DEV Community

Context in Context: Why AI Tools Degrade Over Longer Work Sessions

Keith MacKay — Tue, 12 May 2026 20:48:07 +0000

Context in Context: Why AI Tools Degrade Over Longer Work Sessions

What every executive needs to understand about AI context windows (and how to get the best performance from your AI assistants)

You invested in AI assistants. You were excited. Your initial tests were impressive. But three months in, as sessions are getting longer, you are hearing (or find yourself thinking): "I didn't notice before, but it seems to be forgetting stuff I told it just a little while ago."

You're not imagining it.

A hidden constraint sits at the heart of every AI assistant. It determines whether these tools accelerate your work, or frustrate you by losing important information that has been provided. Many users don't know this constraint exists.

It's called the context window. And if you're using AI for any significant tasks, you need to understand it.

The 30-Second Explanation

Did you ever take a test where you were allowed to create only a single page of reference notes? That page was your context window for that test (especially if you were someone who slept through classes and saw homework as an optional exercise). It contained your entire understanding of the subject at hand.

Another way to think about it: picture your AI assistant with a notepad. It uses this pad as a working memory where it tracks: your conversation, the files it reads, the domain knowledge it adds for this task, and the instructions it follows. That notepad has a fixed size. Everything the AI needs must fit on that pad--your prompts, the LLM responses, supporting documents, tools--all of it. When the notepad fills up, the AI doesn't "remember" earlier information like a human might (if they actually attended the lectures!). It loses access. Or worse, it gets confused trying to juggle too much at once.

That notepad is the "context window." And it fills up faster than a conference room whiteboard on day three of a strategy offsite.

Even worse, your LLM front-end provides additional opportunities to load EVEN MORE things into your context window, taking up precious space: MCP server details, skills, local documents, and so forth.

Why This Hits Your Bottom Line

Currently, typical AI assistants have context windows of roughly 200,000 tokens: about 150,000 words, or a 500-page book. Sounds enormous.

It's not.

Here's what actually fills that space:

Every message exchanged (yours and the AI's responses)
Every file the AI reads to understand your code
System instructions governing the AI's behavior
Tool definitions for every capability you've enabled
Search results, error messages, test outputs

One complex coding session can exhaust that entire budget in minutes.

When the budget runs low, three things break:

Quality tanks. Responses become generic, like getting advice from someone who skimmed your email instead of reading it.
Memory fails. Decisions from early in the conversation get pushed out by newer information. The AI develops corporate amnesia (ever see the movie "Memento"?).
Consistency disappears. The AI contradicts itself. It ignores patterns it established an hour ago. It's like working with someone who wasn't at the last three meetings but won't admit it.

Your impression wasn't wrong. The tool really does degrade the longer it's used.

...And You Can't Even Use ALL of It

Many experiments have shown that using ALL of the context window available to you is, to use the technical term, "a very bad idea". The models have been trained on human data, and the analogs to human cognition even extend to things like giving greater weight to information at the beginning and end of the context window, yielding a mushy middle that is de-emphasized (I think of this as analogous to primacy and recency bias in humans... I haven't researched whether this was designed or entirely an emergent property, feel free to educate me in the comments!).

In many tools, when the window is full, it will automatically compact the information to what it deems important, in order to clear workspace and continue its task. This is "lossy", actually throwing away some of the information that has been provided for context and keeping only a summary. That is a serious limitation for complex tasks.

Many coding shops have standards around how to better preserve project context as the context window fills up -- I have often seen the figure "80%" as the target for maximum amount of context window used for a task. Given my own personal experience, I like to take action when my context window is about 60% full, meaning even LESS available room for context. I've seen some well-respected AI coders in the field recommend using no more than 30%-40% of your context window...so YMMV.

What do you do when you hit your context window target limit? Historically, my colleagues and I would generally used a strategy of pushing session context into an external file, starting a brand-new session, reloading the context from the file, and continuing where we left off. That proves to be an annoying interruption, but it's a small price to pay for continued high-quality work. That strategy has evolved. Now, where possible, we break tasks into small independent components that can be distributed across a swarm of multiple agents, each of which has its own context window. With upfront thinking and strategizing, we can use the tools in such a way that we (almost) never hit the context window limits...but there are still real limits when working with massive codebases, very intertwined systems, high levels of detail, and so forth.

The Real Business Impact

This isn't a minor annoyance. It directly affects four things you care about:

Developer productivity. Developers who don't understand context waste hours fighting degraded AI. Those who do understand achieve 2-4x the output from the same tools.

AI costs. Many commercial AI tools charge effectively by token. Poor context management means paying for waste: the AI reading unnecessary files, repeating explanations, loading unused tools, spinning in circles with polluted context.

Code quality. An AI drowning in context produces inconsistent code, misses requirements, and makes errors that must be caught and fixed.

Adoption success. Nothing kills AI enthusiasm faster than unpredictable performance. Teams that hit degradation repeatedly often abandon tools that could have been transformative. You paid for a sports car; they're convinced it's a lemon.

The Insight That Separates Winners from Strugglers

One mental shift changes everything:

Context is a budget, not a bucket.

Buckets fill passively until they overflow. Budgets demand active allocation.

Teams that treat context as a budget ask: What does the AI need to see right now? What can we exclude? When do we start fresh? How do we move tasks AWAY FROM the AI and into deterministic code where possible? (For instance: a colleague of mine had a terrific retro agent that would review completed sessions and improve processes for subsequent runs. I added an instruction to look for opportunities to write scripts for things that could be done deterministically in future runs, and it estimated a 60-80% future savings in tokens. This was almost certainly overstated, but even a 20% savings in any budget has real value!)

Teams that treat context as a bucket keep piling in information until performance craters. Then they blame the tool.

What Good Looks Like

Developers who get it:

Run workflows that break all projects into discrete, achievable-within-a-single-context-window tasks
Start fresh sessions for distinct tasks instead of running marathon conversations
Delegate focused tasks to specialized "subagents" that return summaries, not raw data dumps (the tools themselves are beginning to do this: for instance, Claude Code tasks can now launch a subagent per task that runs in its own context window)
Write scripts for repetitive operations instead of walking the AI through each step
Maintain project docs that give the AI architectural context without reading every file

Teams that get it:

Establish clear conventions for when to start new sessions
Create shared documentation that bootstraps AI context efficiently, and constantly edit the document with new learning
Run regular retrospectives to find tasks that should be scripts, not conversations
Track context-related productivity metrics

Organizations that get it:

Recognize that AI tool performance depends on usage patterns, not just tool selection
Invest in training for context-aware workflows
Choose AI tools that show context consumption (you can't manage what you can't see), or use tool add-ins or augmentation to allow context monitoring
Set realistic expectations: AI assistants are powerful, but they have constraints

The Hidden Tax on Every Session

Modern AI tools are extensible. They connect to databases, file systems, APIs, and specialized capabilities through plugins (generally via MCP, the Model Context Protocol...a widely-adopted standard for allowing existing software to outline its capabilities and available information for AI agents). Many thousands of MCP integration implementations already exist to allow AI agents to connect to existing software tools and data sources.

Each integration provides power. Each also consumes context: silently, automatically, whether used or not. This is a great simplifier for connectivity/integration, but the MCP standard has no inherent security provisions and comes with a high up-front token cost.

Think of it like subscribing to every streaming service, every magazine, and every meal kit delivery "just in case." Except instead of cluttering your mailbox, you're cluttering your AI's brain.

When you connect an MCP extension, its entire capability description loads into the context window. One extension with 20 features might consume 10,000-15,000 tokens just by being referenced in your project. Organizations that enable every available extension "just in case" can burn 30-40% of their context budget before anyone types a prompt.

The lesson is counterintuitive but critical: More capability often means less intelligence. Enable what you'll use. Disable what you won't.

Alternative strategies include:

connect with necessary tools via their API through scripts created by the LLM
use alternate "progressive disclosure" strategies like "skills" in Claude Code (where the skill components are only loaded into the context window on an "as-and-when needed" basis)
create separate processes or agents with their own context windows for specific tasks or specific MCP instances. ## The Counterintuitive Truth

Here's what surprises most people:

The goal isn't to maximize the amount of information that goes into the AI. It's to optimize what it pays attention to.

More context often produces worse results. An AI with focused, relevant context significantly outperforms one drowning in information. Just like a human does.

Experienced AI users spend effort curating what goes into context. Amateurs just collect stuff and pile more in. Curate for quality, don't collect for completeness.

Warning Signs Your Team Has Context Problems

Listen for these phrases:

"It keeps forgetting what I told it": Classic context overflow
"Sometimes it's brilliant, sometimes it's useless": Inconsistent context load
"The longer I work, the worse it gets": Session running too long
"I have to keep re-explaining the same thing": Important context pushed out
"I just restart when it stops working": Context pollution forcing fresh starts

Five Questions for Your Next Leadership Meeting

If your organization uses AI development tools, ask these:

Do we train developers on context management? Most teams don't. They pay for it in lost productivity every day.
Can we measure context consumption? If you can't see it, you can't manage it. Does your tooling provide visibility?
Do we have conventions for session management? Ad-hoc approaches leave productivity on the table. What triggers a fresh start?
Are we using extensions judiciously? Or does everyone enable everything "just in case"?
Have we identified tasks that should be scripted? Repetitive AI-assisted tasks often work better as simple automation.

Relief Is Coming Soon (But Not Here Just Yet)

The good news: context constraints won't stay this tight forever.

Context windows are growing. Gemini has a 1-million-token context window. Claude Code allows 1-million-token context windows via API usage, but not (yet) to subscribers. Context windows are expected to continue to grow in size, and management of them will only continue to improve.

Usage strategies are also improving. A recently-described technique from MIT researchers called Recursive Language Models (RLMs) shows particular promise. RLM isn't a specific product. It's a strategy that can be applied to any LLM: decompose large problems into smaller pieces, analyze each in its own focused context, then synthesize the results. For those familiar with MapReduce (the strategy Google invented to distribute search problems across many different servers and then synthesize results), you might think about this strategy as vaguely analogous. Divide-and-conquer for AI.

I fully expect that, within 12 months, RLM-based tools will navigate multi-million-line codebases with the coherence that today's tools bring to small projects. "Codebase too large" will stop being a hard limit.

But here's the catch: RLMs solve scale, not quality. Understanding what code does differs from understanding why it exists. And the fundamentals of context hygiene (attention, relevance, signal-to-noise) will still matter. Larger windows just mean more opportunities to drown in noise if you're not deliberate.

Master context management now, and you'll be ready when the constraints loosen. Ignore it, and you'll just have more rope to hang yourself with.

The Bottom Line

AI coding assistants are genuinely transformative. But they're not magic. They operate within real constraints (constraints that, when ignored, undermine the entire investment).

Context management is one of the highest-leverage skills for AI-assisted development. Teams that understand it extract dramatically more value from identical tools. Teams that don't blame the technology for problems rooted in usage patterns.

The AI isn't getting worse. Its notepad just filled up.

Once you understand this, everything changes: how you deploy AI tools, how you train teams to use them, how you measure success.

The notepad is finite. How you manage it determines whether AI becomes your organization's secret weapon, or its most expensive frustration.

The technical details matter less than the organizational practices built around them. Context management isn't an engineering problem. It's a capability your teams either have or don't.

Use Data Stores In Application Development | 🏗️ Build A Product Catalog API

Ntombizakhona Mabaso — Tue, 12 May 2026 20:45:57 +0000

Exam Guide: Developer - Associate
🏗️ Domain 1: Development with AWS Services
📘 Task 3: Use Data Stores In Application Development

DynamoDB dominates this task. The need to understand table design, key selection, indexing, consistency models, and how to write efficient queries is essential. As well as caching with ElastiCache and DAX. Plus specialized stores like OpenSearch.

📘 Concepts

DynamoDB Key Concepts

Primary Keys

Every table needs one. Two options:

Simple primary key: Partition key only (PK). Each item has a unique PK.
Composite primary key: Partition key (PK) + Sort key (SK). Multiple items can share a PK if they have different SKs.

Partition Key Selection

The partition key determines which physical partition stores your data. A good partition key has high cardinality which refers to many distinct values so that the data spreads evenly.

Good Partition Keys	Bad Partition Keys
userId, orderId, sessionId	status ("active"/"inactive")
deviceId, transactionId	country (few values, uneven distribution)
email, accountId	date (hot partition for today)

Consistency Models

Model	Behaviour	Cost	Available On
Eventually Consistent	May return stale data (usually consistent within 1 second)	1x read capacity	Base table + GSIs
Strongly Consistent	Always returns the most up-to-date data	2x read capacity	Base table only (NOT GSIs)

Query vs Scan

Operation	How It Works	Cost	When to Use
Query	Finds items by partition key + optional sort key condition	Reads only matching items	Always prefer this
Scan	Reads every item in the table	Reads entire table	Analytics, one-time migrations only
GetItem	Fetches one item by its full primary key	Reads exactly one item	When you know the exact key

FilterExpression does NOT reduce the amount of data read. It only filters what's returned to you. You still pay for the full scan/query. To reduce reads, use better key design or GSIs.

Global Secondary Index (GSI) vs Local Secondary Index (LSI)

Feature	GSI	LSI
Partition Key	Different from base table	Same as base table
Sort Key	Different from base table	Different from base table
When To Create	Anytime	At table creation only
Throughput	Has its own (separate from base table)	Shares with base table
Consistency	Eventually consistent only	Supports strongly consistent
Limit	20 per table	5 per table

GSI Projection Types:

ALL: all attributes (most flexible, most storage cost)
KEYS_ONLY: only key attributes (cheapest)
INCLUDE: keys + specified attributes (balanced)

Caching Options

Service	Use Case	Latency	Works With
DAX	DynamoDB read cache	Microseconds	DynamoDB only, eventually consistent only
ElastiCache Redis	General-purpose cache	Sub-millisecond	Any data source, complex data types, persistence
ElastiCache Memcached	Simple caching	Sub-millisecond	Any data source, multi-threaded, no persistence

Specialized Data Stores

Store	Use Case
DynamoDB	Key-value lookups, known access patterns, serverless
RDS/Aurora	Relational data, complex joins, ACID transactions
OpenSearch	Full-text search, log analytics, complex queries
S3	Object storage, data lake, large files
ElastiCache	Session storage, leaderboards, real-time analytics

Data Lifecycle

DynamoDB TTL

Automatically deletes expired items at no cost. Eventually consistent (up to 48 hours delay).

S3 Lifecycle Policies

Transition objects between storage classes (Standard → IA → Glacier) or expire them after a set time.

🏗️ Build A Product Catalog API

Now let's put these concepts into practice by builidng a Product Catalog API backed by DynamoDB:

A DynamoDB table with a composite primary key and a Global Secondary Index (GSI)
A Lambda function that performs queries, scans, and writes
TTL configured for automatic data expiration
DAX caching in front of DynamoDB
A clear understanding of when to use query vs scan, GSI vs LSI, and strong vs eventual consistency

Prerequisites

An AWS account (free tier covers DynamoDB and Lambda)

Part I

Design the DynamoDB Table

Before creating anything, let's think about access patterns. This is the most important step in DynamoDB design.

Our Access Patterns

Access Pattern	How We'll Query
Get a product by ID	Query PK = `PRODUCT#123`
List all products in a category	Query PK = `CATEGORY#electronics`
Get a product's reviews	Query PK = `PRODUCT#123`, SK begins_with `REVIEW#`
Find products by price range in a category	Query GSI with category + price
List recently added products	Query GSI with status + createdAt

Create the Table

Step 01: Open the DynamoDB console

Step 02: Click Create table

Table name: ProductCatalog
Partition key: PK (String)
Sort key — optional: SK (String)

Step 03: Under Table settings, choose Customize settings

Step 04: Read/write capacity settings: On-demand

⚠️ Don't create the just table yet, let's add a GSI first

Add a Global Secondary Index

Step 05: Scroll down to Secondary indexes → click Create global index:

Index name: GSI1
Partition key: GSI1PK (String)
Sort key: GSI1SK (String)
Attribute projections: All

Click Create index, then click Create table.

✅Green banner: The ProductCatalog table was created successfully.

Why This Design?

We're using the single-table design pattern with overloaded keys:

Base table:
  PK = "PRODUCT#laptop-001"    SK = "METADATA"           → product details
  PK = "PRODUCT#laptop-001"    SK = "REVIEW#2026-04-24"  → a review
  PK = "CATEGORY#electronics"  SK = "PRODUCT#laptop-001" → category listing

GSI1:
  GSI1PK = "CATEGORY#electronics"  GSI1SK = "PRICE#00079.99" → find by price
  GSI1PK = "STATUS#active"         GSI1SK = "2026-04-24"     → find by date

Partition Key Selection: A good partition key has high cardinality (many distinct values). Bad examples: status (only a few values → hot partition), country (uneven distribution). Good examples: userId, productId, orderId.

Part II

Add Sample Data

Using the Console

Step 01: In the DynamoDB console, click on ProductCatalog

Step 02: Click Explore table items

Step 03: Click Create item
Switch to JSON view (toggle at the top)
Paste this item:

{
  "PK": {"S": "PRODUCT#laptop-001"},
  "SK": {"S": "METADATA"},
  "GSI1PK": {"S": "CATEGORY#electronics"},
  "GSI1SK": {"S": "PRICE#00999.99"},
  "name": {"S": "Pro Laptop 15"},
  "description": {"S": "15-inch laptop with 16GB RAM"},
  "price": {"N": "999.99"},
  "category": {"S": "electronics"},
  "status": {"S": "active"},
  "createdAt": {"S": "2026-04-20T10:00:00Z"},
  "stock": {"N": "50"}
}

Step 04: Click Create item

Add a few more products:

{
  "PK": {"S": "PRODUCT#mouse-002"},
  "SK": {"S": "METADATA"},
  "GSI1PK": {"S": "CATEGORY#electronics"},
  "GSI1SK": {"S": "PRICE#00029.99"},
  "name": {"S": "Wireless Mouse"},
  "description": {"S": "Ergonomic wireless mouse"},
  "price": {"N": "29.99"},
  "category": {"S": "electronics"},
  "status": {"S": "active"},
  "createdAt": {"S": "2026-04-22T10:00:00Z"},
  "stock": {"N": "200"}
}

{
  "PK": {"S": "PRODUCT#laptop-001"},
  "SK": {"S": "REVIEW#2026-04-24#user-001"},
  "rating": {"N": "5"},
  "comment": {"S": "Great laptop, fast and reliable"},
  "userId": {"S": "user-001"},
  "createdAt": {"S": "2026-04-24T14:30:00Z"}
}

{
  "PK": {"S": "CATEGORY#electronics"},
  "SK": {"S": "PRODUCT#laptop-001"},
  "name": {"S": "Pro Laptop 15"},
  "price": {"N": "999.99"}
}

{
  "PK": {"S": "CATEGORY#electronics"},
  "SK": {"S": "PRODUCT#mouse-002"},
  "name": {"S": "Wireless Mouse"},
  "price": {"N": "29.99"}
}

Part III

Query vs Scan

Query (Efficient)

Step 01: In the ▼ Scan or query items tab, switch from Scan to Query

Step 02: Set:

Partition key Value: PRODUCT#laptop-001
Sort key Value: Begins with ▼ REVIEW Click Run

✅Green banner: Completed · Items returned: 1 · Items scanned: 1 · Efficiency: 100% · RCUs consumed: 0.5

You'll see only the review items for that product. DynamoDB read exactly the items you asked for. Efficient.

Scan (Expensive)

Step 03: Switch back to Scan
Click Run with no filters

✅Green banner: Completed · Items returned: 5 · Items scanned: 5 · Efficiency: 100% · RCUs consumed: 2

You'll see ALL items in the table. DynamoDB read every single item. On a table with millions of items. This is slow and expensive.

Step 04: Click Add filter

Attribute name: category
Type: String
Condition: Equal to
Value: electronics Click Run

✅Green banner: Completed · Items returned: 2 · Items scanned: 5 · Efficiency: 40% · RCUs consumed: 2

You'll see only electronics items, but DynamoDB still read the entire table and filtered afterward. The filter doesn't reduce the read cost.

💡 FilterExpression does NOT reduce the amount of data read. It only filters what's returned to you. You still pay for the full scan. To reduce reads, use better key design or GSIs.

Query the GSI

Step 05: Switch to Query

Step 06: Change the Index dropdown to GSI1

Partition key (GSI1PK) Value: CATEGORY#electronics
Sort key (GSI1SK) Value: Begins with ▼ PRICE# Click Run

✅Green banner:: Completed · Items returned: 2 · Items scanned: 2 · Efficiency: 100% · RCUs consumed: 0.5

This efficiently finds all electronics products, sorted by price. That's the power of a well-designed GSI.

Part IV

Build the API with Lambda

Create the Lambda Function

Step 01: Open the Lambda console → Create function

Function name: ProductCatalogAPI
Runtime: Python 3.12 Click Create function

✅Green banner:: Successfully created the function "ProductCatalogAPI".

Step 02: Configuration → *General configuration → click Edit

Memory: 256 MB
Timeout: 10 seconds Click Save

Step 03:Add DynamoDB Permissions
Configuration → Permissions → click the role name
Add permissions → Attach policies
Search for and attach AmazonDynamoDBFullAccess

⚠️ In production, scope this down to only the ProductCatalog table. For this tutorial, full access keeps things simple. Brevity.

Step 04: Write the Function Code

import json
import boto3
from decimal import Decimal
from boto3.dynamodb.conditions import Key, Attr

# Initialize OUTSIDE the handler — reused across warm invocations
dynamodb = boto3.resource('dynamodb')
table = dynamodb.Table('ProductCatalog')

class DecimalEncoder(json.JSONEncoder):
    """DynamoDB returns Decimal types — this converts them to float for JSON."""
    def default(self, obj):
        if isinstance(obj, Decimal):
            return float(obj)
        return super().default(obj)

def lambda_handler(event, context):
    """
    Routes requests based on the HTTP method and path.
    Demonstrates query, scan, get_item, and put_item operations.
    """
    http_method = event.get('httpMethod', 'GET')
    path = event.get('path', '/')
    path_params = event.get('pathParameters') or {}
    query_params = event.get('queryStringParameters') or {}

    try:
        if path == '/products' and http_method == 'GET':
            return list_products(query_params)

        elif path.startswith('/products/') and http_method == 'GET':
            product_id = path_params.get('productId', path.split('/')[-1])
            return get_product(product_id)

        elif path == '/products' and http_method == 'POST':
            body = json.loads(event.get('body', '{}'))
            return create_product(body)

        elif path.startswith('/products/') and path.endswith('/reviews'):
            product_id = path_params.get('productId', path.split('/')[2])
            return get_reviews(product_id)

        else:
            return response(404, {'error': 'Not found'})

    except Exception as e:
        print(f"Error: {str(e)}")
        return response(500, {'error': 'Internal server error'})


def list_products(query_params):
    """
    List products by category using QUERY (efficient).
    Falls back to SCAN if no category is specified (expensive — avoid in production).
    """
    category = query_params.get('category')

    if category:
        # QUERY — efficient, reads only matching items
        print(f"Querying products in category: {category}")
        result = table.query(
            KeyConditionExpression=Key('PK').eq(f'CATEGORY#{category}')
        )
    else:
        # SCAN — reads entire table, expensive!
        # In production, require a category or use pagination
        print("WARNING: Scanning entire table — this is expensive!")
        result = table.scan(
            FilterExpression=Attr('SK').eq('METADATA')
        )

    return response(200, {
        'products': result['Items'],
        'count': result['Count'],
        'scannedCount': result['ScannedCount']  # Shows the difference between query and scan
    })


def get_product(product_id):
    """
    Get a single product by ID using GET_ITEM.
    This is the most efficient read — directly accesses one item by its full key.
    """
    result = table.get_item(
        Key={
            'PK': f'PRODUCT#{product_id}',
            'SK': 'METADATA'
        },
        # ConsistentRead=True  # Uncomment for strongly consistent read (2x cost)
    )

    item = result.get('Item')
    if not item:
        return response(404, {'error': f'Product {product_id} not found'})

    return response(200, item)


def get_reviews(product_id):
    """
    Get all reviews for a product using QUERY with sort key condition.
    begins_with on the sort key efficiently finds all reviews.
    """
    result = table.query(
        KeyConditionExpression=(
            Key('PK').eq(f'PRODUCT#{product_id}') &
            Key('SK').begins_with('REVIEW#')
        ),
        ScanIndexForward=False  # Sort descending (newest first)
    )

    return response(200, {
        'productId': product_id,
        'reviews': result['Items'],
        'count': result['Count']
    })


def create_product(body):
    """
    Create a new product using PUT_ITEM.
    Also creates the category listing item for efficient category queries.
    """
    product_id = body['productId']
    category = body['category']
    price = Decimal(str(body['price']))  # DynamoDB requires Decimal, not float!

    # Write the product metadata
    table.put_item(Item={
        'PK': f'PRODUCT#{product_id}',
        'SK': 'METADATA',
        'GSI1PK': f'CATEGORY#{category}',
        'GSI1SK': f'PRICE#{price:010.2f}',  # Zero-padded for correct sort order
        'name': body['name'],
        'description': body.get('description', ''),
        'price': price,
        'category': category,
        'status': 'active',
        'stock': body.get('stock', 0)
    })

    # Write the category listing (denormalization for efficient queries)
    table.put_item(Item={
        'PK': f'CATEGORY#{category}',
        'SK': f'PRODUCT#{product_id}',
        'name': body['name'],
        'price': price
    })

    return response(201, {'message': 'Product created', 'productId': product_id})


def response(status_code, body):
    return {
        'statusCode': status_code,
        'headers': {'Content-Type': 'application/json'},
        'body': json.dumps(body, cls=DecimalEncoder)
    }

Step 05: Click Deploy

✅Green banner: Successfully updated the function "ProductCatalogAPI".

Notice Decimal(str(body['price'])). DynamoDB does NOT support Python float. You must use Decimal. This is a common gotcha.

Step 06: Test The Function
Click the Test tab
Create test events for each operation:

List products by category:

{
  "httpMethod": "GET",
  "path": "/products",
  "queryStringParameters": {"category": "electronics"},
  "pathParameters": null
}

Get a single product:

{
  "httpMethod": "GET",
  "path": "/products/laptop-001",
  "pathParameters": {"productId": "laptop-001"},
  "queryStringParameters": null
}

Get reviews:

{
  "httpMethod": "GET",
  "path": "/products/laptop-001/reviews",
  "pathParameters": {"productId": "laptop-001"},
  "queryStringParameters": null
}

Create a product:

{
  "httpMethod": "POST",
  "path": "/products",
  "body": "{\"productId\":\"keyboard-003\",\"name\":\"Mechanical Keyboard\",\"category\":\"electronics\",\"price\":89.99,\"stock\":100}",
  "pathParameters": null,
  "queryStringParameters": null
}

💡 Run each test and check the results. Look at the count vs scannedCount in the list response. When using query, they'll be equal. When scanning, scannedCount will be higher.

Part V

Consistency Models

See the Difference

Step 01: In the Lambda function, find the get_product function
Uncomment the ConsistentRead=True line
Deploy

✅Green banner: Successfully updated the function "ProductCatalogAPI".

Now get_product uses strongly consistent reads:

Always returns the latest data

Costs 2x the read capacity

Only works on the base table (not GSIs)

💡 GSIs only support eventually consistent reads.

When to Use Each

Use Case	Consistency	Why
Product catalog browsing	Eventually consistent	Stale data for a second is fine
Shopping cart	Strongly consistent	User expects to see what they just added
Inventory check before purchase	Strongly consistent	Must be accurate to avoid overselling
Analytics dashboard	Eventually consistent	Slight delay is acceptable

Part VI

TTL: Automatic Data Expiration

Enable TTL

Step 01: In the DynamoDB console, click on ProductCatalog

Step 02: Click ▼ Actions
Click Turn on TTL

Step 03: Turn on Time to Live (TTL)
TTL attribute name: ttl
Click Turn on TTL

✅Green banner: Successfully activated Time to Live for the ProductCatalog table with the ttl attribute.

Step 04: Add Items with TTL

Create an item with a TTL value (Unix epoch timestamp):

{
  "PK": {"S": "SESSION#user-001"},
  "SK": {"S": "DATA"},
  "userId": {"S": "user-001"},
  "cartItems": {"L": [{"S": "laptop-001"}, {"S": "mouse-002"}]},
  "ttl": {"N": "1745625600"}
}

The ttl value is a Unix timestamp. Items are deleted after this time. Use an epoch converter to set a time a few minutes in the future for testing.

💡 TTL deletion is eventually consistent: items may persist for up to 48 hours after expiration. Don't rely on TTL for exact timing. Always filter out expired items in your queries as a safety measure.

Part VII

Caching with DAX

DAX (DynamoDB Accelerator) is an in-memory cache that sits in front of DynamoDB. It's a drop-in replacement. Same API, just change the client endpoint.

When to Use DAX

Scenario	Use DAX?
Read-heavy workload, same items queried repeatedly	Yes
Microsecond response times needed	Yes
Write-heavy workload	No (DAX is a read cache)
Need strongly consistent reads	No (DAX returns eventually consistent)
Diverse access patterns, rarely same item twice	No (low cache hit rate)

How DAX Works

Without DAX:
  App → DynamoDB (single-digit millisecond reads)

With DAX:
  App → DAX (microsecond reads if cached) → DynamoDB (on cache miss)

Console Walkthrough (Don't Create.Just Understand)

💸 DAX requires a VPC and costs money even when idle. We'll walk through the setup without creating it.

Step 01: Click ▼ DAX

Step 02: Click Create cluster

Cluster name: product-cache
Node type family: t-type family
Node type: dax.t3.small
Cluster size: 3 nodes (for high availability) Click Next

Step 03: Configure networks

Network Type: IPv4
Subnet group: Create new
Subnet group name: MySubnetGroup
VPC ID: defaultVPC
Subnets: Select all
Security group: default ▼ Click View in EC2 console

Step 04: Allow port 8111 from your Lambda functions

✅Green banner: Inbound security group rules successfully modified on security group

Step 05: Configure Security

IAM Service role for DynamoDB access: Create new
IAM role name: DaxToDynamoDB Click Next → Click Next → Click Create cluster

✅Green banner: Successfully created the cluster product-cache.

Step 06: In your Lambda code, you'd change one line:

# Without DAX
dynamodb = boto3.resource('dynamodb')

# With DAX — same API, just different endpoint
import amazondax
dax_client = amazondax.AmazonDaxClient(
    endpoints=['product-cache.abc123.dax-clusters.us-east-1.amazonaws.com:8111']
)
table = dax_client.Table('ProductCatalog')
# All your existing code works unchanged!

DAX is a drop-in replacement for DynamoDB reads. Same API, same code. Just change the client. 💡 But remember: DAX only supports eventually consistent reads and is for read-heavy workloads.

🏗️ What You Built | 📘Exam Concepts Recap

What You Did	Exam Concept
Designed a table around access patterns first	Access-pattern-driven DynamoDB design
Created a composite primary key (PK + SK)	Single-table design, sort key relationships
Added a Global Secondary Index with different keys	GSI for alternate access patterns
Used overloaded keys (`PRODUCT#`, `CATEGORY#`, `REVIEW#`)	Single-table design pattern
Queried by partition key with `begins_with` on sort key	Efficient query operations
Ran a scan and compared `Count` vs `ScannedCount`	Scan is expensive: it reads the entire table
Added a `FilterExpression` to a scan	Filters run AFTER reading: don't save capacity
Used `Decimal(str(price))` instead of `float`	DynamoDB type system: no float support
Toggled `ConsistentRead=True` on `get_item`	Strongly vs eventually consistent reads
Noted GSIs only support eventual consistency	GSI limitations
Enabled TTL on a `ttl` attribute	Automatic data lifecycle management
Walked through DAX setup	Read caching for DynamoDB, microsecond latency

⚠️ Clean Up Protocol

1. DynamoDB → Delete the ProductCatalog table
2. Lambda → Delete ProductCatalogAPI
3. IAM → Delete the Lambda execution role
4. CloudWatch → Delete the log groups

Key Takeaways

Partition key cardinality: high cardinality = even distribution = good performance
Query > Scan: always prefer query. Scan reads the entire table.
FilterExpression doesn't save reads: it filters after reading. Use key design or GSIs instead.
GSIs can be added anytime. LSIs must be created with the table
GSIs are eventually consistent only: no strongly consistent reads on GSIs
Use Decimal, not float for DynamoDB numbers in Python
TTL is free but eventually consistent (up to 48 hours delay)
DAX = DynamoDB read cache (microsecond reads). Same API as DynamoDB.
DAX doesn't support strongly consistent reads
Single-table design with overloaded keys is the recommended DynamoDB pattern

Additional Resources

🏗️

Stop Sharing Prompts — Start Shipping Claude Plugins

Michel Sánchez Montells — Tue, 12 May 2026 20:43:23 +0000

The license arrives. The whole team starts using Claude. At first, everything is bright: "This thing is amazing!" Everyone improves, everyone shares, everyone discovers new things.

And then, almost without noticing, as a natural evolution, a new problem appears.

Everyone has configured it on their own — on their machine, in their own interface. The one who found the perfect prompt for reviewing PRs keeps it to themselves. The one who built a skill to generate Jira tickets has it on their machine and nowhere else.

You have as many versions of Claude as you have team members.

The first solution, the obvious one, doesn't work for everyone

The first thing every team tries is exporting and importing a file through Cowork. It works. But only between Cowork users.

The developers on Ubuntu running Claude Code don't have that option at first glance. And even if they did, every time someone updates a skill, you're back to sending the file through the team Slack channel. The previous one is now outdated. And nobody knows which version they have installed.

The real solution: a repository as a marketplace

Claude Code and Cowork both support importing skills, commands, and agents packaged as plugins from an external source that follows the plugin marketplace structure.

That means you can build your own:

Git repository, accessible to your whole team, that acts as the single source of truth for your Claude tooling.

What one person updates, everyone receives. And each team member can import it regardless of whether they work on Windows with Cowork, on Mac, or on Ubuntu with Claude Code.

Here's how to do it.

How?

1. Create the repository

It can be on GitHub, GitLab, Bitbucket — whatever you use. It just needs to be accessible from your team's machines.

The repo follows this structure:

claude-plugin-marketplace/         ← git repository
├── .claude-plugin/
│   └── marketplace.json          ← marketplace index
├── README.md
└── greetings/                    ← one directory per plugin
    ├── .claude-plugin/           
    │   └── plugin.json           ← plugin metadata
    ├── commands/
    │   └── welcome.md            ← command
    └── skills/
        └── greet-in-language/    ← skill
            └── SKILL.md

2. The `marketplace.json` file

This lives inside the .claude-plugin directory at the repo root. It lists the available plugins, each pointing to its directory:

{
  "name": "claude-montells-plugins",
  "owner": {
    "name": "Michel Sánchez Montells"
  },
  "plugins": [
    {
      "name": "greetings",
      "source": "./greetings",
      "description": "A collection of greeting utilities: a /welcome command that introduces the session with date and directory context, and a skill that greets the user in any language they request."
    }
  ]
}

name: is how the marketplace will be listed.
plugins: list of plugins with name and source.

3. The `plugin.json` file

Each plugin defines its metadata in .claude-plugin/plugin.json inside its own directory:

{
  "name": "greetings",
  "version": "1.0.0",
  "description": "A collection of greeting utilities: a /welcome command that introduces the session with date and directory context, and a skill that greets the user in any language they request.",
  "author": {
    "name": "Michel Sánchez Montells",
    "email": "montells@gmail.com",
    "url": "http://github.com/montells"
  },
  "repository": "https://github.com/montells/claude-plugin-marketplace"
}

name: the name of the plugin. Act as a namespace for the commands and skills.

4. A skill example

Each skill is a folder named after the skill, containing a SKILL.md file. The content is the prompt Claude will invoke autonomously when the context calls for it:

<!-- pluginName/skills/skillName/SKILL.md -->
<!-- greetings/skills/greet-in-language/SKILL.md -->

Greet the user in the language they request.
If no language is specified, greet them in English.
Keep the greeting warm and brief.

5. A command example

Commands live in commands/<name>.md. Unlike skills, they are invoked explicitly with /name and can receive arguments via $ARGUMENTS:

<!-- greetings/commands/commandName.md -->
<!-- greetings/commands/welcome.md -->
---
description: "Introduce the session with date and directory context"
allowed-tools: Bash(date), Bash(pwd)
---

Greet the user and provide session context.

## Context
- Current date and time: !`date`
- Working directory: !`pwd`

## Task
Say hello and let the user know where they are and what time it is.

6. Import from Cowork

The flow in Cowork depends on your plan:

Team or Enterprise plan — the ideal path for teams. An admin connects the GitHub repository from the organization settings. From that point, the plugins appear in every team member's catalog and can be installed (or auto-installed) without anyone having to do anything else.

Individual plan (Pro/Max) — the repository can't be connected directly, but you can export the plugin as a .zip and upload it manually: Customize → Browse plugins → Upload plugin file. It works, though it loses the benefit of automatic sync.

In both cases, once the plugin is installed, its skills appear when you type / in Cowork.

7. Import from Claude Code

From Claude Code, type /plugins to open the plugin manager. Go to the Marketplaces tab and select + Add Marketplace.

You'll be prompted for the marketplace source. It supports several formats:

owner/repo                              ← GitHub shorthand
git@github.com:owner/repo.git          ← SSH
https://example.com/marketplace.json   ← HTTPS
./path/to/marketplace                  ← local path

In our case:

montells/claude-plugin-marketplace

Or with SSH if the repo is private:

git@github.com:montells/claude-plugin-marketplace.git

Once added, go to the Discover tab. You'll see the plugins available in the marketplace. Select one to view its details and choose the installation scope:

Install for you (user scope) — just for you, across all your projects
Install for all collaborators on this repository (project scope) — for the whole team on this repo
Install for you, in this repo only (local scope) — just you, just here

After installing, Claude Code will prompt you to run /reload-plugins to activate the changes.

From that point on, the plugin's commands are invoked with the plugin prefix: /greetings:welcome. Skills activate autonomously when Claude determines the context calls for them.

8. Update flow

From here, updating a skill is exactly like updating code:

Edit the skill file in the repo
Commit and push
The team receives the update next time they sync

No files through Slack. No "which version do you have?". No diverging configurations.

The result

One repository. One single source of truth. And every team member — regardless of their platform — with exactly the same tools, at their latest version.

Onboarding a new team member to Claude goes from "set it up yourself" to "add this marketplace and you're ready."

The example used in this post can be found here

Introduction to Dinghy: a Swiss-army knife for everyday engineering

mrduguo — Tue, 12 May 2026 20:39:11 +0000

If you ship anything for a living — diagrams, infrastructure, docs, slide decks — you have probably noticed that each of those things lives in its own world, with its own toolchain, its own opinionated editor, and its own subtle ways to drift out of sync.

Dinghy is an open-source toolchain that puts all of them under one roof. One CLI. One install. One consistent way to describe what you want as code and let the tools deliver the final artwork.

What it is

A Swiss-army knife for engineers who like writing code more than clicking through dialogs:

Diagram as Code — render architecture diagrams to draw.io.
Infrastructure as Code — render OpenTofu / Terraform from React TSX.
Site Builder — author docs sites with Docusaurus, live-preview them, deploy to S3.
Slide Builder — author RevealJS presentations in YAML / Markdown / HTML, with Prezi-style zoom-and-pan as a Dinghy-exclusive bonus.

It is powered by Deno and Docker, so you do not need to babysit Node versions, Python virtualenvs, Terraform providers, or any of the rest of it.

From a DevOps engineer's bench

Dinghy was built by a DevOps engineer, so it is shaped to walk with your code across the whole software development lifecycle — from local development through to CI/CD — instead of stopping at the edge of one stage.

How it is shaped

Dinghy splits cleanly into a thin CLI and a fat engine that runs in Docker. The CLI is what you install on your machine; the engine is a versioned image that ships every dependency Dinghy needs.

curl -fsSL https://get.dinghy.dev/install.sh | sh

That single command gets you the CLI. From then on, everything Dinghy does happens inside the engine image — which means every machine on your team gets the exact same versions of Deno, Node, OpenTofu / Terraform, and every TF provider, pinned through a single .dinghyrc file.

DINGHY_ENGINE_VERSION=0.1...

One lock. Predictable versions. No more "it works on my laptop" — and no more two-year-old projects you can't rebuild because the dependencies have rotted away.

Who it's for

Anyone who needs to write code for any of this work — a diagram, a piece of infrastructure, a docs site or web app, a slide deck. You do not need to use them all, and you do not need to use them all the time. Reach for one when that is all you need; pull in a few when the work spans more than one.

If any of that sounds useful for what you are building, the rest of this series digs into each capability one post at a time (coming soon — links will go live as each post is published):

Why React for IaC? — the origin of the Dinghy project and core concept.
Diagram as Code — author architecture diagrams as TSX components.
Infrastructure as Code — 248 lines of Terraform from 8 lines of source.
Site Builder — from one Markdown file to a deployed site.
Slide Builder — RevealJS in YAML, with Prezi-style zoom.
Dinghy in the AI age — still relevant? How it works alongside AI.

Ready to set sail?

curl -fsSL https://get.dinghy.dev/install.sh | sh

Guides and examples are at https://dinghy.dev.

What Nigeria's Stock Market Taught Me About System Reliability

Okeke Chukwudubem — Tue, 12 May 2026 20:32:49 +0000

As a software engineering student, I spend a lot of time thinking about systems how they're built, how they fail, and how they recover.

This week, Nigeria's stock market gave me a masterclass.

The Crash

The Central Bank introduced a new rule limiting bank investments in foreign subsidiaries. Within hours, the market lost ₦1.92 trillion. Banking stocks collapsed. Panic spread.

One regulatory change. One massive system failure.

In software terms, this is a single point of failure—one component that, when it breaks, brings down the entire system.

The Recovery

The next day, the market regained ₦1.71 trillion. The same banks. The same fundamentals. The only thing that changed was sentiment.

In system design, we call this eventual consistency—a distributed system's ability to return to a correct state after a disruption, as long as the underlying data remains intact.

The Real Lesson

But here's what most people missed.

Beneath the daily swings, something deeper was happening. Nigeria's market has undergone a structural transformation. Total transactions hit ₦4.15 trillion in Q1 2026—almost double the previous year. And 86.9% of that money is domestic, anchored by pension funds with ₦29.43 trillion in assets.

This isn't speculation. This is architecture.

What This Means for Developers

When a single CBN rule crashes banking stocks, that's a single point of failure. When panic selling spreads across sectors, that's a cascading failure. When the market recovers in 24 hours, that's eventual consistency. When pension funds anchor the market with patient capital, that's redundancy and fault tolerance. And when 86.9% of capital comes from domestic sources, that's a decentralized architecture.

The stock market, it turns out, is just another distributed system. And distributed systems behave in predictable ways—whether they're made of microservices or market participants.

What I'm Learning

The best engineers don't just write code. They understand systems. They know that failures are inevitable, but collapse is optional. They design for resilience, not perfection.

That's the kind of engineer I'm trying to become.

Mini Shai-Hulud: un gusano de cadena de suministro que explotó TanStack y el ecosistema npm.

Cristian Carrillo — Tue, 12 May 2026 20:32:29 +0000

El día de ayer (10/05/2026) la comunidad de npm y PyPI vivió un nuevo capítulo de Mini Shai-Hulud, un campaña de ataque de cadena de suministro dirigida por el grupo TeamPCP que comprometió paquetes de TanStack, Mistral AI, UiPath, OpenSearch, guardrails‑ai y más.

El impacto se estimó en más de 170 paquetes y 500M+ de descargas acumuladas, con un nivel de severidad crítico (CVSS ≈ 9.6) y un CVE asociado: CVE‑2026‑45321.

1 ¿Qué pasó?

El ataque inyectó código malicioso en paquetes de npm muy populares, empezando por el ecosistema de TanStack (por ejemplo, @tanstack/react‑router, @tanstack/vue‑router, etc.), y luego se extendió a Mistral AI, UiPath, OpenSearch, guardrails‑ai y otros.

El malware, un gusano de credenciales (credential‑stealing worm), hacía lo siguiente al ejecutarse durante npm install o cuando se usaba el paquete en CI/CD.

• Robaba tokens de GitHub, npm, AWS, GCP, Azure, Kubernetes, Vault, IDEs y hasta carteras de cripto.
• Se auto‑replegaba hacia otros paquetes que el mantenedor pudiera publicar, propagándose en el ecosistema.
• Establecía persistencia en máquinas de desarrolladores (Claude Code, VS Code, servicios de sistema) y podía borrar datos si se revocaba cierto token.

También se ha visto una variante en PyPI (guardrails‑ai@0.10.1, mistralai@2.4.6) que descarga y ejecuta un payload remoto sin verificación de integridad, ampliando el ataque a Python y otros ecosistemas.

2 ¿Cómo sucedió?

El ataque combinó ingeniería de engaños en GitHub con un mal uso de GitHub Actions y OIDC, sin necesidad de robar directamente el token de npm.

El flujo básico fue:

1. Inyección en el fork:

    ◦ Atacante hace fork de TanStack/router y sube un commit con un paquete @tanstack/setup que contiene un script prepare malicioso que ejecuta bun run tanstack_runner.js.
    ◦ El commit es “huérfano” y se hace pasar por algo legítimo gracias a la URL de GitHub.

2. Envenenamiento de caché en GitHub Actions:

    ◦ El workflow de CI/CD de TanStack ejecuta código del fork, lo que contamina el caché de pnpm y causa que se instale código controlado por el atacante.

3. Extracción de token OIDC y publicación de paquetes:

    ◦ El payload accede a la memoria del proceso del runner (/proc/*/mem) y extrae el OIDC token legítimo de GitHub, que el sistema de SLSA considera confiable.
    ◦ El atacante usa ese token para publicar versiones falsas de los paquetes de TanStack directamente al registro de npm, con probidad de SLSA válida, lo que hace que el paquete “se vea limpio” incluso con firmas.

4. Auto‑propagación del worm:

    ◦ El malware busca tokens de npm con bypass_2fa, enumera todos los paquetes del mantenedor y vuelve a publicar versiones comprometidas, generando el efecto de “gusano” en el ecosistema.

3 ¿Qué debes tener en cuenta?

Este incidente recalca varios peligros que ya no son "teóricos":

• GitHub Actions + OIDC = nuevo vector de ataque

Un token OIDC, aunque sea de corta vida, puede usarse para publicar paquetes y firmarlos con SLSA, dando pinta de legítimo a un paquete malicioso.
• Un solo npm install puede ser suficiente
◦ El malicioso router_init.js se ejecutaba en el pre‑instalación y se auto‑desprendía en segundo plano, sin dejar rastro claro en logs.
◦ Una vez instalado, el gusano podía robar cualquier secreto a disposición en esa máquina o flujo de CI.
• Las salvaguardias “tradicionales” no bastan
◦ Firmas de paquetes, SLSA, y hasta algunos scanners estáticos no detectaron el malware porque el código ejecutable era obfuscado y ejecutado en runtime.
• El impacto va más allá de npm
El ataque ya se ha extendido a PyPI y otros ecosistemas (SAP, Bitwarden, Intercom, Lightning, etc.), lo que muestra que estamos ante una campaña operativa continua de TeamPCP, no un ataque aislado.

4 ¿Qué hacer ahora?

Si usas npm/PyPI en producción, estos pasos no son opcionales:

• Identificar exposición:
    ◦ Revisa package‑lock.json / yarn.lock / pnpm‑lock.yaml (y requirements.txt o pipenv.lock en Python) buscando versiones afectadas de @tanstack/*, @uipath/*, mistralai, guardrails‑ai, @opensearch‑project/opensearch, etc.
    ◦ Busca router_init.js o setup.mjs en el árbol de node_modules y en tus tarballs.

• Rotar todos los secretos potencialmente expuestos:
    ◦ Tokens de npm, GitHub, AWS, Vault, Kubernetes, CI/CD, etc.
    ◦ Wiz y StepSecurity recomiendan rotar cualquier token si el entorno instaló alguna versión afectada, por el alcance de lo que el malware puede extraer.

• Eliminar persistencia en máquinas de desarrolladores:
    ◦ Borrar archivos como .claude/router_runtime.js, .claude/setup.mjs, .vscode/setup.mjs y revisar settings.json y tasks.json.
    ◦ En macOS/Linux, eliminar el servicio gh‑token‑monitor antes de tocar tokens de GitHub para evitar que el wiper se dispare.

• Bloquear infraestructura de C2:
    ◦ Bloquear a nivel DNS/proxy dominios como git‑tanstack.com, *.getsession.org y otras IPs/C2 documentadas por StepSecurity, Wiz, Socket, etc.

5 ¿Cómo protegerse a futuro?

Este ataque es una hoja de ruta de hardening para cualquier equipo que consuma paquetes de terceros:

• Reducir el alcance de OIDC en GitHub Actions:
    ◦ Usar solo id‑token: write en el job que realmente publica, y evitar OIDC en workflows de test/CI generales.

• Hardening de GitHub Actions:
    ◦ Asegurar que pull_request_target solo se ejecute en ramas protegidas y que no se ejecute código de forkeos sin validación.
    ◦ Limpiar caché de CI y usar restricciones de permisos entre fork y base.

• Adoptar buffers de tiempo para nuevos paquetes:
    ◦ Estrategias como “cooldown” de versiones nuevas (nuevas versiones de npm bloqueadas por 24–72 horas) dan margen para detectar y bloquear estos ataques antes de que lleguen a producción.

• Monitoreo de tiempo de ejecución en CI:
    ◦ Herramientas que monitorean tráfico de red, lectura de memoria de runner (/proc/*/mem) o uso de sudo / python3 de forma inusual ayudan a detectar estas inyecciones que evitan el escaneo estático.

• No confiar ciegamente en “provenance” o SLSA:
    ◦ Que un paquete tenga badges de SLSA no garantiza que el pipeline no haya sido comprometido; debes ver el provenance como una parte de tu cadena de confianza, no como la única.

6 Reflexión para líderes técnicos y de seguridad:

Este episodio muestra que:

• La cadena de suministro ya es un vector de ataque operativo y automatizado.
• Un gusano puede escalar de un solo paquete a docenas de repositorios y nubes en cuestión de horas.
• Debes combinar:
    ◦ Control de cambios de dependencias.
    ◦ Hardening de CI/CD.
    ◦ Monitoreo de tiempo de ejecución.
    ◦ Respuesta rápida de rotación de credenciales.

Enlace de referencia rápida:
• Vulnerabilidad CVE‑2026‑45321 (TanStack): detalle de impacto y severidad.
• Mini‑Shai‑Hulud en npm y PyPI: artículos de The Hacker News, Socket, StepSecurity y Wiz con IOCs y pasos de remediation.

The compliance deadline banks aren't watching for

Yaman Al Bochi — Tue, 12 May 2026 20:31:59 +0000

Most financial institutions have good AI. Very few have good AI governance.

There's a practical gap right now between what regulators are signaling (OSFI E-23, SR 11-7) and what institutions are actually tracking. That gap has a name: Shadow AI — the models and tools deployed inside an organization without any formal oversight.

This isn't about being afraid of regulators. It's about realizing that governance isn't a barrier to speed; it's how you prove to the market that your AI is safe to scale.

At Saillent, we help institutions close that gap through a structured, five-tier governance framework that aligns directly with what OSFI and the Fed are asking for. Not theory — applied, audit-ready work.

If you're leading risk or compliance at a financial institution, now is the time to get visibility into what's actually running inside your organization.

My inbox is open: info@saillent.com
Learn more: saillent.com

The mindset all junior developers should have

Tran Manh Hung — Tue, 12 May 2026 20:29:43 +0000

Are you beginning your journey as a developer? Well, I've got something for you. In this article, I want to share a few subjective points on the advice I give my junior devs.

Over the years I've noticed recurring patterns, mistakes, and a few trends I really don't like. So I figured it was time to write them down.

⚠️ Warning: Before you start reading my takes, I'm assuming one important thing — that your tech leads aren't assholes and genuinely want to help you flourish. If you're not so blessed... boy, am I sorry for you.

TL;DR for the impatient:

Bring your guess when you ask a question
Seniors are wrong sometimes — push back
It's our code, never his code
Feeling like you know nothing? That's the job
Use AI, but read what it gives you
Don't compare yourself to others
It's just a job. Sleep.

Alright lets start...

When asking a question, also share what you think the answer is

Let's say you're past the "how do I even start" phase and have a concrete question.

If your question is genuinely complex, it's probably hard for the senior dev to answer too (unless they're Wozniak). It takes their time, and you might also miss context that's important for the solution.

That's why I recommend pairing most questions with your own proposed answer. It can be a totally stupid guess — that's fine. What you'll notice is that a surprising number of times, you end up answering your own question while formulating it. And when you don't, you've given the senior a much better starting point for the conversation, which makes it far easier to get the answer you actually need.

Note: after writing this, I realized it's basically rubber duck debugging. :D

Your mentor/senior dev can also make mistakes

Seniors aren't oracles. We've just been wrong more times than you have, which is mostly what experience is.

If something a senior tells you doesn't add up — push back, ask why, dig in. A good senior will respect that far more than silent agreement. And occasionally, you'll be the one who's right. That's a great feeling, and it's how trust gets built both ways.

It's our code, not yours or mine

This is the most common issue I've encountered across almost every team. Someone pushes code that has a bug. I ask what happened. The first response is: "It was XX, he should fix it."

I hate it.

You're creating an environment where people are afraid to take risks. No risks means slower progress. Slower progress kills motivation. You see where this goes.

Take ownership of the project as a whole team. Build is broken? Instead of pointing out who did it, suggest how you think it could be fixed. There will be times your colleague makes a mistake. There will also be times you make the mistake. Don't forget — you all share the same goal.

Do you feel like the more you learn, the less you know? Good.

Development is genuinely complex. If you think everything is easy, you're either a genius or you're only scratching the surface. The discomfort of "I don't know enough yet" is actually a sign you're starting to see the real shape of the problem space. Get comfortable with it — it doesn't really go away, and that's a feature, not a bug.

AI is great, but please always try to understand the code

AI tools are amazing accelerators, and I'm not going to tell you to avoid them. But there's a difference between using AI to help you build something and using AI to build something for you.

If you ship code you don't understand, you can't debug it, you can't extend it, and you can't defend it in code review. Worse, you don't grow. Treat AI output the same way you'd treat a Stack Overflow answer from 2014 — useful, often correct, but always something you should read, question, and actually understand before it becomes part of your codebase.

Stop comparing yourself to others — everyone moves at their own pace

Someone on your team picked up Kubernetes in a weekend. Someone else seems to know every keyboard shortcut ever invented. Someone got promoted before you.

It doesn't matter.

You don't see their full picture — the years they spent on something before you met them, the things they secretly struggle with, the parts of the job they're worse at than you. The only useful comparison is with the version of you from six months ago. If that person would be impressed by where you are now, you're doing fine.

In the end, it's just a job — your health matters too

I'll be direct: no project is worth burning out for. Not the deadline, not the production incident at 11 PM, not the feature your PM "really needs by Friday."

Sleep, exercise, friends, hobbies that have nothing to do with code — these aren't distractions from your career, they're what make a long career possible. The best devs I know in their 40s and 50s all figured this out early. The ones who didn't... mostly aren't writing code anymore — they're running a goose farm somewhere.

A note for the seniors reading this

This article is for juniors, but if you're a senior or tech lead who made it this far — a quick word for you too.

Remember that you also started somewhere. Someone (hopefully) was patient with you when your PR was a mess, when you asked the "obvious" question for the third time, when you broke the build on a Friday afternoon. You didn't become a senior by accident — someone invested time in you, even when they probably didn't have it to spare.

Yes, the deadlines are tight. They're always tight. There will never be a quarter where you have plenty of free time and your juniors happen to need exactly that much mentoring. That's not how it works.

But please — don't skip the mentoring part. The 30 minutes you spend explaining why, not just what, is the highest-leverage time you'll spend all week. A junior you actually invested in becomes a mid-level dev who unblocks themselves, then a senior who unblocks others, then — eventually — the person carrying the team while you're on vacation.

Skip that investment and you'll be the bottleneck forever. Every question routes through you. Every tricky bug lands on your desk. Every architectural decision waits for your review. That's not seniority, that's just being permanently on-call for your own team.

Helping juniors isn't charity. It's the most selfish long-term move you can make. Future-you will thank present-you for it.

To anyone on my current or previous teams reading this: the stories are definitely not about you. The timing is purely coincidental. :)

If this resonated — or if you violently disagree — drop a comment or even send me mail. I'm especially curious to hear from other tech leads about what mindsets you wish your juniors had earlier.

Can AI Make Legal Work Less Painful? Join Rhett's Legal-Tech Hackathon

Team Rhett — Tue, 12 May 2026 20:29:01 +0000

Legal work is still full of manual review, scattered workflows, slow compliance checks, and unclear documentation.

At Rhett, we're exploring a simple question:

Can developers use AI to make legal execution faster, clearer, and more accessible?

That's the idea behind The Code of Law Challenge — a legal-tech hackathon by Rhett.

📅 Hackathon Dates

30–31 May 2026

🔗 Register here: rhett.legal/hackathon
🔗 Detailed Info: Brochure

Early Bird Offer: ₹799

Who Should Join?

This hackathon is for builders (students, early-career, professionals) interested in:

AI and LLMs
NLP
Open-source tools
Legal-tech
Compliance automation
Document intelligence
Workflow automation
Developer-first problem solving

Team Limit: 1-4 Max.

You do not need to be a lawyer. You need curiosity, execution, and the willingness to build something useful.

The Problem Statements

1. Contract Review & Redlining Tool

Build a tool that can review contracts such as NDAs, employment agreements, or service agreements. The tool should help users:

Identify risky, ambiguous, or non-standard clauses
Suggest improved or alternative clauses
Highlight changes in a clear redlined format
Improve contract review speed and clarity

Open stack — LLMs, RAG pipelines, rule engines, fine-tuned models, or a hybrid approach. Your call.

2. AI for Legal Governance — Open Innovation Track

Build a solution that improves legal governance using open-source technologies. Possible directions:

Compliance checklist automation
Policy review assistants
Regulatory change trackers
Legal Q&A systems
Document classification and tagging tools
Risk monitoring workflows

What We're Looking For

We care about working prototypes, clear problem definition, practical utility, and thoughtful use of open-source technologies.

The best projects will not just look impressive. They will solve a real legal or compliance problem in a way users can actually understand.

🏆 Prizes & Opportunities

₹22,000 prize pool for the top 2 winning teams
Paid internship opportunities at Rhett for standout participants
Premium workshop / certification access via LegalWiki
1-year membership to the Indian Society of AI and Law (ISAIL)
Incubation and mentorship support through HPNLU's Legal Innovation & Incubation Centre

Why This Matters

Legal systems are often slow, expensive, and difficult to navigate — especially for growing businesses and MSMEs that drive most of India's economic activity.

Developers have a real opportunity to change that. The next generation of legal tooling won't come from law firms hiring engineers. It will come from engineers who decide the friction isn't acceptable anymore.

If you're building at the intersection of AI, law, and open-source — or you've been waiting for an excuse to start — we'd love to see what you create.

Which problem would you tackle — contract redlining or open-innovation governance? Drop a comment with your stack of choice or to know more about it 👇

Living on My Own Server: An Indie Hacker's Work-Life Balance

Mustafa ERBAY — Tue, 12 May 2026 20:28:27 +0000

Living on My Own Server: An Indie Hacker's Work-Life Balance

Running my own servers has been the foundation of both my work and personal projects for years. This has provided me with incredible control and flexibility, but it has also inevitably required me to write my own rules regarding work-life balance. On this path as an "indie hacker," managing my own infrastructure has become not just a technical choice, but an integral part of my lifestyle. In this post, I will talk about the challenges and opportunities of living on my own servers and how this balance is established.

This journey didn't always start in a planned way. Initially, I moved my server room into my own home just to get better performance and more control. However, over time, I realized that this wasn't just a matter of "infrastructure," but something that deeply affected my way of life. Managing my own data center meant being in a constant state of being "on," which could blur the line between professional and personal life.

The Freedom and Responsibility of My Own Infrastructure

The biggest plus of managing my own servers is definitely freedom. I can install any software I want, configure it as I wish, and develop my projects without getting stuck in the limitations of any third-party provider. This provides an invaluable advantage, especially when I want to prototype and test new ideas quickly. Debugging processes are also more direct; I have access to every layer from hardware to software.

However, this freedom brings great responsibility. You have to constantly deal with the security, updates, backups, and potential failures of the servers. This can mean the necessity of immediate intervention in case of an alarm coming in the middle of the night or a service crash. This situation can make it difficult to fully relax even on vacations or weekends.

ℹ️ A Snippet from My Experience

Once, I received an alarm regarding PostgreSQL WAL rotation at 03:14 AM. Although it initially looked like a simple disk space issue, it was actually a bloat problem caused by WAL files being cleaned up slower than expected. Such situations require constant monitoring and rapid intervention.

The Indie Hacker's Work-Life Balance

The essence of being an "indie hacker" is to act independently and grow your own projects. While managing my own infrastructure, this independence is further reinforced. However, this is also an indicator of how difficult it has become to separate work and life. When I set up a data center in my own home, the noise and lights of the servers gave a constant sense of presence even when I wasn't working.

I had to take conscious steps to deal with this. First, I physically separated my server room from the rest of my house. By installing sound insulation and a separate air conditioning system, I both reduced the noise and ensured the servers operated in optimum conditions. This allowed me to draw a clear line between my "workspace" and my "living space."

💡 Separation of Workspace

Digital separation is just as important as physical separation. While managing my own servers, I separate the devices I use for work and my personal devices. This prevents work-oriented notifications or tasks from leaking into my personal time.

Technical Challenges and Solutions

The technical challenges I've encountered while managing my own servers are too many to count. One of them was the disk space issues I experienced, especially when dealing with container orchestration. The uncontrolled growth of Docker images and logs over time could quickly fill up server disks. To solve this problem, I implemented regular disk cleanup scripts and log rotation policies.

Another important issue was network security and segmentation. Creating separate VLANs for different projects, managing firewall rules, and securing VPN connections requires constant effort. Integrating modern approaches like Zero Trust Network Access (ZTNA) into my own infrastructure increased both the learning process and the implementation cost.

# Example of a simple log cleanup script

<figure>
  <Image src={cover} alt="A scene where a person is working in a home office among multiple monitors and server hardware." />
</figure>

import os
import glob
import time

LOG_DIR = "/var/log/my_app/"
MAX_LOG_AGE_DAYS = 7

def clean_old_logs():
    cutoff = time.time() - (MAX_LOG_AGE_DAYS * 24 * 60 * 60)
    for log_file in glob.glob(os.path.join(LOG_DIR, "*.log")):
        if os.path.getmtime(log_file) < cutoff:
            os.remove(log_file)
            print(f"Removed old log file: {log_file}")

if __name__ == "__main__":
    clean_old_logs()

This script checks files with the .log extension in the /var/log/my_app/ directory and deletes those older than 7 days. It can be run regularly using systemd timers.

Continuous Learning and Adaptation

Managing one's own infrastructure requires a continuous learning process. New security vulnerabilities emerge, software is updated, and hardware ages. To keep up with this dynamic environment, I need to constantly research, learn new technologies, and adapt my existing systems. This is an inevitable part of the "indie hacker" lifestyle.

For example, when I wanted to run AI models on my own servers, I had to deal deeply with topics like GPU resource management, memory optimization, and distributed training. Using different models and services like Gemini Flash, Groq, and Cerebras together provided me with flexibility but also increased complexity. Such projects both improve my technical skills and open new doors for me.

⚠️ Learning Curve

Every new technology or tool comes with a learning curve. Learning by trial and error on my own infrastructure can sometimes lead to costly mistakes. Therefore, for important systems, always have a fallback plan.

Conclusion: Is a Balanced Life Possible?

Living on my own servers has provided me with incredible freedom and control. As I move forward on my own path as an "indie hacker," this infrastructure has been my biggest supporter. However, this doesn't mean that the work-life balance is perfect. There is a constant need for alertness, continuous learning, and constant problem-solving.

The important thing is to establish this balance consciously. Drawing physical and digital boundaries, using automation tools effectively, and setting aside time for yourself to rest are the cornerstones of this balance. Managing your own infrastructure is not just a technical project, but also a lifestyle choice, and accepting the responsibilities that come with this choice is essential for a sustainable "indie hacker" life in the long run. Living in my own data center has brought me both freedom and responsibility; and what I've learned on this journey has gained me invaluable experiences.

Open-source multi-agent pipeline: 61K Python, 12 agents, 5 quality gates...

Alex — Tue, 12 May 2026 20:28:24 +0000

I spent the last month building an open-source (MIT) pipeline that takes a plain-language idea and runs it through 12 specialized agents — analyst, PM, architect, design critic, developer, QA, security, DevOps, marketing, and more — with 5 quality gates, a strict state machine with recovery, and an AI Director that autonomously manages the whole thing.
Think Bolt.new or Lovable, but self-hosted, MIT licensed, with quality gates that actually prevent the model from shipping broken stubs.
The interesting part isn't the LLM calls. Here's what broke in production.

LLM failover creates consistency problems
I have 6+ providers (DeepSeek, Anthropic, OpenAI, Ollama, Groq, etc.) with automatic health-check failover every 60s. The footgun: DeepSeek and Claude write different code. Same prompt, wildly different output structure. If the router switches providers mid-pipeline, the architect output (Claude) won't match what the developer agent (DeepSeek) expects.
Solution: task-level pinning. Heavy tasks (architect, developer) stay locked to the primary provider. Light tasks (marketing copy, naming) can fall back freely. I also added a model capability matrix check before routing — otherwise you get an architect running on a 7B local model producing garbage.
State machines need to survive the model being wrong
11 states, 34 valid transitions, JSON + SQLite dual persistence. Sounds solid until the model writes a corrupted artifact that crashes the state machine on the next task load.
Had to add:
Recovery fallback: if JSON parse fails, restore from SQLite snapshot
Stranded product recovery: products stuck in pm_quality_fail because the model hallucinated a non-existent file path
Async save with timeout guards so a slow disk write doesn't block the pipeline
The lesson: your state machine needs to survive both a wrong model AND a corrupted disk. Not theoretical — happened in production.
The Director AI feedback loop problem
The Director runs a 6-phase autonomous cycle: route chat → analyze metrics → generate decisions → apply actions → rank what to build next → log.
The footgun: feedback loops. Director generates a decision → applies it → next cycle reads its own output → generates another decision based on that → infinite loop. Had to add noop detection that breaks the cycle when decisions become empty.
The chat classification is also tricky. The Director classifies owner messages as new_idea, product_feedback, or general_directive via LLM. If it misclassifies "fix the login page" as new_idea, you get a duplicate product instead of a bug fix. I added an orphan feedback heuristic: if a message mentions a product name that doesn't exist yet, route to new_idea; otherwise link to the existing product.
Quality gates — what I wish I'd built first
| Gate | What it checks |
|------|---------------|
| Demo quality | 12 checkpoints: contrast, CTA, broken links, spec coverage |
| Browser E2E | Playwright crawl (desktop + mobile), JS errors, 404s |
| Visual QA | 9 heuristics: contrast ratio, CSS vars, empty states, nav |
| Security | AST scan: eval(), innerHTML, exposed tokens, hardcoded secrets |
| Methodology | Domain packs: fintech, ecomm, healthcare, etc |

Real example: visual QA flagged a white-on-white CTA button — the model generated color: white on background: white assuming a dark theme that wasn't applied. The gate caught it, sent it back to the developer with the exact CSS selector. Fixed next cycle.

Preview fidelity is pure web engineering When AI-generated code runs in a sandbox iframe, every web platform quirk amplifies: relative URLs break, is missing, CSP blocks inline styles, `target="_top"` kills navigation. Had to write a dedicated URL rewriter that: injects pointing to the correct sandbox route, rewrites absolute / links to relative, adds permissive CSP headers, strips target="_top". Not AI work. But without it, the preview is broken and users blame you, not the LLM.

61,503 Python LOC, 22,997 TypeScript/TSX LOC
12 specialized agents, 5 quality gates
11 pipeline states, 34 valid transitions
6+ LLM providers with auto-failover
72 test files, MIT licensed

Repo: github.com/alexar76/aicom — FastAPI + Next.js + Docker Compose, self-hosted, MIT, BYO API keys.

My OpenClaw agent looked idle overnight and still burned through tokens

Lars Winstand — Tue, 12 May 2026 20:26:43 +0000

I found a small but very real r/openclaw thread recently: 14 upvotes, 29 comments, and a painfully familiar question.

Why did an OpenClaw agent that looked basically idle overnight still torch the budget?

The best answer from the thread was not exotic.

It was heartbeats.

More specifically: heartbeats that keep resending a fat conversation history back through the model.

That means your agent can look asleep while still paying for context replay over and over.

If you run OpenClaw with a long-lived thread, this is probably the first thing to inspect.

The actual failure mode

A lot of people assume token burn comes from obvious work:

generating lots of code
browser automation
long reasoning chains
multi-step planning

Sometimes yes.

But the thread kept converging on a more boring answer: long sessions plus frequent heartbeats.

A simplified loop looks like this:

heartbeat -> send current state + prior conversation -> model responds -> wait -> repeat

If your session is already large, every heartbeat is expensive even when nothing interesting happened.

That means cost tracks context size, not just visible activity.

Why "idle" is not idle

OpenClaw can feel idle from the outside while still doing this internally:

while True:
    payload = {
        "system": system_prompt,
        "messages": full_conversation_history,
        "state": current_agent_state,
    }
    response = call_model(payload)
    maybe_run_tools(response)
    time.sleep(heartbeat_interval)

The problem is obvious once you write it down:

full_conversation_history keeps growing
each heartbeat resends it
cost compounds silently

That is how people wake up to a bill and think, "but the agent barely did anything."

The thread's best fix: stop keeping one immortal session alive

The most useful suggestion in the comments was not "summarize harder."

It was: use short sessions and write a handoff file.

That pattern looks more like this:

run a bounded task
write the minimum state needed for the next task
end the session
start fresh later with only the handoff

Example handoff file:

# handoff.md

Current task: finish deployment validation
Status: staging deploy succeeded
Next step: run smoke test against /health and /login
Known issue: flaky timeout on user-profile endpoint
Files touched:
- deploy.sh
- smoke_test.py

Then the next session can start with a much smaller prompt:

Read handoff.md and continue from there.
Do not reconstruct old discussion unless required.
Current goal: run smoke tests and report failures.

That is less magical than persistent memory.

It is also usually cheaper.

Why aggressive compaction is not a silver bullet

The tempting answer is to summarize the thread every so often.

That can help, but the Reddit discussion was right to be skeptical about doing it constantly mid-task.

Because the real flow becomes:

read the giant thread
generate a summary
read the summary on the next call
discover something important got dropped
spend more tokens recovering context

That is often just a second conversation about the first conversation.

For active coding or debugging work, losing one detail can be enough to trigger expensive repair loops.

Better architecture beats better prompting

The smartest part of the discussion was this: stop making the model do deterministic work.

If a job can be handled by Python, bash, cron, or n8n, do that.

Use the model for judgment, not polling.

Bad pattern

One always-on OpenClaw agent:

checks files
polls APIs
watches logs
decides if anything changed
keeps a giant context alive

Better pattern

Small background jobs do the boring work.

Only wake the agent when there is something worth reasoning about.

Example with cron:

*/15 * * * * /usr/bin/python3 /opt/check_build_status.py
0 * * * * /usr/bin/python3 /opt/check_error_budget.py

Example notifier script:

# check_build_status.py
import json
import subprocess
from pathlib import Path

state_file = Path("/tmp/build_state.json")
current = {"build_failed": False, "new_error": True}
previous = json.loads(state_file.read_text()) if state_file.exists() else {}

if current != previous and current.get("new_error"):
    subprocess.run([
        "python3",
        "wake_openclaw.py",
        "Build state changed. Investigate latest CI failure."
    ])

state_file.write_text(json.dumps(current))

This is a much better use of an LLM:

scripts gather facts cheaply
cron handles repetition cheaply
OpenClaw gets called only when reasoning is needed

Model tiering is the boring answer that actually works

Another good point from the thread: stop paying premium model prices for maintenance tasks.

If your heartbeat, orchestration, or lightweight routing is using Claude Opus or GPT-5 every time, you are probably overspending.

A practical split looks like this:

Task	Better default
Heartbeats / lightweight orchestration	Qwen 9B, DeepSeek, or another cheap model
Normal coding / planning	Claude Sonnet
High-stakes reasoning	Claude Opus or GPT-5
Local compression / summarization	Granite 3B, Llama, or another local model

Example config:

heartbeat_interval: 1h
orchestrator_model: qwen-9b
heavy_reasoning_model: claude-sonnet
mission_critical_model: gpt-5
local_compression_model: granite-3b
session_rule: "end task -> write handoff.md -> start fresh session"

That setup is not glamorous.

It is just sane.

Practical debugging checklist for OpenClaw token burn

If your bill feels wrong, I would check these in order:

1. Measure heartbeat frequency

If your agent is checking in every few minutes, stretch it out.

Start with 1 hour for anything non-urgent.

2. Inspect payload size

Log how much context is being sent per call.

Even rough logging helps.

def estimate_chars(messages):
    return sum(len(m.get("content", "")) for m in messages)

print("context_chars=", estimate_chars(full_conversation_history))

3. Kill long-lived threads

If a task is done, end the session.

Do not keep dragging old context forward just because it feels convenient.

4. Replace repetitive reasoning with scripts

If the model is repeatedly checking a condition, that is probably script territory.

5. Tier your models

Cheap model for maintenance.
Expensive model for hard calls.

6. Use local summarization if you need compression

If you really must compact context, a local model can be a good tradeoff.

A concrete OpenClaw workflow that is harder to bankrupt

Here is a pattern I would recommend for a lot of OpenClaw setups:

cron/script layer
  -> checks deterministic conditions
  -> writes structured state files
  -> wakes OpenClaw only on change

OpenClaw session
  -> reads latest state file + handoff.md
  -> performs bounded reasoning task
  -> writes result + next-step handoff
  -> exits

State file example:

{
  "service": "billing-api",
  "deploy_status": "failed",
  "failed_step": "database migration",
  "timestamp": "2026-05-12T02:10:00Z"
}

Prompt example:

Read state.json and handoff.md.
Determine the most likely cause of the failed migration.
Suggest the smallest safe fix.
Do not re-check unrelated systems.

This keeps the model focused and keeps your context small.

The bigger issue is not just cost, it is behavior

Per-token billing changes how people build.

Once you get burned a couple times, you start doing weird things:

cutting prompts too aggressively
avoiding retries
reducing monitoring
limiting experiments
shutting down useful background loops

That is not just a billing problem.

It changes the architecture of the system because you are designing around fear.

For OpenClaw users running always-on agents, that gets old fast.

This is exactly why Standard Compute is interesting here.

Instead of paying per token and constantly wondering whether a sleepy-looking agent is secretly expensive, you get flat monthly pricing through an OpenAI-compatible API with routing across models like GPT-5, Claude Opus, and Grok.

If you are building persistent OpenClaw automations, that changes the optimization target.

You can optimize for reliability and output quality instead of constantly asking, "is this heartbeat worth the money?"

That does not remove the need for good architecture.

You should still shorten sessions, use handoff files, and move deterministic work into scripts.

But it does remove a lot of the token anxiety that makes people underbuild useful agents.

My take

The main lesson from that Reddit thread was simple:

The problem usually is not that your OpenClaw agent is too smart.

It is that the session shape is wrong.

If you keep one giant thread alive, heartbeats turn context into a recurring tax.

If you switch to:

longer heartbeat intervals
bounded sessions
handoff files
scripts and cron for repetitive work
model tiering

then the bill usually gets more predictable very quickly.

And if you are tired of per-token pricing shaping every design decision, use infrastructure that is built for always-on agent workloads instead of fighting the meter all night.

That is the real fix: better architecture first, better pricing model second.

Both matter.

DEV Community

Context in Context: Why AI Tools Degrade Over Longer Work Sessions

Context in Context: Why AI Tools Degrade Over Longer Work Sessions

The 30-Second Explanation

Why This Hits Your Bottom Line

...And You Can't Even Use ALL of It

The Real Business Impact

The Insight That Separates Winners from Strugglers

What Good Looks Like

The Hidden Tax on Every Session

Warning Signs Your Team Has Context Problems

Five Questions for Your Next Leadership Meeting

Relief Is Coming Soon (But Not Here Just Yet)

The Bottom Line

Use Data Stores In Application Development | 🏗️ Build A Product Catalog API

📘 Concepts

DynamoDB Key Concepts

Primary Keys

Partition Key Selection

Consistency Models

Query vs Scan

Global Secondary Index (GSI) vs Local Secondary Index (LSI)

GSI Projection Types:

Caching Options

Specialized Data Stores

Data Lifecycle

DynamoDB TTL

S3 Lifecycle Policies

🏗️ Build A Product Catalog API

Prerequisites

Part I

Design the DynamoDB Table

Our Access Patterns

Create the Table

Add a Global Secondary Index

Why This Design?

Part II

Add Sample Data

Using the Console

Part III

Query vs Scan

Query (Efficient)

Scan (Expensive)

Query the GSI

Part IV

Build the API with Lambda

Create the Lambda Function

Part V

Consistency Models

See the Difference

When to Use Each

Part VI

TTL: Automatic Data Expiration

Enable TTL

Part VII

Caching with DAX

When to Use DAX

How DAX Works

Console Walkthrough (Don't Create.Just Understand)

🏗️ What You Built | 📘Exam Concepts Recap

⚠️ Clean Up Protocol

Key Takeaways

Additional Resources

Stop Sharing Prompts — Start Shipping Claude Plugins

The first solution, the obvious one, doesn't work for everyone

The real solution: a repository as a marketplace

How?

1. Create the repository

2. The marketplace.json file

3. The plugin.json file

4. A skill example

5. A command example

6. Import from Cowork

7. Import from Claude Code

8. Update flow

The result

Introduction to Dinghy: a Swiss-army knife for everyday engineering

What it is

From a DevOps engineer's bench

How it is shaped

2. The `marketplace.json` file

3. The `plugin.json` file