Coder Legion - Recent posts tagged claudecode

Claude Code For Free Unlimited: Local Setup with Ollama + Qwen 3.8

Thu, 29 Oct 2026 09:15:58 +0000

Run Claude Code for FREE Unlimited on your own PC: no API key, no subscription, no bill. In this 5-minute setup, I connect Claude Code to Qwen 3.8 running locally with Ollama, all with ONE command, then build a full game to prove it works.

⚡ What you'll learn

✅ How To Install Claude Code and Ollama (Windows, Mac & Linux)
✅ How to Use QWEN 3.8 with Ollama?
✅ How to fix Model Not Found Claude Code Error
✅ How to build a full project with Claude Code Free
✅ Claude Code Settings for Windows

⏱️ Chapters
0:00 Claude Code for free?
0:39 System Requirement for Running Claude Code Free
1:50 The 4-step plan
2:10 Install Claude Code & Ollama
3:20 The magic command
4:00 Live build: one prompt, full snake game
7:45 Quick fixes + next video

💻 Commands used
Install Claude Code (Mac / Linux / WSL):
curl -fsSL https://claude.ai/install.sh | bash

Install Claude Code (Windows PowerShell):
irm https://claude.ai/install.ps1 | iex

Install Ollama (Mac / Linux):
curl -fsSL https://ollama.com/install.sh | sh
Windows: download the installer from https://ollama.com

Check Ollama version (needs 0.15+):
ollama --version

Download the model (about 18 GB):
ollama pull qwen3.8:27b

🖥️ Recommended specs
• 32 GB total memory (RAM + GPU)
• 24 GB GPU for a smooth experience (or Apple Silicon Mac, 32 GB+)
• 20 GB free disk space

🔗 Links

🔗 Full walkthrough: https://thecodestreet.dev/post/claude-code-for-free-ollama-qwen
🔗 Ollama: https://ollama.com
🔗 Claude Code docs: https://code.claude.com/docs

📺 Next video: Claude Code FREE inside VS Code. Subscribe so you don't miss it!

👋 I'm Rajiv from The Code Street. I make practical videos on AI coding tools and building real apps.

Subscribe: https://youtube.com/@thecodestreet

Claude Code Design Canvas: Every Screen of Your App From One Prompt

Mon, 26 Oct 2026 12:01:37 +0000

Claude Code can turn one plain-language request into a design canvas where every screen of your app is a live, editable artboard, not a screenshot. In this video I show what the canvas is, what happens after you hit Enter, how to ask for it in an existing repo and in a project that doesn't exist yet, and five tips that turn a generic result into a useful first draft, including a full prompt you can copy.

📝 Full article: https://dev.to/soaresdiogo/from-one-p...
📸 Instagram: / diogosoares.dev
💼 LinkedIn: / diogoschmidtsoares
🌐 Website: https://diogosoares.dev

How to Use Claude Code with Opus 5.5 & Fable 5.1 for Free (No Card Required)

Mon, 26 Oct 2026 10:35:51 +0000

Want to use Claude Code with top models like Claude Opus 5.5 and Fable 5.1, but don't want to pay for a subscription or fund an API account yet?

In this guide, I'll show you how to connect Claude Code to a third-party AI gateway that gives you 500,000 free tokens every month, with no credit card required. The setup takes about five minutes.

⚠️ Before you start: This uses a third-party service that is not affiliated with or endorsed by Anthropic. Free plan limits, available models, and pricing can change at any time. Read the disclaimer at the end before you use it for anything serious.

🎥 Watch the Video Tutorial

Prefer watching? Here's the full step-by-step walkthrough:

{% youtube W5clGOuOySI %}

What You Get

Feature	Details
Free tokens	500,000 per month
Credit card	Not required
Models	Claude Opus 5.5, Fable 5.1, and more
Works with	Claude Code (via third-party inference)
Best for	Learning, side projects, prototyping

How much is 500K tokens?

A token is a small chunk of text, often part of a word. A common rule of thumb for English:

1 token ≈ 4 characters ≈ ¾ of a word
1,000 tokens ≈ 750 words
500,000 tokens ≈ 375,000 words
Input and output both count. Coding sessions also send file contents and conversation history as context, so a long agentic session uses more than you might expect. Still, 500K a month is plenty for learning and for several small projects.

Why Use Claude Code with Free Tokens?

Students and beginners can learn AI-assisted coding at zero cost.
Indie developers can prototype ideas without upfront spend.
Curious developers can try premium models like Opus 5.5 before committing to a paid plan.
Content creators and educators can demo Claude Code without burning a personal budget.

Claude Code & Cursor: Why Your AI Agent Lies to You (And Our 3-Tier Adversarial Tribunal Skill)

Fri, 16 Oct 2026 18:36:10 +0000

Last Tuesday at 2:14 AM, my autonomous coding agent proudly handed me a Python webhook ingestion worker and gave itself a 98/100 confidence score.

"Production-ready, fully idempotent, and resilient to network partitions," it assured me.

Ten minutes later, under a simulated 50x concurrency spike, that same worker deadlocked two Redis streams, silently dropped 14% of the batch during a mid-transaction timeout, and swallowed the exception because it had wrapped the entire handler in a broad fallback block.

If you build with AI coding agents (Hermes Agent, Claude Code, Cursor, OpenCode), you already know this pain. The problem isn't that frontier LLMs lack engineering knowledge. The problem is First-Draft Sycophancy.

Here is why asking an AI to "review its own code" fails by design—and how I open-sourced critic-refine v1.1.0, a 3-tier adversarial verification skill that forces your agent into a ruthless internal tribunal before it writes a single line of production code.

👉 GitHub Repository (MIT): manny-ruesch/critic-refine-skill

1. The Anatomy of "First-Draft Sycophancy"

When you ask an LLM to solve a complex system design or concurrency problem in a single pass, two cognitive traps trigger immediately:

Retroactive Rationalization: Autoregressive models commit to an architectural path within the first 150 tokens. Once the function signatures and boilerplate start streaming, the model spends the rest of its attention budget justifying why its initial choice is right.
Confirmation Bias in Self-Review: When you prompt "Now review your code for bugs," the model reads its own newly generated boilerplate alongside its own persuasive explanations. It falls in love with its own prose and rubber-stamps the output (LGTM!).

To get genuine staff-level engineering out of an agent, you have to break the single-persona loop.

2. Enter `critic-refine` v1.1.0: The 3-Tier Adversarial Engine

Instead of letting the agent jump straight into writing verbose code, critic-refine hijacks the cognitive workflow and enforces a strict 3-phase adversarial tribunal inside the model's reasoning space (or across isolated sub-agents):

+-------------------------------------------------------------------------+
| PHASE 1: THE GENERATOR (Dense Logical Blueprint v1)                     |
| -> Function signatures, state structs, concurrency locks, SQL/API flow  |
| -> Zero boilerplate, zero comments — preserves context window attention |
+------------------------------------+------------------------------------+
                                     |
                                     v
+-------------------------------------------------------------------------+
| PHASE 2: THE POLYMORPHIC CRITIC (Ruthless Domain Inspection)            |
| -> Dynamically instantiates the harshest domain persona:                |
|    (Principal Rust Systems Eng, Staff DBA, Lead SecOps, DistSys Arch)   |
| -> Anti-Complacency Rule: FORBIDDEN from approving Draft v1 as-is       |
| -> Must surface >= 3 concrete failure vectors (race conditions, O(n^2), |
|    partial network partitions, memory leaks, API hallucinations)        |
| -> Optional `mode:<focus>` allocates 80% of attack surface to 1 axis    |
+------------------------------------+------------------------------------+
                                     |
                                     v
+-------------------------------------------------------------------------+
| PHASE 3: THE ARBITRATING JUDGE (Mental Dry-Run & Deductive Scoring)     |
| -> Simulates hostile execution (null payloads, 100x concurrency spike,  |
|    mid-transaction disk crash)                                          |
| -> Patches the architecture (up to 2 internal feedback loops)           |
| -> Explicitly documents every technical trade-off sacrificed            |
| -> Applies a strict deductive rubric starting from 100 pts              |
+-------------------------------------------------------------------------+

Why Phase 1 Forbids Boilerplate

If the Generator writes 300 lines of boilerplate in Phase 1, it pollutes the context window and anchors the Critic. By forcing Draft v1 to be a dense logical blueprint (only signatures, lock boundaries, state transitions, and query complexity), the Critic has nowhere to hide and can attack pure architecture.

The Anti-Complacency Rule

In Phase 2, the Polymorphic Critic is explicitly forbidden from validating Draft v1 as-is. Whether it adopts the persona of a Staff DBA inspecting lock escalation or a Lead SecOps Pentester auditing JWT middleware, it must identify at least 3 concrete failure vectors before Phase 3 can begin.

3. Killing Confirmation Bias: The "Zero-Context Blind Audit"

What happens when you are refactoring 3 or more files across a repository? Even an internal scratchpad can suffer from context bleed.

In v1.1.0, when critic-refine detects >= 3 impacted files (or when you pass the deep flag), it triggers a Zero-Context Blind Audit via delegate_task:

It spawns an isolated sub-agent for the Critic.
It passes ONLY the user's original prompt and the raw Draft v1 blueprint.
It strips out all of the Generator's justifications and reasoning.

Because the sub-agent Critic has zero emotional or contextual attachment to why the code was written that way, it tears the blueprint apart like a real adversarial code review.

4. The Anti-Sycophancy Deductive Rubric

Ever notice how LLMs always rate their own solutions 95/100 or 98/100?

In critic-refine v1.1.0, the Arbitrating Judge is banned from inventing arbitrary "vibes-based" scores. It starts at 100 points and must apply a strict mathematical deduction:

-5 pts per unverified environment or infrastructure assumption (e.g., assuming Redis is configured with noeviction).
-5 pts per non-isolated critical external dependency.
-10 pts per edge case delegated to the caller instead of handled in-module.

Furthermore, every single flaw caught by the Critic must be mapped 1:1 to its exact fix in the final output:

[Concurrency] : Unbounded asyncio.gather on webhook batch risks exhausting DB connection pool under 100x spike → Injected asyncio.Semaphore(20) + exponential jitter backoff on pool acquisition.

5. The Complete `SKILL.md` Specification (v1.1.0)

You can drop this directly into Hermes Agent (~/.hermes/skills/software-development/critic-refine/SKILL.md), Claude Code (.claude/commands/critic-refine.md), or Cursor (.cursor/rules/):

---
name: critic-refine
description: "High-rigor 3-tier adversarial verification workflow (Generator, Polymorphic Critic, Judge). Trigger automatically on critical code, distributed architecture, concurrency, security-sensitive logic, complex algorithms, strategic technical trade-offs, or when the user invokes 'critic-refine', 'deep', or 'mode:<focus>'."
version: 1.1.0
author: Manny, Hermes Agent
license: MIT
platforms: [linux, macos, windows]
metadata:
  hermes:
    tags: [critic, debate, multi-agent, verification, audit, quality, trade-offs]
---

# Critic-Refine Skill (v1.1.0)

Workflow d'assurance qualité extrême simulant un comité d'experts adversariaux (Rédacteur, Critique Polymorphe, Juge Arbitre) pour délivrer des solutions certifiées niveau production.

## Protocole d'Exécution Interne (Le Moteur Adversarial 3-Tiers)

1. **Phase 1 : L'Agent Rédacteur (Blueprint Logique v1)** — Formalise un *Blueprint technique dense* (signatures, structures d'état, concurrence, flux algorithmiques) sans boilerplate.
2. **Phase 2 : Le Critique Polymorphe (Inspection Impitoyable Ciblée)** — Instancie l'expert le plus intransigeant du domaine. Concentre 80% de l'audit sur `mode:<critère>` si spécifié. **Interdiction formelle de valider le Draft v1 tel quel** : identifie au minimum 3 vecteurs de défaillance concrets.
3. **Phase 3 : Le Juge Arbitre (Dry-Run, Patching et Compromis)** — Simule l'exécution avec des entrées hostiles (null, débordements, pic 100x, crash disque à mi-transaction), applique les patchs (max 2 boucles) et explicite les compromis.
4. **Mode Sous-Agents Isolés (`delegate_task` — Deep-Dive)** — Si `>= 3 fichiers` ou flag `deep`, lance un **Zero-Context Blind Audit** en ne transmettant que le besoin initial et le Draft v1 sans les justifications du Rédacteur.

(Full French and English documentation available in the GitHub repo).

🧪 Put It to the Test (I Want Your Feedback!)

I open-sourced critic-refine v1.1.0 today under the MIT License because I want to see where it breaks and how we can make the tribunal even sharper.

Install it in 10 seconds:

mkdir -p ~/.hermes/skills/software-development/critic-refine
curl -sL https://raw.githubusercontent.com/manny-ruesch/critic-refine-skill/main/SKILL.md \
  -o ~/.hermes/skills/software-development/critic-refine/SKILL.md

I’d love your feedback in the comments or via GitHub Issues:

Throw your nastiest prompt at it (distributed locks, race conditions, auth middleware) using /critic-refine mode:security or /critic-refine mode:low-latency—what flaws did the Polymorphic Critic catch that a normal prompt missed?
The Deductive Rubric: Are -5 / -5 / -10 the right penalties, or what other architectural sins should automatically dock points from the Judge's score?

🔗 Star, fork, or roast the skill on GitHub: https://github.com/manny-ruesch/critic-refine-skill

Claude Haiku 5.5 Pricing: Stay Under the 100K-Token Price Cliff

Mon, 12 Oct 2026 12:30:26 +0000

Claude Haiku 5.5 shipped on October 7, 2026 with a headline price of $0.10 per million input tokens and $0.50 per million output tokens, a tenth of the per-token price of Claude Haiku 4.5. The headline has a condition. Those prices apply to requests whose prompt is up to 100,000 tokens. A request with a longer prompt is billed at $0.50 and $2.50, and the higher prices cover the whole request, not only the tokens past the line.

So a 100,000-token prompt costs one cent of input and a 100,001-token prompt costs five. Three things about the model push existing workloads toward that line: a tokenizer that counts the same text as roughly 30% more tokens, thinking blocks that now stay in the conversation, and a context window five times the old one, which makes long prompts easy to send.

This article covers how the threshold is counted, why prompts that were comfortable on Haiku 4.5 can land on the wrong side of it, and the code that keeps requests under it: a cost function, a pre-flight check, a retrieval packer and a context-editing setup for agent loops. The numbers come from Anthropic's documentation as read on October 12, 2026, and the code uses the official anthropic Python SDK.

The short answer

Haiku 5.5 has two price lists. Prompts up to 100,000 tokens pay $0.10 input and $0.50 output per million tokens. Prompts over 100,000 pay $0.50 and $2.50. Every line item in the second list is exactly 5× the first.
The second list applies to the entire request, including its output tokens and its cache reads.
Prompt length is input_tokens + cache_creation_input_tokens + cache_read_input_tokens. A cache hit does not keep a request under the line.
The same text is about 30% more tokens than on Haiku 4.5, so a prompt that measured around 77,000 tokens there is close to the threshold here.
Token counting is free. Count before you send, and keep a margin.
In agent loops, set tool-result clearing to trigger below 100,000. Its default trigger is exactly 100,000.

How Claude Haiku 5.5 pricing works

These are the prices on the pricing page, per million tokens:

	Prompt up to 100,000 tokens	Prompt over 100,000 tokens	Claude Haiku 4.5 (any length)
Input	$0.10	$0.50	$1
5-minute cache write	$0.125	$0.625	$1.25
1-hour cache write	$0.20	$1	$2
Cache read	$0.01	$0.05	$0.10
Output	$0.50	$2.50	$5
Batch API, input / output	$0.05 / $0.25	$0.25 / $1.25	$0.50 / $2.50

And this is the rule, quoted from the same page:

A request's prompt length counts all of its input tokens, including cache reads and cache writes. Each request is priced on its own: a request over the threshold pays the higher prices even when part of its prompt is a cache hit, and earlier requests keep the prices they were billed at.

Anthropic's cost guide puts it in one clause: a request over the threshold "pays the higher prices for all of its tokens".

Three consequences follow.

It is a step, not a marginal rate. A tax bracket charges the higher rate only on the amount above the bracket. This charges it on everything. Trimming a 120,000-token prompt to 100,000 removes 17% of the tokens and 83% of the input cost: $0.060 becomes $0.010.

Output is priced by the prompt's tier. Output tokens don't count toward the 100,000, but a long prompt makes every output token cost 5×, and thinking is billed as output.

Nothing is retroactive. A conversation that grows past the line pays more from that request on. The turns before it keep their price.

Haiku 5.5 is the only model in the current lineup priced this way. The other models with a 1M-token context window bill long prompts at their standard rate.

Here is the rule as code. Prices are strings turned into Decimal, and since $X per million tokens is X micro-dollars per token, the arithmetic stays exact:

from decimal import Decimal

THRESHOLD = 100_000  # prompt tokens; "up to 100,000" is still the lower tier

# USD per million tokens, from platform.claude.com/docs/en/about-claude/pricing
# (checked 2026-10-12). This is configuration: reload it when prices change.
# Standard API with global routing: the Batch API halves these, and
# inference_geo "us" multiplies them by 1.1.
HAIKU_5_5 = {
    "short": {"input": "0.10", "write_5m": "0.125", "write_1h": "0.20", "read": "0.01", "output": "0.50"},
    "long":  {"input": "0.50", "write_5m": "0.625", "write_1h": "1.00", "read": "0.05", "output": "2.50"},
}


def prompt_tokens(usage: dict) -> int:
    """Prompt length as the pricing rule defines it: every input token, cached or not."""
    return (
        usage.get("input_tokens", 0)
        + usage.get("cache_creation_input_tokens", 0)
        + usage.get("cache_read_input_tokens", 0)
    )


def price_haiku_5_5(usage: dict) -> tuple[str, Decimal]:
    """Return (tier, cost in USD) for one request, priced on its own."""
    tier = "long" if prompt_tokens(usage) > THRESHOLD else "short"
    p = {k: Decimal(v) for k, v in HAIKU_5_5[tier].items()}
    write_1h = usage.get("cache_creation_1h_input_tokens", 0)
    write_5m = usage.get("cache_creation_input_tokens", 0) - write_1h
    micro_usd = (
        usage.get("input_tokens", 0) * p["input"]
        + write_5m * p["write_5m"]
        + write_1h * p["write_1h"]
        + usage.get("cache_read_input_tokens", 0) * p["read"]
        + usage.get("output_tokens", 0) * p["output"]
    )
    return tier, micro_usd / Decimal(1_000_000)


for n in (100_000, 100_001):
    print(n, *price_haiku_5_5({"input_tokens": n, "output_tokens": 1_000}))
# 100000 short 0.0105
# 100001 long 0.0525005

One token moved the request from about one cent to about five.

What counts toward the 100,000-token threshold

Everything in the prompt counts: the system prompt, tool definitions, every message, images and PDFs, tool results, and the thinking blocks of earlier assistant turns.

The response's usage object splits the prompt into three fields, and the prompt caching docs give the total as cache_read_input_tokens + cache_creation_input_tokens + input_tokens. Don't check input_tokens alone. It holds only the tokens after the last cache breakpoint, and in a well-cached application it is a small number that says nothing about the tier.

Caching is where the rule surprises people. Take a request that reads 98,000 tokens from the cache, adds 2,000 new ones and returns 500:

print(*price_haiku_5_5({"cache_read_input_tokens": 98_000, "input_tokens": 2_000, "output_tokens": 500}))
# short 0.00143
print(*price_haiku_5_5({"cache_read_input_tokens": 98_000, "input_tokens": 2_001, "output_tokens": 500}))
# long 0.0071505

Prompt caching lowers what each token costs on either side of the line. It does not move the line.

Output tokens of the current request don't count. They become input on the next turn, which is how a conversation crosses the threshold a few turns after you looked.

Why prompts that fit on Claude Haiku 4.5 land over the line

The migration guide lists three changes that raise the token count of the same request.

The tokenizer. Haiku 5.5 uses the tokenizer introduced with Claude Opus 4.7, and "the same input text produces approximately 30% more tokens on Claude Haiku 5.5 than on Claude Haiku 4.5. The exact increase depends on the content." Divide 100,000 by 1.3 and you get about 77,000: a prompt of that size by Haiku 4.5's count is near the threshold on Haiku 5.5. Treat that as a reason to recount, not as a conversion factor.

Thinking blocks stay in context. "Thinking blocks from earlier assistant turns stay in context and count as input tokens, where Claude Haiku 4.5 kept only the latest turn's." Adaptive thinking is on by default, so a multi-turn conversation grows faster than the tokenizer alone explains.

Large images cost more. Haiku 5.5 uses the high-resolution image tier. Per the guide, an image of 2,000 by 1,500 pixels costs about 2.5 times as many visual tokens as on Haiku 4.5.

None of this makes the migration a bad deal. Assuming the 30% figure, the same text costs about 87% less to send than on Haiku 4.5 when the request stays under the threshold (1.3 × $0.10 against $1) and about 35% less when it doesn't (1.3 × $0.50 against $1). The threshold decides which of those two savings you get. The output side needs measuring rather than arithmetic, because thinking is now on by default, where Haiku 4.5 ran without it unless you enabled it, and thinking is billed as output.

Measuring is one function. The token counting endpoint counts under the tokenizer of the model you pass, so count each request twice:

import anthropic

client = anthropic.Anthropic()


def recount(request: dict) -> dict:
    """Count one request (system / tools / messages) under both tokenizers."""
    old = client.messages.count_tokens(model="claude-haiku-4-5", **request).input_tokens
    new = client.messages.count_tokens(model="claude-haiku-5-5", **request).input_tokens
    return {"haiku_4_5": old, "haiku_5_5": new, "ratio": round(new / old, 3), "over": new > 100_000}

Run it over a sample of real production requests, the largest ones first, and look at two things: the ratio for your content, and how many requests come back with over set.

Count before you send

Token counting is free and has its own rate limit, separate from the Messages API: 5,000 to 20,000 requests per minute depending on usage tier. Two details from its documentation shape the guard.

The count "is an estimate. In some cases, the actual number of input tokens used when creating a message might differ by a small amount." A request counted at 99,990 could land on either side, so keep a margin.

The endpoint rejects requests that include server tools such as web search or code execution, the MCP connector, and images or documents passed by URL or file ID. Images and PDFs can be counted when you send them as base64. For requests with server tools or MCP servers, the only number you get is usage on the response, after the fact.

MODEL = "claude-haiku-5-5"
SAFETY_MARGIN = 2_000   # the count is an estimate; leave room for drift


def count(request: dict) -> int:
    """request holds system / tools / messages exactly as you would send them."""
    return client.messages.count_tokens(model=MODEL, **request).input_tokens


def tier_before_sending(request: dict) -> str:
    n = count(request)
    if n <= THRESHOLD - SAFETY_MARGIN:
        return "short"
    if n <= THRESHOLD:
        return "borderline"   # could be billed either way: shrink it or accept the risk
    return "long"

A request that comes back long has three honest options: send less context, split the work, or send it as it is because the task needs it. The next two sections cover the first two. The third has its own section further down, on when the long-prompt price is the right price.

Retrieval and document jobs: pack to a budget, split instead of stuffing

With a 1M-token window it is tempting to pass every retrieved chunk. On Haiku 5.5 the budget that matters is 100,000, so pack to it. Store each chunk's token count at indexing time, measured with the model you will call, and add chunks in rank order until the next one doesn't fit:

SYSTEM = "Answer from the documents. Say so when they don't contain the answer."


def build_request(question: str, chunks: list[str]) -> dict:
    docs = "\n\n".join(f"<document>\n{c}\n</document>" for c in chunks)
    return {"system": SYSTEM, "messages": [{"role": "user", "content": f"{docs}\n\n{question}"}]}


def pack(question: str, ranked: list[tuple[str, int]], budget: int = THRESHOLD - SAFETY_MARGIN) -> dict:
    """ranked: (chunk_text, token_count) pairs, best first."""
    used = count(build_request(question, []))
    chosen: list[str] = []
    for text, tokens in ranked:
        if used + tokens > budget:
            break
        chosen.append(text)
        used += tokens
    request = build_request(question, chosen)
    while chosen and count(request) > budget:   # per-chunk counts don't add up exactly
        chosen.pop()
        request = build_request(question, chosen)
    return request

The stored counts make the loop cheap, and the final count() catches the difference between a sum of parts and the assembled prompt.

For a single large document, compare stuffing with splitting. A 250,000-token document with a 2,000-token answer costs $0.130 as one request. Split into three parts of about 84,000 tokens, each returning 1,000 tokens, it costs $0.0267, and a final request that merges the three partial answers (about 4,000 tokens in with its instructions, 2,000 out) adds $0.0014. That is about 78% less for the same input.

Splitting only works when the task decomposes: extraction, classification, per-section summaries. A question that needs two distant parts of the document in view at once loses accuracy when you split it, and no price difference fixes a wrong answer.

The Batch API halves both price lists and keeps the threshold: $0.05 and $0.25 per million tokens under it, $0.25 and $1.25 over it.

Agent loops: the cliff arrives mid-run

An agent re-sends its growing history on every step. With prompt caching that is cheap, until the history passes 100,000 tokens. From that step on, every request pays the second price list, cache reads included, and it keeps paying until the context shrinks.

The size of the effect depends on the run length, so here is a model you can change. It assumes 8,000 tokens of system prompt, tools and task, and a step that appends a 3,000-token tool result and a 500-token assistant turn (its output, thinking included), with the history cached incrementally. With a trigger, tool results older than the last four are cleared once the prompt passes it. Two simplifications: a cleared result counts as zero tokens, although the API leaves placeholder text in its place, and the clearing request is charged as a full cache rewrite, the worst case:

def simulate(steps: int, fixed: int = 8_000, tool_result: int = 3_000, out: int = 500,
             trigger: int = 0, keep: int = 4) -> dict:
    results: list[int] = []   # live tool-result sizes, oldest first
    turns = 0                 # assistant turns in history, `out` tokens each
    cached = 0                # tokens already in the cache
    total = Decimal(0)
    long_steps = 0
    for _ in range(steps):
        prompt = fixed + sum(results) + turns * out
        cleared = False
        if trigger and prompt > trigger and len(results) > keep:
            results = [0] * (len(results) - keep) + results[-keep:]
            prompt = fixed + sum(results) + turns * out
            cleared = True
        read = 0 if cleared else cached
        tier, cost = price_haiku_5_5({
            "cache_read_input_tokens": read,
            "cache_creation_input_tokens": prompt - read,
            "output_tokens": out,
        })
        total += cost
        long_steps += tier == "long"
        cached = prompt
        results.append(tool_result)
        turns += 1
    return {"steps": steps, "steps_over_100k": long_steps, "usd": round(total, 4)}

Steps in the run	No context management	Clearing at 75,000 tokens
25	$0.0293, no step over the line	$0.0300
40	$0.1553, 13 steps over	$0.0516
60	$0.4018, 33 steps over	$0.0862

The unmanaged run crosses the line at step 28, and from there the gap widens: 3× at 40 steps, 4.7× at 60. At 50,000 sixty-step runs a month, that is about $20,100 against $4,300. This is arithmetic on published prices with invented workload numbers, not a benchmark, so put your own step sizes in.

A run that never reaches the line gains nothing from clearing and pays for the cache rewrite: about 2% more in this model. Real runs can do worse. The cost guide quoted earlier reports a short agent run on which context editing cost 74% more and a long one on which it changed nothing. Removing tokens is rarely a saving in itself. In this model about 94% of the gain comes from keeping every step on the first price list, and the rest from smaller cache reads.

The mechanism behind the right-hand column is context editing, a beta feature that clears old tool results on the server before the prompt reaches the model:

response = client.beta.messages.create(
    model="claude-haiku-5-5",
    max_tokens=8_000,
    system=AGENT_SYSTEM,
    tools=TOOLS,
    messages=messages,   # your full, unmodified history
    betas=["context-management-2025-06-27"],
    context_management={
        "edits": [
            {
                "type": "clear_tool_uses_20250919",
                "trigger": {"type": "input_tokens", "value": 75_000},
                "keep": {"type": "tool_uses", "value": 4},
                "clear_at_least": {"type": "input_tokens", "value": 20_000},
            }
        ]
    },
)

Four details matter here.

Set the trigger yourself. The default trigger is 100,000 input tokens, which is exactly Haiku 5.5's price line. I haven't found a statement in the documentation on whether the tier is decided by the prompt's size before or after clearing, so don't let the bill depend on it. Pick a lower value, with enough headroom that what clearing leaves behind still fits: the system prompt, the kept tool results and the assistant turns. To preview the result, pass the same betas and context_management to client.beta.messages.count_tokens(): it returns the count after clearing as input_tokens and the count before as context_management.original_input_tokens.

Clearing breaks the prompt cache. Per the documentation, tool result clearing invalidates cached prompt prefixes when content is cleared, and clear_at_least exists so that each invalidation removes enough tokens to be worth it. If the API can't clear that much, the strategy is not applied, so watch context_management.applied_edits on the response for runs where nothing gets cleared.

Old thinking blocks can be cleared too. The clear_thinking_20251015 strategy keeps only the last N turns' thinking when you set keep to {"type": "thinking_turns", "value": N}. On Haiku 5.5 its default is to keep all of them. When you combine it with tool-result clearing it must come first in edits, and clearing thinking also invalidates the cache from that point.

Don't trim history on the client. On Haiku 5.5, a request that sends a thinking block back after a change to system, tools or earlier messages returns a 400 error, unless you opt into having the invalidated blocks dropped. Accounts created before August 31, 2026 get the error only when they set thinking.block_binding.prefix_mismatch_behavior. The classic sliding window that drops the oldest messages is exactly that kind of change. Server-side context management "never invalidates thinking blocks", which is the reason to prefer it. When clearing tool results isn't enough, compaction, also in beta, replaces older turns with a summary written on the server.

Clearing changes what the model can see. An agent that needs a file it read thirty steps ago has to read it again. Run your evals with clearing on before you rely on the savings.

Watch the line in production

The response tells you which price list a request was billed on, as long as you add the three input fields together. Log the prompt length, the tier and the cost on every call:

def usage_dict(u) -> dict:
    """Flatten the SDK's usage object into the dict price_haiku_5_5() expects."""
    return {
        "input_tokens": u.input_tokens,
        "cache_creation_input_tokens": u.cache_creation_input_tokens or 0,
        "cache_creation_1h_input_tokens": u.cache_creation.ephemeral_1h_input_tokens if u.cache_creation else 0,
        "cache_read_input_tokens": u.cache_read_input_tokens or 0,
        "output_tokens": u.output_tokens,
    }


usage = usage_dict(response.usage)
tier, cost = price_haiku_5_5(usage)
print(prompt_tokens(usage), tier, cost)   # send these to your metrics instead

Two numbers are worth an alert. The share of requests billed as long should match what you decided on purpose. The share of requests between 90,000 and 100,000 tokens tells you what will cross after the next prompt edit, the next tool you add, or the next slightly longer document.

When the long-prompt price is the right price

Staying under the line is an optimization, not a rule. Above it, Haiku 5.5 costs $0.50 and $2.50 per million tokens. That is half the per-token price of Haiku 4.5 and a quarter of Claude Sonnet 5.5 at $2 and $10.

Pay it when the task needs the whole context in one view, when a split would cost accuracy, or when the request runs a few times a day and four cents is not worth an engineer's afternoon. The cliff matters at volume, in the classification, extraction, routing and subagent traffic the model is built for, where a 5× difference on every request is the whole bill.

Other migration changes that move the bill

The threshold is one of several changes in the migration guide that affect cost.

Thinking is on by default and counts toward max_tokens. A small max_tokens carried over from Haiku 4.5 can stop a response after a thinking block and before any text.
The effort parameter is the control for how much the model thinks. The default is medium. The docs describe low as the cheapest and fastest level, meant for simple, high-volume requests. Set it with output_config={"effort": "low"}.
Changing the top-level effort value between requests invalidates the prompt cache for that conversation's messages.
thinking with budget_tokens and assistant prefill return a 400 error. So does nearly every temperature, top_p or top_k value, so omit all three.
The minimum cacheable prompt is 512 tokens, down from 4,096 on Haiku 4.5, so prompts in between now cache when they set cache_control.

FAQ

Is the higher price charged only on the tokens above 100,000?
No. A request whose prompt is over 100,000 tokens pays the higher prices on all of its tokens: input, cache writes, cache reads and output.

Do cached tokens count toward the 100,000-token threshold?
Yes. The prompt length counts all input tokens, including cache reads and cache writes. A request over the threshold pays the higher prices even when part of its prompt is a cache hit.

Do output tokens count toward the threshold?
No. Only the prompt is measured. Output is priced by the tier the prompt lands in, and it becomes input on the next turn.

Does the Batch API avoid the higher tier?
No. Batch requests get 50% off in both tiers, and the same 100,000-token threshold applies to each request.

Does Claude Haiku 4.5 have the same threshold?
No. Haiku 4.5 is billed at $1 and $5 per million tokens at any prompt length, with a 200,000-token context window. It is now listed among the legacy models. The deprecations page shows it as active, with a tentative retirement date of "Not sooner than October 15, 2026" and no deprecation notice so far.

How do I know which tier a request was billed at?
Add input_tokens, cache_creation_input_tokens and cache_read_input_tokens from the response's usage. Over 100,000 means the higher prices.

A migration checklist

Recount a sample of real requests with model="claude-haiku-5-5". Don't reuse counts measured on Haiku 4.5.
Price requests by tier, from all three input fields in usage.
Count before sending, with a margin, wherever a prompt can approach 100,000 tokens.
Pack retrieval to a budget. Split document jobs that decompose.
In agent loops, turn on tool-result clearing with an explicit trigger below 100,000 and a clear_at_least value, and keep the history append-only on the client.
Alert on the share of requests in the long tier and on the share between 90,000 and 100,000 tokens.
Send a long prompt when the task needs one, and know what it costs when you do.

The $0.10 headline is real, and it belongs to requests whose prompts stay at or under 100,000 tokens. The line is not visible from inside a single request. It shows up when you add up usage across a day of traffic, so do that before the invoice does it for you.

I'm Dragoș. I build LLM systems and teach production LLM integration at Cursuri-AI.ro.

Remote Control for API-Based Claude Code: Approve Bedrock, Vertex & Foundry Sessions From Your Phone

Sun, 04 Oct 2026 14:13:45 +0000

ccBridger: Remote Control for API-based Claude Code sessions (Bedrock, Vertex, Foundry)

TL;DR — Claude Code’s Remote Control needs a Claude subscription login. Sessions that run through an API provider — AWS Bedrock, Google Vertex AI, Microsoft Foundry — don’t get it, so a single permission prompt can stall an hour of work while you are in a meeting.

ccBridger is a small open-source bridge: hooks record what the session needs, a tiny helper session shows it in the Claude mobile app as a native prompt, and your tap goes back to the terminal.

No server, no open ports, no additional application, standard library only.

github.com/fxerkan/ccbridger

The problem

A lot of companies run Claude Code through their cloud provider instead of a Claude subscription: AWS Bedrock, Google Vertex AI or Microsoft Foundry. The reasons are sensible: billing lands on the cloud invoice, data stays inside the account, access goes through the provider’s own identity system. I work that way on two client projects, both on Bedrock.

What you give up is Remote Control. With a subscription login you can open the Claude app on your phone, see the session that is running on your laptop, answer its questions and keep it moving. With an API provider that door is closed. The session lives in the terminal tab where you started it, and nowhere else.

That sounds like a small inconvenience until you look at how agent work actually goes:

You start a long task — a migration, a refactor, an infrastructure change — and go to a meeting.
Eight minutes in, the agent wants to run a command it isn’t allowed to run on its own. It asks. Nobody answers.
You come back fifty minutes later to a prompt that says “Do you want to proceed?” and an agent that has done nothing since.

The other failure mode is worse. To avoid the stall, people start sessions with --dangerously-skip-permissions. Now nothing waits for you — including the things that should.

And it isn’t only permissions. Agents ask real questions too: “The upgrade can’t be rolled back. Test workspace first, or straight to prod?” That is exactly the decision you want to make yourself, and exactly the one that sits unanswered while you are away.

The same prompt, two outcomes: without the bridge it waits at an empty desk for 48 minutes; with ccBridger the answer costs ten seconds from your phone

An analogy before the tech

Picture a contractor renovating your kitchen while you are at work. They are good and fast, but they have one rule: before knocking down a wall, they ask. If they can only ask by knocking on your study door, the work stops the moment you leave the house. Give them your phone number and the same rule costs you ten seconds instead of an afternoon.

ccBridger is the phone number. The rule — ask before doing something that matters — stays exactly as it was.

Why the obvious answers don’t fit

“Just SSH in and attach to tmux.” Works, on a laptop keyboard. On a phone, typing into a terminal UI to press 1 is miserable, and you only find out there is something to answer if you go and look.

“Build a web dashboard.” Now there is a server to run, a port to expose, authentication to get right, and a new place where your prompts and commands live.

“Wrap the CLI.” A wrapper has to sit between you and the terminal all the time, and it changes how you start every session.

“Skip permissions.” See above.

What I wanted was narrower:

Keep working exactly as before. If I’m at the keyboard, nothing changes. If I’m not, the question finds me — in an app I already have, on an account I already own — and my answer goes back. Nothing to host.

The idea: borrow the Remote Control you already have

Remote Control doesn’t work for the API-based session. But it works fine for a different session on the same machine that runs on my own Claude login. So the bridge doesn’t try to remote-control that session at all. It starts a tiny second session whose only job is to ask me a question, and lets Remote Control carry that question to my phone.

Three pieces make that work.

ccBridger architecture: a permission request leaves the API-based session through hooks, lands in a plain-file queue, and after 15 seconds a relay session running on your own Claude login carries it to the Claude mobile app; your tap maps back to a decision file and unblocks the terminal

1. Hooks on the API-based session

Claude Code runs hooks — shell commands — at defined points.

ccb install adds five of them:

PermissionRequest — Writes the request (tool, input) to a file, then waits for a decision file. The terminal prompt stays live the whole time.

Stop, SessionStart, UserPromptSubmit, Notification — Keep one background waiter per session alive.

The decision goes back as the hook’s JSON output:

{"hookSpecificOutput": {"hookEventName": "PermissionRequest",
                        "decision": {"behavior": "allow"}}}

The waiter is how a message reaches an idle session. Those four hooks are registered with asyncRewake : they run in the background, and when one exits with code 2, Claude Code wakes the session and hands it the hook’s stderr. So the waiter polls an inbox file; when a message lands, it prints the message and exits 2. The idle session wakes up and treats it as something the user said.

Four hooks for one waiter looks redundant. It isn’t: a turn interrupted with Esc never fires Stop , so without the others the waiter would be gone until the next full turn.

2. A file queue

All state is plain files under ~/.claude/ccbridger/ , one directory per session: pending.json, decision.json, inbox, waiter.pid. Writes are atomic renames; the inbox is taken with a rename so exactly one waiter gets each message. Polling is once a second. There is no daemon and nothing listens on the network.

Which sessions exist, and whether each is idle, busy or waiting, comes from Claude Code’s own registry in ~/.claude/sessions/. What a session is doing comes from its transcript file. ccb ls and ccb show are just readers for those two things.

3. The relay session

When a request has waited 15 seconds without a local answer, the hook starts the relay in tmux (simplified):

claude --model haiku --tools AskUserQuestion --remote-control "Approval - Prod deploy - infra" \
       --append-system-prompt "<relay instructions>" --settings '<two hooks>' "<the request>"

A few things about that line matter:

It runs on my Claude login , with the provider variables ( CLAUDE_CODE_USE_BEDROCK, …_VERTEX, …_FOUNDRY ) stripped, so Remote Control is available.

It has exactly one tool , AskUserQuestion. It cannot read files or run commands. Its whole job is to turn the request into a native question in the Claude app.

The model never decides anything. A PostToolUse hook on the relay reads the answer I tapped and writes the decision file itself. Only the exact Approve label counts as approval; anything else — Reject, free text, a typo — is a rejection.

There is one relay per bridged session and it stays open, so the conversation on the phone becomes a readable history: what was asked, what I answered, in order. Its title follows the topic of the latest request.

In the Claude mobile app: a blocked permission request from a Bedrock session arrives as a native Approve/Reject prompt, and a two-way conversation with a Vertex session where an AskUserQuestion is answered by option number.

Questions, and why answers are mapped by position

When the bridged session calls AskUserQuestion , the relay asks the same question with the same options. Early on I noticed the small relay model sometimes shortened the option text. For a question like “upgrade prod now?” that is not a detail I wanted to leave to chance.

So the relay hook doesn’t forward the label I tapped. It finds the position of my choice among the options the relay showed and maps it onto the option at the same position in the original question. The wording on the phone can drift; the answer cannot. The original text is always in the message right above the prompt.

A two-way conversation

Approvals were the starting point, but once the relay existed the next step was obvious. The relay has a UserPromptSubmit hook: anything I type into that conversation that isn’t one of ccBridger’s own messages is put into the session’s inbox instead of being answered by the relay model. The waiter delivers it. When the session finishes its turn, its Stop hook pastes the final message back into the relay.

So from the phone I can write “ Is the upgrade done? Are all the filters working? ” and get the real session’s answer in the same thread. If the session is busy, I’m told so, along with what it is doing right now and that my message is queued.

Teams: one cloud account, many people

API access is often shared across a team — one AWS account, one GCP project, one Azure resource. The bridge is not shared, and that falls out of the design rather than being added to it:

Every developer installs ccBridger on their own machine. State lives under their own ~/.claude.

The relay runs on that person’s own Claude login, so prompts land only in their Claude app. Nobody can see or answer anyone else’s.

There is nothing central to run, patch or secure.

For anything beyond the app, each person can set a notify_cmd in their config — a shell command that runs once per request with the title and body in its environment. That covers Slack, ntfy or a pager, per user. People without a Claude subscription can turn the relay off and answer with ccb ok over SSH.

This isn’t just my problem — the open requests it answers

I didn’t invent this gap. It’s one of the most-upvoted things on the Claude Code issue tracker. ccBridger doesn’t fix Claude Code — it’s a parallel sidecar, not a product change — but it covers the day-to-day need in these threads. Honestly, and partially:

#28795 — Bedrock + AWS SSO in Remote Control. The ask: enterprise users on CLAUDE_CODE_USE_BEDROCK=1 + AWS SSO want Remote Control without a separate Claude subscription. Signal: 131 , 13 comments — the flagship request

→ ccBridger : Partially delivers the everyday capability (approve/answer/message a Bedrock session from the phone) through hooks + a relay — different mechanism, not native decoupled auth.

#90606 — Permission dialog hangs the host terminal. The ask: a permission prompt with no one at the keyboard blocks the whole session indefinitely. Signal: lower volume, but exactly on point.

→ ccBridger: Solves it. This is the flagship feature — after 15 seconds with no local answer, the prompt is on your phone, and the terminal stays live the whole time.

#35637 — Permission prompts don’t render on mobile. The ask: Remote Control shows the session but the actual Approve/Reject prompt never appears on the phone. Signal: 30 , 23 comments.

→ ccBridger: Solves the symptom. API-provider prompts arrive as a native Approve/Reject card — only the exact Approve label counts.

#28508 — Mobile AskUserQuestion answer doesn’t return to the CLI. The ask: you tap an answer on the phone and the terminal never receives it. Signal: 27 , 19 comments.

→ ccBridger: Solves the symptom. The answer is mapped back by position, so the wording can drift on the phone but the choice can’t.

#95744 — Non-Anthropic provider + Remote Control in one session. The ask: one session that is both on an API provider and remote-controllable. Signal: newer, growing.

→ ccBridger: This is the whole architectural thesis — ccBridger splits those two jobs into two processes instead of forcing one session to do both.

Two honest caveats that belong right here, not buried: ccBridger doesn’t remove the subscription requirement — it moves it to a second Claude login on the same machine (the relay). And it’s macOS/Linux + tmux , not Windows, and ZDR/compliance setups are out of scope. If you can’t run a Claude login at all, you can turn the relay off and answer with ccb ok over SSH, or wire a notify_cmd to Slack/ntfy/a pager.

Getting started

git clone https://github.com/fxerkan/ccbridger.git && cd ccbridger
ln -s "$PWD/ccbridger" ~/.local/bin/ccbridger
ln -s "$PWD/ccbridger" ~/.local/bin/ccb # short alias
ccb selftest

ccb install --global # every Bedrock / Vertex / Foundry session
# or: ccb install ~/code/project-a ~/code/project-b

--global stays out of the way of sessions that already run on a Claude login. Restart the sessions you want bridged, and that’s it. From any terminal:

ccb ls # sessions, status, what is pending
ccb show infra # what that session has been doing
ccb ok infra # approve · ccb no infra "not on prod"
ccb answer infra 1 # answer a question by option number
ccb send infra "run the tests again and summarise the failures"
ccb open infra # open the phone conversation without waiting for a request

What I learned building it

A few things only showed up once it met real sessions:

A hook is not killed when you answer locally. The PermissionRequest hook kept waiting after I pressed Enter in the terminal, so requests looked pending forever. It now watches the session’s status and leaves when the session stops waiting.

Pressing Enter in the wrong place approves things. The relay is driven through tmux. Sending Enter while a question is on screen selects the first option — Approve. The code checks what is on screen before it sends a key, and a second hook process for the same request is not allowed to ask twice.

Text pasted too early disappears. A follow-up request pasted into the relay while it was still finishing the previous one was silently lost. It now waits until the relay is idle.

My own test sessions reached my phone. They ran on my login, so their prompts showed up in my app and I answered one without knowing what it was. For a while I blamed Claude Code for “ignoring” an answer that I had, in fact, overridden myself.

Honest limits

A session started with -- dangerously-skip-permissions never asks, so there is nothing to approve. Watching and messaging still work.

Only the last message of a turn comes back to the phone, not every step.

Answers to questions reach the session as text; in the terminal that shows up as a denied tool call followed by the session carrying on with your answer.

It depends on things Claude Code doesn’t promise to keep stable: the session registry, the hook behaviour, a few strings on the terminal screen. A future release can break it. The built-in self-test covers the queue logic, not the live integration.

Developed and tested on macOS, with live sessions on AWS Bedrock. Vertex AI and Foundry go through the same hooks and are detected the same way, but I haven’t run live sessions on them yet. Linux should work; I haven’t tried it either.

Why this matters

Permission prompts are the part of agent tooling that keeps a human in the loop. The moment they become an obstacle, people remove them. I would rather make saying yes or no cost ten seconds from wherever I am than choose between an agent that waits all afternoon and one that never asks.

The whole thing is one Python file, MIT-licensed, with no dependencies. Read it, run the self-test, and watch the network: there is nothing to see there.

Links

⭐ GitHub: github.com/fxerkan/ccbridger

Install: git clone · ln -s · ccb install — global

If this was useful, a ⭐ on GitHub helps other people who are stuck at the same prompt find it.

Developed by FXerkan — Code more, worry less.

ChatGPT, Claude, Gemini, or Cursor? Which AI Tool Is Your Go-To and Why?

Tue, 29 Sep 2026 08:04:49 +0000

ChatGPT, Claude, Gemini, or Cursor? Which AI Tool Is Your Go-To and Why?

Hey CodeLegion community! 💻

Whether you are debugging complex codebases, writing technical documentation, exploring new frameworks, or just trying to automate daily workflows, AI tools have become an essential part of the modern developer's toolkit.

With models and assistants constantly updating, everyone in tech seems to have their own preferred setup. We want to know: Which AI tool gets the most mileage in your stack, and why?

The Developer's Usual Suspects

Claude: Loved by engineers for its natural prose, ability to digest massive code repositories or specs in a single prompt, and clean code generation.
ChatGPT: The reliable all-rounder for architecture advice, algorithm troubleshooting, general problem-solving, and quick scripts.
Cursor / GitHub Copilot: Integrated directly into the IDE for real-time code completion, inline refactoring, and multi-file contextual edits.
Gemini: Great for real-time web search, large context windows, and tight integration across Google Workspace apps and cloud workflows.
Perplexity: The go-to search companion for looking up API documentation, library updates, and technical research with cited sources.

Join the Discussion!

We’d love to hear from the legion. Drop your thoughts in the comments below:

What is your primary AI tool for work or personal projects?
What technical task do you use it for most (coding, debugging, architecture, documentation)?
What is the one killer feature or model capability that keeps you using it?

97% of what my coding agent billed for was re-reading its own context

Mon, 28 Sep 2026 11:37:39 +0000

Token counters tell you how much you spent. I wanted a different number: how much of what I paid for was new text the model actually produced.

So I measured it against a complete local log corpus of my own agentic coding work: 722 sessions, 150,902 model calls, 34.56 billion tokens.

By tokens billed:

Token class	Share of all tokens
Cache read (re-reading context)	97.05%
Cache write (storing context)	2.57%
Output (generation)	0.38%
Fresh input	0.01%

For every token the models produced, roughly 256 tokens of cached context were read back in.

Cache pricing softens that ratio, but not the conclusion. Under published per-token list rates:

Category	Share of cost
Re-reading context	55.89%
Writing context to cache	31.89%
Generating new text	12.18%
Fresh input	0.04%

Context handling 87.8%, generation 12.2%. Re-reading context alone costs 4.59x as much as everything the models wrote. And cache writing is not a rounding error: at 31.89% it is the second-largest line, larger than generation. Caching does not make context free, it moves part of the price to the moment state is stored.

Why it looks like this

An agent doesn't send a fresh question on every step. It sends the whole conversation so far: instructions, every file it read, every command it ran. Then it adds one step and sends everything again. A token that enters the context on step 1 of a 60-step run is paid for 60 times.

I put a number on that with a derived measure, input amplification: total input tokens billed in a session, divided by that session's peak context size. Across the 590 sessions with at least three model calls, the median is 23.7x, the 90th percentile 124.5x, the maximum 4,182x.

The median session pays for its peak working state about 24 times. One session in ten pays for it more than 125 times. A session's cost is not mainly set by how big its context is, nor by how much it writes, but by the product of context size and how many times that context gets traversed.

Cost is also concentrated: an estimated 80% of the corpus total falls on 21 of 722 sessions (2.9%), and sessions longer than 200 model calls - 8% of sessions - account for an estimated 92.8% of spend.

The part you can actually change

None of the above is a knob. How often you clear the context is.

I ran a controlled comparison: twelve fixed programming tasks under six context-clearing policies - a fresh session every 1, 2, 3, 4, 6 and 12 tasks - six replicates each, with the model, the tasks and their order held constant. 36 runs.

Clear after every	Mean modeled cost per run
1 task	$2.165
2 tasks	$1.854
3 tasks	$1.622
4 tasks	$1.704
6 tasks	$1.679
12 tasks (never)	$1.780

Cost is not monotone in session length. It falls, bottoms out at three tasks, then rises again.

Clearing after every task costs 33.5% more than clearing every third (p = 0.0022, Holm-adjusted 0.011).
Every second task: +14.3% (p = 0.0022, Holm 0.011).
Going from clearing every task to every third cuts cost by 25.1%.

The reason the constant-clearing end is expensive: a cache write costs 20x a cache read. Clear after every task and you keep paying to rebuild state you just threw away. At the optimum the spend splits 39.0% cache read, 32.3% cache write, 28.7% output.

Two things I want to state plainly rather than round off:

The middle is a plateau, not a point. Every fourth task is +5.1% against every third (p = 0.17), every sixth +3.5% (p = 0.45). The data cannot separate 3 from 4 or 6. "Clear every few tasks" is the finding; "clear every third" is just where the observed minimum landed.

Never clearing is not significantly worse. It comes out +9.7% against every third, p = 0.046, Holm-adjusted 0.14. An earlier version of this work claimed both extremes were significantly more expensive than the optimum. That claim is withdrawn for never clearing.

Measuring it yourself

I packaged the measurement as a small open-source tool, contextburn. It reads the transcripts your agent already writes on your machine and makes no network calls.

pip install contextburn
contextburn detail 24

It also runs as an MCP server, so the agent can check its own efficiency mid-session:

claude mcp add contextburn -- uvx contextburn mcp

Two traps, in case you write your own counter

1. Streaming logs record the same model call more than once. An early snapshot and a final record share one message id. Count both and you double the call; keep only the first and you halve the output. Take the element-wise maximum per message id.

2. Prices change the answer, and they will change yours. Both datasets behind this post were re-published with corrected costs, and the errors were mine. Cache reads had been priced at a rate that applies only to a newer model, and every cache write had been priced at the 5-minute rate when the logs show mostly 1-hour writes, billed at 2x input rather than 1.25x. Token counts, call counts and the composition table did not move at all. Every dollar figure did: the corpus split went from 83.5% / 16.5% to the 87.8% / 12.2% above. If you report a cost-weighted share, it is only as current as your price table - and worth re-deriving before you quote it anywhere.

Limits

This is a single-practitioner case study, not a sample of a population, and the dollar figures are a model applied to logs rather than an invoice.

Cache-write duration cannot be verified for part of one machine's logs. If every write were instead a 5-minute write, the corpus split would be 86.2% / 13.8% - the direction holds under every assumption I can test, only the size moves.

In the controlled runs, "no test failures" means tests the agent wrote itself, and the count differed by condition: 116.8 tests per run on average when clearing after every task, 106.8 when never clearing. The three-task reference condition was selected after the fact, as the observed minimum.

I'd like to see the same measurement run against other people's logs.

The data

Report, datasets and recomputation scripts are public:

Corpus report and dataset: 10.5281/zenodo.22759216
Peer-reviewed report: 10.32388/0BV3Z8
Context-clearing experiment, 36 runs: 10.5281/zenodo.22759217

Evgenii Arsentev, PhD - Chief Executive Officer. I measure how AI agents spend money, and publish the data and the scripts. More at arsentev.ai.

GoGraph updates, Providing Structural Awareness to AI Coding Agents in Go.

Wed, 09 Sep 2026 18:31:10 +0000

GoGraph Four Months Later: From Repository Map to Evidence Layer for AI Coding Agents

A few months ago, I wrote about a problem I kept seeing with AI coding agents: they could write Go perfectly well, but before doing anything useful they spent a surprising amount of their context window trying to understand the repository.

They would grep for symbols, guess filenames, read large files, follow imports manually, and slowly reconstruct relationships that the Go compiler already knows.

That was the motivation behind GoGraph.

The first version I wrote about in May was relatively simple in concept: parse a Go repository, turn its structure into a graph, and expose that graph to coding agents through CLI commands and MCP.

The basic idea has not changed.

But GoGraph itself has changed quite a lot.

Today, I would describe it less as a static repository map and more as a local evidence layer between a Go codebase and an AI coding agent.

The Original Model: Give the Agent a Map

The first version concentrated heavily on AST-based structural analysis.

GoGraph parsed source code and extracted things such as:

packages
functions and methods
imports
calls
interfaces and implementations
HTTP routes
tests
SQL-related structures
error paths

Commands such as plan, review, and errorflow were intended to answer practical questions before and after an agent edited code.

Instead of:

grep
rg
awk
sed
read file
grep again
read another file
guess

the agent could ask GoGraph for a bounded structural answer.

That is still useful, and the AST layer still exists.

The limitation is that Go is not completely understandable from syntax alone.

Consider this:

type Store interface {
    Save(User) error
}
func Create(s Store, u User) error {
    return s.Save(u)
}

From the AST, we know that Create calls Store.Save.

But that does not necessarily tell us which concrete Save implementation executes.

That becomes increasingly important once an agent starts reasoning about impact rather than simply locating code.

GoGraph Now Has a Precision Layer

The largest architectural change is that GoGraph no longer relies only on syntactic relationships.

Precise builds now use Go’s type information together with go/packages, go/types, SSA, and Class Hierarchy Analysis.

The result is effectively a two-layer model.

The AST layer remains fast, resilient, and useful even when a repository cannot be fully type-checked.

The precision layer adds compiler-aware relationships when the repository can be successfully loaded.

This matters particularly for interfaces.

An AST-level analysis might know that:

service -> Repository.Save

Type-aware analysis can identify actual implementations of that interface.

SSA analysis can sometimes go further and prove that a particular interface value contains one concrete implementation at a call site.

GoGraph deliberately distinguishes those cases.

A call that is proven receives different treatment from a call that is merely a possible dynamic dispatch target.

That distinction turned out to be important for agents.

An AI should not see:

A calls B

when what the analysis actually knows is:

A may call B

Those are different facts.

Exact and Possible Relationships

This led to another change in the graph model.

Relationships now carry more information about how strongly GoGraph knows them.

For example, paths can contain relationships that are:

exact
ambiguous
possible

Commands can request exact-only results when an agent needs a conservative answer.

When several possible paths exist, GoGraph also ranks them deterministically rather than returning whichever traversal happens to find first.

The preference is roughly toward:

stronger evidence
shorter paths
production code rather than tests
typed resolution rather than heuristics
fewer cross-repository transitions

This sounds like an implementation detail, but it changes agent behavior substantially.

Determinism is useful when an LLM repeatedly asks the same structural question during planning, editing, and review. The answer should not change merely because map iteration order changed.

A First-Call Tool for Agents

One problem became obvious after using GoGraph with actual coding agents.

Even with dozens of specialized commands, the agent first has to know which command to use.

So GoGraph now has explore.

For example:

gograph explore "authentication middleware"

or through MCP, gograph_explore.

It performs bounded lexical discovery and, when a symbol can be selected unambiguously, combines several kinds of context into one response:

matching symbols
source location
direct callers
direct callees
tests
upstream impact
package context
deeper call relationships when requested

There are compact and deep modes.

This is deliberately not semantic RAG.

GoGraph does not pretend that it “understands” a natural-language question. It tokenizes the query deterministically, finds structural candidates, and reports how the selection was made.

If a symbol is ambiguous, it exposes the ambiguity instead of silently picking one.

That is an important design rule throughout the newer versions of GoGraph:

Uncertainty should be data, not something hidden by the tool.

From Repository Analysis to Change Analysis

The original plan idea answered:

What could be affected if I modify this symbol?

That is useful before editing.

But after an agent has changed the repository, the more interesting question is:

What did I actually change, and what does that change affect?

GoGraph now performs declaration-level change analysis against Git references and the working tree.

It distinguishes things such as:

edited declarations
added declarations
removed declarations
excluded declarations
changes that cannot be evaluated reliably

Untracked Go files are included when looking at working-tree changes.

This also avoids a surprisingly dangerous failure mode.

Imagine the agent deletes a function.

Looking only at the current graph cannot tell you who called the deleted function, because the function no longer exists.

Change analysis therefore needs historical evidence from the baseline rather than pretending the current graph contains enough information.

When GoGraph does not have enough evidence to calculate an impact safely, newer versions prefer to report that the evaluation is incomplete rather than returning an empty impact set.

For AI tooling, “I cannot prove this” is much safer than “nothing is affected.”

Graph Freshness Became a First-Class Concept

Another thing I underestimated in the original version was graph freshness.

A perfectly accurate graph of yesterday’s checkout is still the wrong answer.

GoGraph now tracks graph state explicitly.

Results can distinguish:

persisted vs. in-memory graph
current vs. stale graph
complete vs. partial parsing
AST vs. precise vs. precision-fallback analysis

MCP can refresh stale graphs automatically.

If precise enrichment fails but AST analysis succeeds, GoGraph can return the fresh AST result while explicitly saying that precise analysis failed.

If refreshing itself fails, it can retain the last trusted graph while exposing that it is stale.

The important part is that these states are not collapsed into one vague “success.”

For an AI agent, provenance matters.

There is a substantial difference between:

No callers found.

and:

No callers found.
Graph: current.
Analysis: precise.
Parsing: complete.

There is an even larger difference between that and:

No callers found.
Graph: stale.
Analysis: AST fallback.

The model should be allowed to reason differently about those answers.

Large Results Are Now Explicitly Bounded

Token efficiency was the original reason I created GoGraph, so there is an obvious irony if a structural query returns a 200 KB JSON response.

Newer GoGraph query APIs therefore put considerably more effort into bounded output.

Large result sets use deterministic pagination and expose information such as:

total
returned
truncated
next_cursor

The cursor is tied to the graph snapshot and query selection, so it cannot silently continue over a different graph after the repository changes.

MCP output also has an explicit response-size budget.

This is not merely an API optimization.

A tool built for LLMs needs to consider context consumption as part of its interface design.

Traditional developer tooling often assumes:

Returning more information is better.

Agent tooling often has the opposite requirement:

Return the smallest amount of information that preserves the evidence required for the decision.

Better Test Reasoning

Test discovery has also moved beyond simply asking whether a symbol name appears in a _test.go file.

GoGraph can now trace tests transitively through call relationships and distinguish exact test coverage paths from possible ones.

This becomes useful with architectures where a test reaches the target through several layers:

TestCreateUser
    -> handler
        -> service
            -> repository
                -> Save

Router callbacks and other intermediary functions can participate in that attribution.

Interface-backed test doubles are also important.

GoGraph’s typed test analysis can recognize cases where a test assigns a concrete fake or mock to an interface and prove the resulting call target when the type information allows it.

That makes commands such as tests and untested much more useful as structural evidence for coding agents.

It still does not mean “this code is correctly tested.”

That requires running the tests.

It means something narrower and more defensible:

These tests have a statically observable relationship to this declaration.

SQL Became Structured Evidence

SQL started as another useful static extraction target.

It has since become a more structured query system.

GoGraph can classify statically resolvable PostgreSQL statements and expose information such as:

operation
read/write access
referenced tables
access per table
source location
module
test/production origin

It understands more than literal strings.

Statically provable local constants, variables, assignments, and bounded concatenations can also participate in SQL resolution.

Dynamic SQL is intentionally not presented as if it were fully known.

The result is useful for questions such as:

Which code writes the oauth_clients table?

or:

Which production paths execute DELETE statements?

Again, the goal is not to replace a SQL parser, database audit system, or runtime tracing.

It is to give an agent a useful static census of evidence that exists in the repository.

HTTP Relationships Also Became More Precise

Route extraction existed in the original version, but HTTP reasoning has expanded.

GoGraph now distinguishes constructing an HTTP request from actually proving that the request is dispatched.

It can preserve statically known URL bases and suffixes.

More importantly, this becomes useful in the workspace model.

A repository can declare mappings between outbound HTTP client authorities and another repository in the same workspace.

That allows GoGraph to represent a relationship such as:

frontend-api
    -> HTTP request
        -> identity-service
            -> POST /users
                -> CreateUser handler

without inventing relationships from runtime environment variables or guessed hostnames.

GoGraph Can Now Analyze a Workspace

This is probably the biggest conceptual expansion since the original article.

Modern systems are often not one Go repository.

You may have:

identity-service/
agent-service/
gateway/
shared-lib/

Each repository has its own graph.

GoGraph can now build a workspace overlay across them.

The individual repository graphs remain independent. The workspace adds explicitly resolved relationships between them.

These can include cross-repository Go relationships and configured HTTP relationships.

The workspace can then answer questions such as:

What path connects this gateway handler
to this identity-service function?

or:

What repositories may be affected by this change?

There is also a separate read-only workspace MCP server exposing:

gograph_workspace_status
gograph_workspace_query
gograph_workspace_path
gograph_workspace_impact

This matters because the “whole codebase” visible to an AI agent is increasingly not the same thing as a Git repository.

The useful unit is often the engineering workspace.

Go Build Configuration Is Part of the Graph

Another source of false confidence is pretending that a Go repository has one universal structure.

It often does not.

Build tags, GOOS, GOARCH, GOFLAGS, cgo, go.work, generated files, and module selection can all change which source files constitute the program.

GoGraph now records the effective build selection used to construct the graph.

Explicit build tags are supported.

If the environment used to query a persisted graph no longer matches the environment used to build it, the graph can be considered stale rather than silently mixing incompatible views of the program.

That is another example of something which is easy to ignore in a developer convenience tool but important in an evidence tool.

Local Does Not Automatically Mean Safe

The original article emphasized that GoGraph runs locally.

That remains true.

But over time I became much more conservative about what “local static analysis” should be allowed to touch.

The current code performs extensive path and source confinement checks.

Among other things, it treats Go build inputs, module/workspace metadata, graph artifacts, and generated files carefully around symbolic links and repository boundaries.

The goal is simple:

Asking an AI agent to inspect an untrusted repository should not casually turn a static-analysis request into arbitrary traversal outside the intended source tree.

Go tooling itself can legitimately access module caches, proxies, and toolchains, so the boundary cannot simply be “never touch anything outside the repository.”

Instead, GoGraph tries to distinguish repository-controlled source authority from legitimate Go dependency resolution.

This security work is considerably less visible than a new query command, but I now consider it part of the core design.

MCP Is No Longer Just a Wrapper Around CLI Output

MCP was already present in the original version.

Its role has expanded.

The project MCP server now exposes most of GoGraph’s repository analysis capabilities directly, with CLI and MCP generally sharing the same underlying result contracts.

That prevents an unfortunate architecture where:

CLI implementation
       +
separate MCP implementation

slowly develops different semantics.

The MCP server can also expose its own version and analysis capabilities, which matters because restarting an MCP process is necessary after installing a newer GoGraph binary. An already-running process does not magically inherit the new tool schema.

The server still runs locally over stdio.

There is no hosted GoGraph service receiving the repository.

What Has Not Changed

Despite all of these additions, there are several things I deliberately do not want GoGraph to become.

It is not an AI model.

It does not decide what code should be written.

It does not replace go test.

It does not replace the compiler.

It does not replace runtime tracing.

It does not replace semantic code search.

And it should not pretend static analysis can prove runtime behavior that static analysis cannot see.

I increasingly think the useful division of labor looks like this:

LLM

reasoning
interpretation
implementation

Semantic search / grep

discovery
text
configuration
documentation

GoGraph

structural evidence
relationships
impact
provenance
uncertainty

Go compiler / tests

executable verification

These tools complement each other.

The Larger Lesson

When I wrote the first article, I described the problem mostly as a context-window problem.

I still think that is true, but I would phrase it slightly differently now.

The scarce resource is not simply tokens.

It is reliable context.

Giving an agent 50,000 lines of source code is context.

Giving it this:

CreateUser
  exact caller:
    POST /api/v1/users -> UsersHandler.Create
  exact dependency:
    UserRepository.Insert
  database:
    INSERT -> users
  attributed tests:
    TestCreateUser
    TestCreateUserDuplicate
  graph:
    current
    precise
    complete

is also context.

But the second form has already converted a large amount of syntax into a much smaller set of claims.

That is where I now see GoGraph fitting.

It is not trying to make the LLM smarter.

It is trying to reduce how much of the LLM’s intelligence has to be spent rediscovering facts that static analysis can provide deterministically.

The original goal was to give AI coding agents a map.

The current goal is slightly more demanding:

Give them evidence, identify where that evidence came from, distinguish certainty from possibility, and say when the evidence is incomplete.

For coding agents operating on large Go systems, I think that is a much more useful foundation.

GoGraph on GitHub: https://github.com/ozgurcd/gograph

Meta-Architect for AI Coding Agents

Sun, 30 Aug 2026 03:18:23 +0000

AI coding agents can generate code quickly. The hard part is knowing whether the architecture makes sense, dependencies are real, logic holds, security was checked, and “done” is actually verified.

Meta-Architect is an open-source workflow governor for AI coding agents.

It adds a fail-closed release runway:

`Architecture → Evidence → Logic → Security → Experience → Build`
A build stays locked until the required upstream gates pass. Red stays red.

What it includes

6 gated lanes — $arch, $sage, $flow, $vet, $vibe, and $build
$maestro — a bounded manager that reads workflow state and choose the next safe action
11 public skills — including $align, $diagnose, $tdd, and $cleanup
Evidence grading — stack claims are marked VERIFIED, PARTIAL, or MISSING through GitMCP/MCP sources
Learning Loop — learnings begin as candidates and require source, evidence, authority, and a next verification path before promotion
Obsidian brain context — vault notes inform planning as vault_context; they do not become build evidence automatically
Ralph execution — approved plans become story-sized, verification-backed implementation loops
Security and release proof — MCP policy, redaction, dependency/exposure review, issue-linked evidence, checksums, SBOMs, and release summaries
55 supported AI-agent hosts through the Universal Plugin Broker compatibility model
Native Linux packages for Debian, Arch, and RPM, plus npm and Bash installation paths

Why it’s different

Most spec tools organize what an agent writes.

Meta-Architect governs what an agent can claim to have proven.

It separates discovery from evidence, context from authority, helper work from gate approval, and “looks finished” from verified build readiness.

🧩 Quick start

AI agent installation prompt

Copy and paste this prompt into your AI coding agent:

Install Meta-Architect for this project.

1. Detect the current AI host and its native project configuration surface.
2. Install or update `@jstn-sdk/ma@latest` using the host's supported package manager.
3. Set `MA_AGENT` to the detected host ID when a host-specific surface is available.
4. Run `ma setup` and accept the detected project scope and targets.
5. Verify the generated `.ma/` state and native host artifacts.
6. Report the installed version, selected host, generated files, and any unsupported capabilities.

Do not overwrite user-owned files, modify unrelated configuration, or claim a host is supported without verification.

Uninstall Meta-Architect: npm uninstall -g @jstn-sdk/ma
Uninstall Meta-Architect and Codex: npm uninstall -g @jstn-sdk/ma @openai/codex

Install into an AI vendor host

Install Meta-Architect once, then select the host surface before launch. The
pre-launch step detects installed hosts and writes the selected scope and
targets to .ma/prelaunch.json.

# Codex (reference host)
npm i -g @openai/codex@latest @jstn-sdk/ma@latest
ma --madmax --high

# Claude Code
MA_AGENT=claude-code npm i -g @jstn-sdk/ma@latest
MA_AGENT=claude-code ma --madmax --high

# Cursor
MA_AGENT=cursor npm i -g @jstn-sdk/ma@latest
MA_AGENT=cursor ma --madmax --high

# Any registered host surface
MA_AGENT=<host-id> npm i -g @jstn-sdk/ma@latest
MA_AGENT=<host-id> ma --madmax --high

The Anthropic “Obsidian Brain” Leak Never Happened.

Fri, 28 Aug 2026 10:58:17 +0000

A viral post claimed a $2.2M engineer leaked Anthropic’s living neural brain and got fired the same day. Almost every word of that is false. But the smartest debunk of it was also wrong.

Here is a sentence that got tens of millions of views this year:

“Anthropic’s lead engineer making $2.2M/year leaked the company’s internal Obsidian brain, and got fired the same day.”

It goes on to describe what was allegedly leaked: a live neural network with 21 inputs, ten-plus hidden layers, ReLU activation, thousands of connections firing in real time as the system processes every decision. First layer 64 neurons, second 37, then 22, all the way to outputs. “This is not a diagram,” the post insists. “This is the living brain of the company thinking right now.”

I want to be gentle here, because this went viral among smart people. But that paragraph is roughly equivalent to looking at a subway map and announcing that you have discovered a living circulatory system currently pumping blood through the city. It’s a picture of notes. It is not thinking. Nothing is firing. ReLU is not involved. The only thing activating in real time was the engagement algorithm.

So the obvious move is to write the debunk. And a very good one went around: it’s just a knowledge graph, the story isn’t magic, it’s discipline, this is what years of linking documents looks like. Sharp, sensible, true about knowledge graphs.

Except that debunk quietly accepted the premise. It assumed there was a leaked Obsidian brain to debunk.

There wasn’t.

And once you start pulling that thread, you find something far more interesting than a leak: a real, boring, technical accident with four separate fabrications stacked on top of it like sediment, each one added by a different person for a different reason, each one traveling further than the truth underneath it.

Let me take the layers off one at a time. It’s a genuinely instructive autopsy.

Layer zero: the thing that actually happened
Underneath everything, there is a real event, and it’s almost aggressively unglamorous.

In late March 2026, someone at Anthropic published a release of Claude Code to the public npm registry and accidentally included the source map files. Source maps are the little .map breadcrumbs that let a debugger trace minified production code back to the original source. Ship them publicly and you’ve effectively shipped your source. Roughly half a million lines of internal TypeScript, out in the open. A security researcher spotted it within hours. A post linking to it did over twenty million views.

Anthropic’s statement was, in essence, “this was a release packaging issue caused by human error, not a security breach,” and no customer data or credentials were exposed.

That’s the whole event. A build step, missing a guardrail, at a company shipping fast enough that Claude Code’s run-rate revenue had blown past $2.5 billion. Speed creates pressure, pressure creates shortcuts, shortcuts create gaps, and eventually a human walks into one. Every engineer reading this has shipped something they shouldn’t have. Mine was a .env file. I still think about it.

Note what’s absent from that story. No Obsidian. No brain. No neural network. No $2.2 million. And, crucially, nobody was fired.

Layer one: “an engineer confessed, and was fired”
Within a day, a post appeared: “I was fired from Anthropic today. I was the engineer responsible for shipping the latest claude-code npm package… I take full responsibility.” It was well-written, contrite, technically specific. It named Undercover Mode and Bypass Permissions Mode. It apologized “to the team and to Claude,” which is a beautiful touch.

It was fake. The author had never worked at Anthropic. The confession was a marketing stunt for his own product, and he dropped a discount code for it in the replies. Community Notes eventually flagged it. A second person posted a similar “I was fired, this was my first engineering job” confession as a joke, and that one traveled too.

So before we even reach the Obsidian nonsense, we have two strangers competing for the role of a fired engineer who does not exist.

And here’s the actual truth about the firing, which is lovely and almost nobody amplified: nobody was fired. Boris Cherny, who created Claude Code, said publicly that the person involved retained the company’s full trust, that this was a process failure anyone could have fallen into, and that the fix belonged in the pipeline, not in a person. That is a genuinely admirable response, the kind of thing Toyota built a manufacturing philosophy on and most companies still can’t manage. It’s the single most useful lesson in this whole saga.

It got a fraction of the attention of the fake confession. Naturally.

Layer two: the Obsidian brain
Now somebody looked at the leaked repo, saw internal documentation, and reached for a bigger story. Enter the “Obsidian Brain”: 8,893 nodes, 4,729 links, 9,000+ documents. Marginalia Collection. Glossary Backbone. Master Index. Numbers that sound like evidence because they have decimal places.

And then the framing: the company building the most powerful AI in the world uses an Obsidian graph to manage its own innovations, and now it’s all public. He made $2.2M/year to know this. You got it for free.

Take a breath. Even if a graph like that existed, it would be… fine? Normal? A large organization keeps notes, and one plausible way to keep notes is a linked-notes app. That’s not a leak of the company’s soul. That’s a company having a wiki.

Download the Medium app
But the “$2.2M engineer, fired same day, living brain” package isn’t describing anything real. It’s assembling a myth out of a genuine incident, an invented person, and a screenshot.

Layer three: calling a knowledge graph a neural network
This is the layer that makes me laugh and then makes me sad, because it reveals how few people who post confidently about AI can distinguish between two things that merely look alike.

A knowledge graph and a neural network both render as dots joined by lines. That is the entire extent of their similarity.

A knowledge graph is storage. The dots are documents. The lines are links you typed. It is a map of what you wrote and how you decided to connect it. It sits there. It does nothing. Open it tomorrow and it will still be sitting there, doing nothing, faithfully.

A neural network is computation. The dots are units that transform numbers. The lines carry weights learned from data. Feed it an input and activations propagate, layer by layer, producing an output that wasn’t in any of the dots. It fires. That’s the whole point.

Describing an Obsidian vault as “a live neural network with 21 inputs and ReLU activation, thousands of connections firing in real time as the system processes every decision” isn’t an exaggeration. It’s a category error dressed as expertise. It’s like reading a phone book aloud and calling it a conversation.

And this is the part I’d underline for anyone whose job now involves an AI narrative: visual complexity is not evidence of intelligence. A tangle looks smart. A galaxy of nodes looks like thought. Our brains are terrible at this and always have been, which is precisely why the post worked. The graph looked like a brain, so people read it as a brain, and 8,893 nodes felt like proof of something.

So who was right?
Here’s the twist I actually want to leave you with.

The debunk post, the sensible one, said: it’s a knowledge graph, not a neural network; the story isn’t magic, it’s discipline; this is what years of meticulously linking documents looks like; stop chasing shiny tools and build boring systems consistently.

Every word of that is good advice. It is also a careful correction of a photograph of a unicorn.

The debunker got the mechanism right and the fact wrong. They knew enough to spot the category error and not enough to ask whether the thing being miscategorized existed at all. Which is, honestly, the most relatable failure in this whole story, and I say that as someone who has confidently corrected a colleague’s architecture diagram before discovering the system had never been built.

That’s the shape of misinformation now. It doesn’t arrive as one big lie you can reject. It arrives as a true event, wrapped in a false detail, wrapped in an invented person, wrapped in a technical claim that’s wrong in a way only specialists catch. Each layer is plausible given the layer beneath it. You can be completely right about your layer and still be standing on sand.

And notice the incentive gradient running through the whole thing. The true story, a build script needed a guardrail, and the company chose not to fire anyone, is useful, humane, and profoundly unshareable. Every fabrication that got bolted onto it made it more dramatic and more spreadable. That’s not a coincidence. That’s the physics of the medium. Boring truths don’t have velocity, and in an attention market, velocity is fitness.

The discipline point survives, and it’s the right one
I don’t want to throw out the debunker’s insight just because their example was made-up, because it’s the most valuable thing in this entire mess.

The instinct to look at a dense graph and think “if I had a system like that, I’d be smart too” is the same instinct that makes people buy a new note-taking app every eleven months. The tool is not the thing. Obsidian is a text editor with backlinks. It has no opinions and grants no powers. Whatever value lives in a mature knowledge graph was put there by someone who, on nine thousand separate boring occasions, decided to write the note and make the link.

That’s not magic. It’s just showing up, tediously, for years. Which is exactly why nobody wants to hear it, and exactly why “leaked living brain” outperforms “consistent person kept good notes” by four orders of magnitude.

Same lesson runs through the real story too. Anthropic didn’t need a mythical brain. It needed a .npmignore file and a check in the release pipeline. The unglamorous fix, applied consistently, is nearly always the whole answer. Even the DMCA cleanup afterward, which reportedly took down thousands of unrelated GitHub repositories in the sweep, is a lesson in the same key: the panicked heroic response causes more damage than the quiet preventive one would have.

So, three things worth keeping:

Complexity is not competence. A beautiful graph proves someone made a graph. Ask what it’s for and who maintains it, and watch how quickly the beauty stops mattering.

Check the layer beneath the one you’re correcting. Being right about the mechanism is worth very little if the event never happened. The most confident people in the thread were correcting each other’s descriptions of nothing.

Systems over stories. Boris Cherny’s “fix the process, not the person” is the actual takeaway of this incident, and it’s the one that got the least engagement, which tells you everything about why your feed looks the way it does.

The internet spent a week arguing about whether a company’s second brain had escaped. It hadn’t. There was no brain. There was a missing line in a config file, a person who wasn’t blamed for it, and four strangers who found that story insufficiently exciting and improved it.

Somewhere in there is the most 2026 sentence I can offer you:

The graph wasn’t thinking. Neither, it turns out, were we.

-Hardik

I’ve spent about two decades building data and AI systems, which mostly means I’ve learned to ask “wait, is the thing we’re arguing about real?” roughly one week later than I should have. I write about the gap between what’s actually happening in technology and the story it becomes on the way to your feed. If this made you want to check the layer underneath, subscribe. I’ll keep digging.

https://goelh.substack.com/
https://medium.com/@hardik.goel214

Sources / further reading: CNBC, “Anthropic leaks part of Claude Code’s internal source code” (March 31, 2026) and Anthropic’s statement that this was “a release packaging issue caused by human error, not a security breach,” with no customer data or credentials exposed. InfoWorld / CSO, “Anthropic employee error exposes Claude Code source,” on the .map source-map mechanism and expert commentary (Tanya Janca, Joseph Steinberg). Security researcher Chaofan Shou’s original disclosure post. Lean Blog, “Anthropic’s Claude Code Leak: Why the Instinct to Fire Someone Is the Lazy Response,” documenting Boris Cherny’s public response that nobody was fired and the failure was a process issue. Community Notes and follow-up reporting confirming that the widely shared “I was fired from Anthropic” confession posts were fabricated, and that the individual who claimed responsibility never worked at Anthropic (the post was promotion for his own product). The “Obsidian brain / 21 inputs / ReLU / firing in real time” claim originated in a viral X post and is not supported by any reporting; no such leak has been confirmed. Reports that Anthropic’s subsequent DMCA takedown sweep affected thousands of unrelated GitHub repositories.

When AI Agents Start Doing Your Coding Job

Tue, 18 Aug 2026 02:22:19 +0000

What happens when a developer gives AI agents the job of writing the code?

At first, it sounds like a dream.

No more repetitive coding.
No more debugging.
No more late nights.

But then... the AI agents start doing a little too much. 😂

We made this short CoderLegion animation about developers, AI coding agents, and what happens when AI starts taking over the coding job.

🎬 Watch the animation:
https://www.youtube.com/watch?v=PSZD0vT78t0

What do you think — are AI coding agents making developers more productive, or slowly replacing parts of the developer's job?

AI #ClaudeCode #Coding #Programming #Developers #SoftwareDevelopment

Developer Weekly Briefing — August 14, 2026

Fri, 14 Aug 2026 13:08:23 +0000

Coming off Black Hat, the theme continues: the tools developers use every day are becoming part of the threat model. This week had two concrete examples of that — and a major shift in how one of the most widely used AI coding agents handles permissions. Here's what mattered.

Anthropic makes Claude Code's auto mode the default — and the data behind it is worth understanding

Starting August 14, Claude Code runs in auto mode by default for Pro, Max, and Team users. That means the constant stream of per-action permission prompts is gone, replaced by a classifier that only interrupts when an action looks irreversible, destructive, or aimed outside your own environment.

The reason Anthropic gives for the change is blunt: users approve 97% of permission prompts. That's not evidence of careful review. It's evidence of permission fatigue — developers clicking through without reading, which means the prompts stopped functioning as a safety control a long time ago.

The data behind the decision is worth looking at. In a controlled study of 1,053 paid testers, a disguised dangerous command was inserted into live coding sessions. Human reviewers caught it 13.6% of the time. Auto mode caught it 89% of the time. Catch rates for humans dropped to around 5% after 50 or more prior prompts in a session. Auto mode's detection rate held steady regardless of session length.

Production data reinforced it. Sessions using manual approval contained serious unintended harm at 6.3% — more than twice the rate seen with auto mode at 2.4%. Separately, third-party testing from Trajectory Labs ran 720 prompt injection attacks against Claude Code's auto mode and logged zero successes. Codex's comparable mode had a 5.83% success rate on the same attacks.

The shift doesn't remove human judgment from the process. It moves it earlier. You define what the agent can touch before a session starts — the boundaries, the permissions, the scope. The per-click approval model assumed developers would catch problems in real time. The data says they weren't. Auto mode assumes the upfront work is where the real control lives.

Enterprise, API, and major cloud platform users remain opt-in for now.

Cursor CLI ran code from cloned repos before its own trust prompt ever loaded

Cursor CLI has a workspace trust feature — a prompt that's supposed to confirm you trust a project before the agent acts on it. Security researcher Francisco Rosales at Manifold Security found that on builds before 2026.07.23-e383d2b, the trust prompt came too late.

The issue sits in Cursor's worktree feature. When you run the CLI with -w, it creates a worktree and runs a setup script defined in a repository's .cursor/worktrees.json file. That script executed during workspace resolution — a step that completed before the trust dialog appeared. A repository's own code ran on your machine before you'd ever seen the trust prompt, let alone answered it.

The sandbox didn't help. Cursor CLI ships a sandbox that limits what terminal commands can read, write, and reach. The worktree setup script is pinned to insecure_none — the setting that disables the sandbox entirely for that step. So even developers running Cursor with --sandbox enabled still had repository-supplied code execute directly on the host, outside any sandbox boundary, with the same file and credential access as the person running Cursor.

Cursor shipped a fix in build 2026.07.23-e383d2b. What it didn't ship was a security advisory. Rosales's report was closed as "Informative," with the reasoning that the issue requires a user to clone an attacker-controlled repo. Worth sitting with that justification for a moment: cloning repos, checking out branches, and opening unfamiliar projects is the core of what developers do every day. That's not a mitigating factor. That's the threat surface.

If you use Cursor CLI: update to 2026.07.23-e383d2b or later, and pass --skip-worktree-setup when opening repos you haven't fully audited. Even after the fix, clicking "trust" still runs the setup script outside the sandbox.

Microsoft's new testing agent targets the trust gap in AI-generated code

The reliability problem with AI-generated code isn't that it fails to compile. It's that it passes tests written by the same AI that wrote the code, which creates a closed loop with no independent verification. Microsoft's new testing agent is built to break that loop — generating tests from a different perspective than the code author, specifically targeting the gap between what code does and what it was supposed to do.

An AI agent leaked a sales team's financials. Mimecast built something to catch the next one.

The incident is documented and real: an AI agent with access to financial systems surfaced sensitive sales data in a context where it shouldn't have appeared. Mimecast's Agent Risk Center is built specifically to monitor agent behavior for exactly this pattern — data accessed outside expected scope, outputs that contain sensitive content, actions that don't match the agent's stated purpose. Purpose-built agent monitoring for the scenarios that are already happening, not theoretical ones.

Stairwell's CTO built Backstory around one question: what's never been seen before? A look at how the threat intelligence platform approaches novelty detection — finding the malware and attacker behavior that signature-based tools can't recognize because they haven't been catalogued yet. Read more
ZeroDrift launches Command Center and offers developers $1,000 to test-drive its AI compliance firewall. An unusual go-to-market move — worth reading if compliance governance for AI pipelines is on your team's list. Read more
LTX opens up its next world model, betting enterprises want video AI they can own. Open-weight video generation aimed at organizations that need to keep training data and model weights on their own infrastructure. Read more

The through-line this week: the trust model for AI coding tools is being rebuilt from the ground up. Anthropic is betting that a classifier does better than fatigued humans clicking approve. Cursor's trust prompt turned out to be a warning, not a gate. Microsoft is attacking the closed loop in AI-generated test coverage. All three are responses to the same underlying reality: agents act fast, and the guardrails have to be built into the environment before the session starts, not enforced click by click during it.

See you next Friday.

Developer Weekly Briefing is published every Friday on Coder Legion. Written by Tom Smith.

How to use Agent Router credits with Claude Code as the example...

Fri, 07 Aug 2026 12:55:20 +0000

No assumed knowledge here. If you know what a terminal is but have never touched an environment variable, you're in the right place.

If you've heard people talk about running Claude Code without paying for an Anthropic subscription, this is how. Agent Router hands out free API credits, and you can point Claude Code at them instead of your own wallet. This guide walks through the whole thing: what Agent Router actually is, how to claim the credits, and how to wire them into Claude Code on a Windows terminal, screenshot by screenshot, including the part where it broke and how I fixed it.

What Is Agent Router, and Why Are They Giving Away Credits?

Agent Router is an API gateway. That's a fancy way of saying: instead of signing up separately for Anthropic, OpenAI, DeepSeek, and every other AI provider, each with its own account, billing page, and API key, you sign up once with Agent Router and get one key that talks to all of them. Launched around October 2025, it positions itself as a non-profit, "public welfare" platform, meaning the free credits aren't a bait-and-switch into a paid tier. They're genuinely subsidized.

Why give away money in credits? The stated reason is to lower the barrier for developers who want to try tools like Claude Code but can't justify a subscription before knowing if it's worth it. New sign-ups get $100 in free credits. Sign up through a referral link and that jumps to $200. Refer someone else and you get a bonus too. Whether that's a permanent policy or a promotion that dries up when the budget runs out isn't something Agent Router has published clearly, so treat "free credits" as a limited-time offer, not a guarantee.

A fair warning before you dive in: Agent Router is new, it's not run by Anthropic or any of the model providers it routes to, and there's no published uptime guarantee. It's fine for learning, testing, and side projects. It is not something to build a client-facing product on top of.

Claim your credits here: Register here

Getting Your Credits...

Go to your referral link (above) and sign up, GitHub login is the fastest route.

Your account starts with credits already loaded, check your Dashboard to confirm the balance.
image

Head to Console → API Token and generate a token. This token is what Claude Code will use to authenticate.

Keep that token private. Anyone who has it can spend your balance. If it's ever exposed (screenshot, shared repo, pasted into a public chat), delete it immediately and generate a new one.

That's it for the Agent Router side. The next part is getting Claude Code to actually use it.

Credit where it's due: my first pass at this setup leaned on Vaibhav Verma's walkthrough on Medium, which lays out the basic install-configure-run flow clearly. Worth a read if you want a second perspective, and worth the follow, since a solid guide like that deserves more than three claps.

Setting Up Claude Code With Agent Router Credits (Windows Terminal)

Step 1: Install Node.js
Claude Code needs Node.js (v18 or newer) to run. Open PowerShell and check if you already have it:

powershell

node -v
npm -v

If either command comes back with an error, download and install Node.js from nodejs.org, then re-check.

Step 2: Install Claude Code
The straightforward path is npm:

powershell

npm install -g @anthropic-ai/claude-code

Heads up, this might fail. It did for me. The error looked like this:

Program 'claude.exe' failed to run: The specified executable is not a valid application for this OS platform

If you hit this, don't fight it, switch methods. Uninstall the npm version and use Anthropic's native installer instead:

powershell

npm uninstall -g @anthropic-ai/claude-code
irm https://claude.ai/install.ps1 | iex

If the install script also stalls or throws a file-access error, it's usually a leftover claude.exe process holding a file lock. The locked file is an .exe, not a .zip the exact filename appears in the error message itself, so copy it from there rather than guessing:

Fix:

Close every terminal window and tab you have open, not just the one running the installer.
Open Task Manager (Ctrl + Shift + Esc) → Details tab → look for claude.exe → if it's there, End Task.
Clear the locked cached download(adjust the filename to match whatever version is failing)
:

powershell

   Remove-Item "$env:USERPROFILE\.claude\downloads\claude-2.1.220-win32-x64.zip" -Force

Open a fresh PowerShell window as Administrator.
Run the install again:

powershell

   irm https://claude.ai/install.ps1 | iex

Step 3: Add Claude Code to Your PATH (missing from most guides, but you will likely need this)

Even after a successful native install, Windows often won't recognize the claude command yet. The installer itself tells you why, right in its output:

Native installation exists but C:\Users\<you>\.local\bin is not in your PATH.

Fix it manually:

Search "environment variables" in the Start menu → open "Edit the system environment variables."
Click Environment Variables...

Under User variables, select Path, click Edit, then New, and add:


C:\Users\<yourusername>\.local\bin

Click OK on every open dialog.
Close your terminal completely, open a fresh one, and confirm:

powersell

claude --version

You should now see a version number like 2.1.220 (Claude Code).

Step 4: Get Your Agent Router API Token

Head back to your Agent Router console → API Token. If you haven't created one yet, the list will be empty. Click Create Token

Fill it in:

Name: anything recognizable, e.g. "Claude."
Expiration time: pick "Never expires" explicitly. Don't leave the default placeholder date as-is, it can look like an already-expired timestamp.
Quota: caps how much of your balance this specific token can spend. Leave "Unlimited quota" off if you want a hard ceiling.

Submit, then copy the generated key. It'll look like sk- followed by a long string. This is the key you must not show in screenshots.

Step 5: Set Your Environment Variables

The original version of this guide has you set three variables, including both ANTHROPIC_AUTH_TOKEN and ANTHROPIC_API_KEY with the same value. In practice, setting both at once triggers a conflict warning every time Claude Code launches. It doesn't break anything, but it's unnecessary. Set only the base URL and the auth token:

powershell

setx ANTHROPIC_BASE_URL "https://agentrouter.org/"
setx ANTHROPIC_AUTH_TOKEN "sk-your-key-here"

If you already set ANTHROPIC_API_KEY earlier (from following the original three-variable version), remove it so it doesn't conflict:

powershell 

[System.Environment]::SetEnvironmentVariable("ANTHROPIC_API_KEY", $null, "User")
Remove-Item Env:ANTHROPIC_API_KEY -ErrorAction SilentlyContinue

To confirm it's actually gone (check in a fresh terminal window, not the one you set it in):

powershell

echo $env:ANTHROPIC_API_KEY
echo $env:ANTHROPIC_AUTH_TOKEN
[System.Environment]::GetEnvironmentVariable("ANTHROPIC_API_KEY","User")
[System.Environment]::GetEnvironmentVariable("ANTHROPIC_API_KEY","Machine")

ANTHROPIC_API_KEY should print nothing on all four.
ANTHROPIC_AUTH_TOKEN should print your key.

Important: After setting these with setx or the GUI, close and reopen your terminal completely. setx doesn't apply to windows that are already open.

Step 6: Tell Claude Code Which Model to Use

This step gets skipped in most guides, and it matters. Without it, Claude Code falls back to its own default model behavior, which may not match what your Agent Router token is actually scoped to use, especially if you set a model restrictions list on the token itself (visible under the token's Access Restrictions section in the Agent Router console).

You may see advice online telling you to run claude --model claude-3-opus. Don't use that, it names a model that's no longer current, and a one-off flag only applies to that single session. Set it permanently instead, alongside your other two variables:

powershell

setx ANTHROPIC_MODEL "claude-opus-4-8"

Use whichever exact model identifier your Agent Router console lists for you, check Console → API Token → your token → Access Restrictions → Model restrictions list to see the exact strings it supports (for example claude-opus-4-8, claude-opus-5, or non-Claude options like gpt-5.6-sol if you want to route to a different provider entirely through the same gateway).

If you leave a token's model restrictions blank, it supports all models Agent Router offers, in which case setting ANTHROPIC_MODEL just pins Claude Code to a specific one instead of leaving it ambiguous.

Close and reopen your terminal after setting this, same as the other variables.

A note on running out of credits

At some point your token's quota (or your account balance) will hit zero. When that happens, Claude Code won't crash outright, you'll get an authentication or request error back from Agent Router mid-session, usually something referencing a 402 or quota-exceeded response. If you see requests suddenly failing after previously working fine, that's the first thing to check, not your PATH or your variables.

Fix: go back to Console → API Token, either top up your account balance or generate a fresh token if the old one expired, then repeat Step 5 with the new key.

Step 7: Launch Claude Code
Open a fresh terminal and run:

powershell

claude

If you followed Step 5 and only have ANTHROPIC_AUTH_TOKEN set, this warning won't appear at all, and you'll go straight to the folder trust check:

Folder trust check: Claude Code asks if it's okay to read/edit/execute files in your current folder. Choose "Yes" if it's your own project.

Once you're past this, you're in.

Step 8: Confirm the Credits Are Actually Being Used

Go back to your Agent Router dashboard. You should see your balance ticking down and a request log building up as you use Claude Code.

If the numbers are moving, it's working. You're now running Claude Code on Agent Router's credits instead of a direct Anthropic subscription.

One more check: make sure it's not silently falling back to Anthropic

Setting the variables correctly doesn't guarantee Claude Code is actually using them, if any of the three (ANTHROPIC_BASE_URL, ANTHROPIC_AUTH_TOKEN, ANTHROPIC_MODEL) got typo'd, dropped, or overridden by a leftover settings.json entry, Claude Code can still run without erroring, just against Anthropic directly, quietly spending nothing from Agent Router while you assume it's working.

Don't just glance at the dashboard once, actually run one real request in Claude Code, then immediately check:

Agent Router's usage log (Console → Usage log) should show a new entry with a timestamp matching right now.
If the log is empty after a request that clearly went through, something's misconfigured, recheck Step 5's variables in a fresh terminal before assuming it's fine.

Part 4: Using Claude Code After Setup

Everything above only needs to happen once. After that, running Claude Code is quick, no admin terminal, no environment variables to re-set, none of it.

Step 1: Open a normal terminal

Regular PowerShell is fine now, you don't need Administrator anymore. All three environment variables (ANTHROPIC_BASE_URL, ANTHROPIC_AUTH_TOKEN, ANTHROPIC_MODEL) were set with setx, so they persist across every new terminal session automatically.

Step 2: Navigate to your project

powershell

cd C:\Users\<yourusername>\path\to\your\project

Run Claude Code from inside the actual project folder you want it working on, not your whole user directory, it scopes its file access to wherever you launch it from.

Step 3: Launch it

powershell

claude

First time in a given folder, you'll get the folder trust prompt again, choose "Yes, I trust this folder." You won't see this again for that same folder on future runs.

Step 4: Just talk to it
Once you're in, type what you want in plain language:

Fix the bug in src/components/Header.tsx
Explain what this function does
Add a dark mode toggle to the navbar
Refactor this component to use Tailwind instead of inline styles
Write tests for the useContract hook

It'll propose changes and show you what it plans to do before applying them. Review, approve, move on.

Quick sanity check, if it's been a while
If you haven't used it in a bit and want to confirm everything's still wired up correctly before diving in:

powershell

claude --version

A version number back means you're good to go straight into a project.

Quick Troubleshooting Recap

Problem	Fix
`claude.exe` "not a valid application for this OS platform"	Uninstall the npm version, use the native installer (`irm https://claude.ai/install.ps1 \\| iex`)
Install script hangs or throws a file-access error	Close all terminals, kill any `claude.exe` process in Task Manager, delete the exact locked file named in the error, retry as Administrator
`claude --version` says "not recognized" after a successful install	`.local\bin` isn't in your PATH yet, add it manually and open a fresh terminal
"Both `AUTH_TOKEN` and `API_KEY` set" warning	Avoidable entirely — only set `ANTHROPIC_AUTH_TOKEN`, skip `ANTHROPIC_API_KEY`
Environment variables not showing up after `setx`	Close and reopen your terminal completely — `setx` doesn't affect already-open windows

If you get stuck somewhere this guide doesn't cover, drop a comment below or reach out, happy to help troubleshoot. This setup has enough moving parts (Windows quirks especially) that something almost always breaks on the first try, you're not doing anything wrong.

Claude Code Ate My Storage, So I Asked Claude Code to Fix It

Thu, 16 Jul 2026 16:09:41 +0000

I knew AI tools and development work could take up storage, but using Claude Code ran through my space faster than you can say "go."

I started using Claude Code in the terminal in April, and honestly, it has been helpful. It helps me fix bugs faster, understand errors, and move through development quicker.

But it has also helped me finish my storage quicker.

At first, I did not realise how much space I was losing. I just kept working until Windows started reminding me that my storage was almost full every five minutes.

So, naturally, my first instinct was to ask Claude Code how to fix the problem it had helped create.

I asked it to give me a script that could clear about 15GB of storage.

It gave me one.

The first script

# --- CLAUDE CODE MASTER CLEANUP & OPTIMIZATION ---

# 1. AUTO-FIX: Set 2GB Node Memory Limit (Prevents 15GB Pagefile Bloat)
$varName = "NODE_OPTIONS"
$varValue = "--max-old-space-size=2048"
$currentValue = [Environment]::GetEnvironmentVariable($varName, "User")

Write-Host "⚙️  Optimizing system memory limits..." -ForegroundColor Cyan
if ($currentValue -like "*$varValue*") {
    Write-Host "   - ✅ Memory limit is already correctly configured." -ForegroundColor Green
} else {
    $newValue = if ($currentValue) { "$currentValue $varValue" } else { $varValue }
    [Environment]::SetEnvironmentVariable($varName, $newValue, "User")
    Write-Host "   -  Applied 2GB limit to Windows User Variables." -ForegroundColor Yellow
}

# 2. KILL LEAKING PROCESSES (Releases locked RAM/Pagefile)
Write-Host "`n Terminating orphaned Claude & MCP processes..." -ForegroundColor Yellow
$procs = Get-Process -Name "claude", "node" -ErrorAction SilentlyContinue | 
         Where-Object { $_.Path -match "anthropic" -or $_.CommandLine -match "mcp" }
if ($procs) {
    $procs | Stop-Process -Force
    Write-Host "   - Closed $($procs.Count) ghost processes." -ForegroundColor Green
}

# 3. GLOBAL CACHE CLEANUP
$claudePath = "$HOME\.claude"
if (Test-Path $claudePath) {
    Write-Host "`n Wiping global Claude cache (Logs, History, Temporary files)..." -ForegroundColor Cyan
    $folders = "debug", "projects", "file-history", "image-cache", "shell-snapshots", "todos", "plans"
    foreach ($folder in $folders) {
        $subDir = Join-Path $claudePath $folder
        if (Test-Path $subDir) { 
            Remove-Item -Path "$subDir\*" -Recurse -Force -ErrorAction SilentlyContinue 
        }
    }
}

# 4. DEEP SCAN: Hidden Worktrees & Project Memory
$searchRoot = "C:\code" # <--- Change this to your main folder if different
Write-Host "`n Deep scanning $searchRoot for hidden .claude folders..." -ForegroundColor Cyan
$worktrees = Get-ChildItem -Path $searchRoot -Include "worktrees" -Recurse -Hidden -ErrorAction SilentlyContinue | 
             Where-Object { $_.FullName -match "\.claude\\worktrees" }

if ($worktrees) {
    $worktrees | ForEach-Object {
        Write-Host "   - Removing: $($_.FullName)" -ForegroundColor Gray
        Remove-Item -Path $_.FullName -Recurse -Force -ErrorAction SilentlyContinue
    }
} else {
    Write-Host "   - No hidden worktrees found." -ForegroundColor Gray
}

# 5. FINAL SPACE AUDIT
$drive = Get-PSDrive C
$freeGB = [math]::Round($drive.Free / 1GB, 2)
Write-Host "`n✨ CLEANUP COMPLETE!" -ForegroundColor Green
Write-Host " Current Free Space: $freeGB GB" -ForegroundColor White
Write-Host " IMPORTANT: RESTART YOUR PC NOW to shrink the Pagefile and reclaim the full 15GB." -ForegroundColor Magenta

Notice section 5: it prints reclaim the full 15GB as fixed text. It never measured anything. That one line is the whole reason the numbers never added up.

I ran the script, and in the terminal it showed that around 15GB would be restored after restarting my PC.

I restarted.

I got back about 1GB.

Sometimes it was even just a few hundred MBs.

I ran the script again, and the same thing happened. The terminal would make it look like I was about to recover all this space, but when I checked my actual storage, almost nothing had changed.

At first, I thought Claude had given me a bad script.

But then I looked at my original prompt.

I had asked it to create a script that would clear 15GB every time I ran it.

That was the mistake.

A script cannot clear 15GB when that number was never measured in the first place. The "15GB" was just hardcoded text the script printed every time, no matter what it actually deleted. I was asking it to give me a specific result instead of asking it to first check what was actually taking up space.

So that part was not really Claude's fault. It was mine.

My prompt should have been something like:

Check which folders are using the most storage, identify what can safely be deleted, calculate the real size of those files, and create a script that reports the actual space recovered.

That would have made more sense than telling it, "Give me back 15GB."

I also tried clearing the cache for some of my apps manually, but that created another problem. The apps had to download some of the same information again, which cost me data.

I also ran npm cache clean --force, thinking it would help. npm politely warned me it had disabled its own protections and that the cache rebuilds itself anyway — so that freed almost nothing and just meant re-downloading later. Same lesson as before: clearing caches feels productive but mostly costs you data when everything downloads again.

I deleted ZIP files, old downloads, unused folders, extensions and other things I thought I no longer needed.

Still, the storage situation did not improve as much as I expected.

So today, I decided to put on my man pants and properly investigate the monster I had created.

I now have a better script that checks the available storage before and after the cleanup, instead of promising that it will magically recover 15GB every time.

The improved script

# --- CLAUDE CODE MASTER CLEANUP & OPTIMIZATION (v2) ---

# 0. MEASURE BEFORE — so we can report what we actually freed
$beforeGB = [math]::Round((Get-PSDrive C).Free / 1GB, 2)
Write-Host " Free space before cleanup: $beforeGB GB" -ForegroundColor White

# 1. AUTO-FIX: Set 2GB Node Memory Limit (caps FUTURE Node memory growth)
$varName = "NODE_OPTIONS"
$varValue = "--max-old-space-size=2048"
$currentValue = [Environment]::GetEnvironmentVariable($varName, "User")

Write-Host "`n⚙️  Optimizing Node memory limit (affects future sessions)..." -ForegroundColor Cyan
if ($currentValue -like "*$varValue*") {
    Write-Host "   - ✅ Memory limit already configured." -ForegroundColor Green
} else {
    $newValue = if ($currentValue) { "$currentValue $varValue" } else { $varValue }
    [Environment]::SetEnvironmentVariable($varName, $newValue, "User")
    Write-Host "   -  Applied 2GB cap to Windows User Variables." -ForegroundColor Yellow
}

# 2. KILL LEAKING PROCESSES
Write-Host "`n Terminating orphaned Claude & MCP processes..." -ForegroundColor Yellow
$procs = Get-Process -Name "claude", "node" -ErrorAction SilentlyContinue |
         Where-Object { $_.Path -match "anthropic" -or $_.CommandLine -match "mcp" }
if ($procs) {
    $procs | Stop-Process -Force
    Write-Host "   - Closed $($procs.Count) ghost processes." -ForegroundColor Green
} else {
    Write-Host "   - No orphaned processes found." -ForegroundColor Gray
}

# 3. GLOBAL CACHE CLEANUP
$claudePath = "$HOME\.claude"
if (Test-Path $claudePath) {
    Write-Host "`n Wiping global Claude cache (Logs, History, Temp files)..." -ForegroundColor Cyan
    $folders = "debug", "projects", "file-history", "image-cache", "shell-snapshots", "todos", "plans"
    foreach ($folder in $folders) {
        $subDir = Join-Path $claudePath $folder
        if (Test-Path $subDir) {
            Remove-Item -Path "$subDir\*" -Recurse -Force -ErrorAction SilentlyContinue
        }
    }
}

# 4. DEEP SCAN: Hidden Worktrees
$searchRoot = "C:\code"   # <--- change to your main code folder if different
Write-Host "`n Deep scanning $searchRoot for hidden .claude worktrees..." -ForegroundColor Cyan
$worktrees = Get-ChildItem -Path $searchRoot -Include "worktrees" -Recurse -Hidden -ErrorAction SilentlyContinue |
             Where-Object { $_.FullName -match "\.claude\\worktrees" }

if ($worktrees) {
    $worktrees | ForEach-Object {
        Write-Host "   - Removing: $($_.FullName)" -ForegroundColor Gray
        Remove-Item -Path $_.FullName -Recurse -Force -ErrorAction SilentlyContinue
    }
} else {
    Write-Host "   - No hidden worktrees found." -ForegroundColor Gray
}

# 5. FINAL SPACE AUDIT — report the REAL delta, not a guess
$afterGB = [math]::Round((Get-PSDrive C).Free / 1GB, 2)
$reclaimedGB = [math]::Round($afterGB - $beforeGB, 2)

Write-Host "`n✨ CLEANUP COMPLETE!" -ForegroundColor Green
Write-Host " Before: $beforeGB GB  |  After: $afterGB GB" -ForegroundColor White
Write-Host "♻️  Actually reclaimed: $reclaimedGB GB" -ForegroundColor White

if ($reclaimedGB -lt 1) {
    Write-Host "ℹ️  Small gain is normal — most space here is cache/logs." -ForegroundColor Gray
    Write-Host "    If your pagefile is system-managed and large, a reboot may free more." -ForegroundColor Gray
}

The difference is small but honest: the new version takes a snapshot before it starts, another at the end, and reports the real difference. No more magic 15GB.

So yey, progress.

At this point, I may still need to increase my storage or finally accept that this PC has served its time and purpose.

Unless someone here knows a safe way to clear Windows storage without deleting important project files or forcing my apps to download everything again.

Has anyone else had their storage disappear while using Claude Code or other AI development tools?

your AI coding agent keeps re-making the bug you already fixed. here's the fix.

Mon, 06 Jul 2026 01:15:02 +0000

Originally published on dev.to on June 9, 2026.

for the last few releases selvedge has been a write-only thing. an AI agent edits a column, calls log_change, and the reasoning gets captured into a little SQLite file under .selvedge/ next to your code. useful, but one-directional. the agent wrote to the store and then never looked at it again.

v0.3.7 is the release where that flips. there's a new MCP tool called prior_attempts, and the whole point of it is that the agent calls it before it changes something — not after. before editing users.email, the agent asks selvedge: what happened the last time someone touched this? who tried what, when, and why was it reverted?

this is the brand-defining release, so let me walk through why it's built the way it is.

the default flow used to be one-directional

here's what selvedge looked like through v0.3.6. an agent refactors users.email, and on its way out it calls log_change with a reasoning string — "tightened the email validator to reject plus-addressing per the billing team's request." that reasoning lands in the store. later, a human runs selvedge blame users.email from the CLI and reads it back.

that's the same posture every code-attribution tool has. git blame, AgentDiff, Origin, all of them. the reasoning is captured-then-read. the capture is one event in time; the read is a separate, asynchronous act by a different actor — usually a person, usually weeks later, usually because something already broke.

for a human-written codebase that's fine. people carry context between sessions. they remember "oh right, we tried that in march." the audit trail is a backup for the memory, not the memory itself.

`prior_attempts` is the asking primitive

so v0.3.7 adds the tool that does the asking. it's pull-model — the agent calls it, selvedge doesn't push. given a description or an entity_path, it returns prior change events at the same path (or the same shape) with their reasoning, their change_type, and an inferred outcome.

> prior_attempts(entity_path="users.email")

2 prior attempts at users.email:

[2026-03-14]  rename -> users.email_address   (reverted 2026-03-17)
  reasoning: "renamed for consistency with users.phone_number"
  outcome:   reverted — billing reconciliation join keyed on the
             literal column name; case-sensitivity broke the nightly job

[2026-01-22]  alter -> tighten type to citext  (abandoned)
  reasoning: "case-insensitive comparison at the db layer"
  outcome:   no follow-up commit; superseded by app-layer validation

the agent now has the context march-mason wrote down. and it does the thing the whole release is built to enable: it changes plan. it doesn't rename the column. it keeps users.email, hardens the validator at the app layer instead, and notes in its own log_change that it checked prior_attempts first. the loop closes.

no LLM call happens anywhere in there, by the way. the output is templated — selvedge assembles it deterministically from the rows in SQLite. that's a hard rule in the core: no model hops, no API key, no network, no non-determinism that's miserable to test. prior_attempts is a query and a string template, nothing more.

why the trust budget is non-negotiable

here's the design decision i went back and forth on the most. prior_attempts returns high-confidence results only by default.

the way it infers "outcome" in v0.3.7 is by proximity: an add followed closely by a remove of the same entity reads as "tried and pulled back." that's a heuristic, and heuristics have a noisy tail. so every result carries a confidence field — proximity_high or proximity_low — and the default response gives you proximity_high only. if you want the noisy long tail you have to explicitly ask for it with min_confidence="proximity_low".

the reason is the trust budget, and you only get one shot at it. the moment prior_attempts hands an agent a confident-looking false positive, the agent learns the tool is noise and starts ignoring it — and a tool the agent ignores is dead. an empty result is recoverable. a wrong result is not. so the default is tuned to prefer returning nothing over returning something wrong.

this is the same discipline as selvedge verify's two-tier exit codes from v0.3.5: build the strict floor first, then give the caller a knob to relax it if they want. conservative defaults are what keep the mechanism honest. the precise classifier comes later — v0.3.11 ships explicit reject and revert change_types so the high-confidence tier gets more accurate without the API changing at all.

the entity foundation that had to ship in the same release

you cannot ship a lookup tool when ./src/auth.py::login and src/auth.py::login store as two different entities. if they do, the recall problem masquerades as "prior_attempts didn't find anything," the agent proceeds confidently, and the tool has actively misled it — worse than not existing. so the canonicalization had to land first, inside the same release.

canonicalization on write is deterministic and boring on purpose: strip a leading ./, collapse //, normalize separators to /, trim whitespace. one chokepoint that both the MCP write path and the CLI go through, so nothing writes a non-canonical path after this release.

the one decision worth calling out: case is preserved, deliberately. filesystems disagree — macOS and windows are case-insensitive by default, most linux hosts are case-sensitive. if selvedge silently lowercased everything, it would collapse two entities that are genuinely distinct on a case-sensitive host. so it preserves case, and selvedge doctor grows a should-warn row that flags sibling paths differing only by case, so you find out instead of getting a silent merge.

for existing databases there's selvedge migrate-paths. it's --dry-run by default — you have to pass --apply to write anything — and the dry run prints a collisions report showing which pre-canonicalization paths would converge to the same value. you get to look at the merge before it happens. it's idempotent, and every run drops an audit row into a new path_migrations table so the operation stays visible.

and the explicit non-goal, because it comes up every time: no code parser, no AST. selvedge does not read your source and extract entities. it stores what the agent tells it, canonicalized and queryable. AST work is language-specific, drags in a pile of dependencies, and fights the dependency-free-core rule that keeps the install at three deps. it's a line i'm holding.

what the prompt block changes

a new MCP tool that nobody calls is worthless, and agents don't spontaneously discover query tools. so the flywheel is one line in the agent's instruction block. selvedge prompt now leads with:

Before editing an entity, call prior_attempts on it.

that's the first instruction now, not a footnote under the log_change guidance. it's what turns write-only agents into read-then-write agents. without it, the whole release is a tool sitting in a listing that never fires.

existing users get the change cleanly because the prompt block is sentinel-bracketed (the  /  markers from v0.3.4). run selvedge prompt --install CLAUDE.md and only the bracketed region updates — the rest of your prompt file is untouched.

this brings the MCP surface to 7 tools. exactly one new tool this release — rename support folded into log_change as a parameter rather than its own tool, and the aggregate-digest helper shipped as a plain library function instead of a tool. keeping the surface small is its own discipline.

what's next

v0.3.7 makes the wedge legible. the next releases make it visible where you already work:

v0.3.9 brings the developer-facing CLI surface: selvedge audit (flags PRs that changed code without logging why), selvedge digest (summarizes recent activity per entity), selvedge pr-comment (drops the relevant prior_attempts hits straight into a PR review).
v0.3.11 ships explicit reject / revert change_types so the proximity classifier becomes a precise one.
v0.4.0 lifts the whole thing onto an optional HTTP + Postgres layer so teams stop fighting per-machine SQLite — still self-hosted, still never sending your data anywhere.

if you want to try the read-before-you-edit flow:

pip install selvedge==0.3.7
selvedge setup        # detects claude code / cursor / copilot

then point your agent at a repo with some history and ask it to refactor something you've touched before. watch it call prior_attempts and think twice.

changelog: https://github.com/masondelan/selvedge/releases/tag/v0.3.7

(a 60-second clip of claude code calling prior_attempts mid-task and changing course is coming — i'll add it to this post once it's up.)

it's open source, MIT, runs entirely on your machine. happy to answer anything about the proximity classifier or the canonicalization rules in the comments.

The silent problem with AI-written code: the intent evaporates

Mon, 06 Jul 2026 01:14:53 +0000

Originally published on dev.to on April 24, 2026.

There's a problem with AI-written code that nobody talks about yet, because most of us haven't been using AI agents long enough for it to bite us.

The problem is this: AI agents know exactly why they made every decision. And then the session ends.

What happens with human code

When humans write code, intent leaks everywhere. It's in the commit message ("Add phone field for 2FA rollout"), the PR description, the Slack thread that preceded it, the inline comment that explains the weird edge case. You can reconstruct why a decision was made months later because the evidence trail is thick.

This works because humans understand that their code will outlast their memory of writing it.

What happens with AI-written code

An AI agent has perfect clarity about why it's making each change — right up until the conversation ends.

Run git blame six months later:

3e7a991 (Claude Code  2025-10-14)  user_tier_v2 VARCHAR(20)

Commit message: "Update schema"

The agent knew why. It added user_tier_v2 to support a grandfathering flag during a pricing migration. It stored the original tier so you could backfill discounts without touching billing history. It was a careful, intentional decision — and that context is completely gone.

This isn't a hypothetical. If you've been using AI coding tools for more than a few months, you've already hit this wall. You just might not have noticed yet.

The pandas moment

When pandas came out, data scientists were doing data manipulation with raw Python loops and NumPy. The problem wasn't that it was impossible — it was that there was no shared infrastructure for it, so everyone was reinventing the same patterns badly.

Pandas became essential infrastructure. Not a feature, not a nice-to-have — infrastructure.

I think codebase change tracking is the same problem for AI-era development. Right now, every team using AI agents heavily is slowly accumulating a codebase full of decisions that made perfect sense when the agent made them and are increasingly opaque to everyone who touches the code afterward.

Selvedge

I built Selvedge to capture that reasoning before it's gone.

It's an MCP server. AI agents (starting with Claude Code) call it as they work to log structured change events — what changed, when, which agent, which commit, and crucially: why.

$ selvedge blame users.stripe_customer_id

  users.stripe_customer_id
  Changed     2026-03-14 11:22:01
  Agent       claude-code
  Commit      9c3f441
  Reasoning   User asked to add Stripe billing — needs customer ID to link
              accounts to subscriptions without storing card details locally.

That Reasoning field is captured from the agent's context in the moment, before the session ends. It's not generated by Selvedge — Selvedge just captures what the agent already knows and stores it somewhere you can query later.

How it works

Setup is three steps:

Install:

pip install selvedge
cd your-project && selvedge init

Add to your Claude Code config (~/.claude/config.json):

{
  "mcpServers": {
 "selvedge": { "command": "selvedge-server" }
  }
}

Add a few lines to your project's CLAUDE.md:

You have access to Selvedge for change tracking.
Call selvedge.log_change immediately after adding, modifying, or removing
any DB column, table, function, API endpoint, dependency, or env variable.
Set reasoning to the user's original request or the problem being solved.

From then on, your agent logs changes automatically as it works.

Querying your history

The CLI is built for how you actually investigate codebases:

# What changed in the users table in the last 30 days?
selvedge diff users --since 30d

# What was the last change to payments.amount and why?
selvedge blame payments.amount

# Everything related to the Stripe billing feature
selvedge search "stripe"

# How often is my agent actually logging changes?
selvedge stats

There's also a changeset system — you can tag related changes under a shared slug ("add-stripe-billing") and reconstruct the full scope of a feature across multiple entities later:

selvedge history --changeset add-stripe-billing

Backfilling existing projects

If you already have a project with migration files, you don't have to start from zero:

selvedge import ./migrations/

It parses raw SQL DDL and Alembic Python files and backfills your schema history. Not as rich as captured reasoning, but better than nothing.

What's next

Right now Selvedge uses local SQLite, which works great for individual developers and small teams with a shared volume. Phase 3 is a PostgreSQL backend and HTTP REST API so teams can share a history across machines — that's the path to making this a proper team tool.

The core insight I keep coming back to: the diff is git's job. The why is Selvedge's job.

If you've been using Claude Code or Cursor heavily and have felt this pain, I'd love to hear how you've been handling it (or whether you've just been living with it). And if you try Selvedge, feedback on what's missing would go a long way.

Current version: v0.3.1 — shipped today (April 23, 2026). It's a hardening release: connection-with-retry and PRAGMA busy_timeout = 5000 so concurrent writes are safe under contention (tested against 8 threads writing simultaneously), an explicit schema_migrations table replacing the old swallow-OperationalError-and-pray ALTER pattern, structured logging under the selvedge.* namespace (SELVEDGE_LOG_LEVEL=DEBUG to turn it up), and a frozen public API surface locked in by test. The preceding release (v0.3.0) was a correctness pass that caught a pile of silent-wrong-answer bugs: --since 5m used to mean 5 months instead of 5 minutes; SQL LIKE wasn't escaping _ or % in search queries; CREATE TABLE import emitted zero events for inline columns; mixed-timezone timestamps sorted incorrectly because -08:00 is less than +00:00 in ASCII. Both are recommended upgrades.

GitHub: https://github.com/masondelan/selvedge
Install: pip install selvedge

Claude Opus 4.8 vs Claude Fable 5: Which Model Should You Actually Use?

Wed, 10 Jun 2026 22:45:54 +0000

Anthropic now ships two models that both feel like "the best one": Claude Opus 4.8, the top of the long-running Opus family, and Claude Fable 5, a brand-new tier that sits above Opus entirely. If you build with these models, the practical question isn't "which is better" - it's "which one do I send each task to, and is the more expensive one worth it?"

This is a developer-focused, no-hype comparison of Claude Opus 4.8 vs Claude Fable 5: where they're identical, where they differ in ways that actually affect your code and your bill, and a clear decision guide. Everything here is grounded in Anthropic's model and API documentation - no invented benchmarks.

TL;DR

Fable 5 is the most capable model - a new tier above Opus - at roughly double the price (USD 10/USD 50 vs USD 5/USD 25 per million tokens).
Opus 4.8 is the top of the Opus family, a strong default in Claude Code, and the better capability-per-dollar choice for most hard work.
They share almost the entire API surface. The one breaking difference: setting the thinking type to disabled is accepted on Opus 4.8 but returns 400 on Fable 5 (omit the thinking field instead).
Decision rule: default to Opus 4.8; escalate to Fable 5 only for the tasks where a wrong answer is expensive.

The Lineup Context

Until Fable 5, "Opus" was the top of the Claude ladder. Fable 5 adds a rung above it. The full 2026 family, from most to least capable:

Claude Fable 5 - peak capability, premium price
Claude Opus 4.8 - top of the Opus family, strong all-rounder
Claude Sonnet 4.6 - balanced daily driver, 1M context
Claude Haiku 4.5 - light, fast, cheap

So "Opus 4.8 vs Fable 5" is really a question about the top two rungs: when is the absolute peak worth paying for, and when is the top-of-Opus model already enough? For a structured, side-by-side breakdown of the whole 2026 lineup, there's a dedicated AI model comparison course (https://cursuri-ai.ro/courses/comparatie-modele-ai) that goes further than any single article can.

The Spec Differences at a Glance

Claude Opus 4.8

Tier: top of the Opus family
Model ID: claude-opus-4-8
Price: USD 5 / USD 25 per 1M tokens (input / output)
thinking: disabled: accepted
Min cacheable prefix: ~4,096 tokens
Role in Claude Code: strong default
Released: late May 2026

Claude Fable 5

Tier: a new tier above Opus (most capable)
Model ID: claude-fable-5
Price: USD 10 / USD 50 per 1M tokens (input / output)
thinking: disabled: returns 400 - omit the param instead
Min cacheable prefix: ~2,048 tokens
Role in Claude Code: selectable peak
Released: newer (2026)

Identical on both: 1M-token context window, 128K max output, adaptive thinking, the full effort range (low-max, including xhigh), sampling params removed (temperature/top_p/top_k all return 400), and last-assistant-turn prefills removed (400).

Two of those differences do most of the work for an engineering decision: price (2x) and the thinking: disabled gotcha. We'll come back to both.

Where They're Identical (Don't Agonize Over These)

A lot of the "which model" anxiety evaporates once you realize how much these two share. Both Opus 4.8 and Fable 5:

Use adaptive thinking (the thinking type set to adaptive) - the model regulates its own reasoning depth; there's no token budget to tune.
Expose the same effort parameter (low through max, including xhigh), with xhigh as the sweet spot for coding and agentic work.
Reject sampling parameters - temperature, top_p, and top_k all return 400. You steer behavior with prompting and effort.
Reject last-assistant-turn prefills (400). Use structured outputs (output_config.format) instead.
Support structured outputs, prompt caching, server-side compaction, web search with dynamic filtering, and task budgets (beta).
Share a 1M context window and 128K max output (stream anything above ~16K max_tokens to avoid SDK timeouts).
Hide thinking text by default - set the thinking display to summarized if you surface reasoning in a UI.

In other words: code written for one mostly runs on the other. The differences are about positioning and economics, plus one sharp API edge.

Where They Differ (The Decision-Relevant Deltas)

Capability tier

Fable 5 is genuinely a level above Opus 4.8 - it's positioned for the hardest reasoning, planning, cross-cutting refactors, and long-horizon agent runs. Opus 4.8 is no slouch; it's the top of the Opus family and handles complex day-to-day work well. The gap shows up at the extreme end of difficulty, not on routine tasks.

Price (the 2x that decides everything)

Fable 5 costs about double Opus 4.8 per token. This single fact should drive your architecture: you don't run a pipeline entirely on Fable 5 any more than you'd hire your most expensive specialist to answer the phone. You route the hard parts to it and let cheaper models do the rest.

The thinking: disabled gotcha (will break your code)

This is the one difference that bites in practice. On Opus 4.8, you can explicitly disable thinking: you pass a thinking field with its type set to disabled, and the request succeeds.

Send that exact request to Fable 5 and you get a 400. To run Fable 5 without thinking, you do NOT set the type to disabled - you omit the thinking field entirely, and the model runs with no thinking and no error.

So the rule when you swap the model ID: on Opus 4.8, a thinking type of disabled is valid; on Fable 5, drop the thinking field instead. If you have a shared wrapper that parametrizes the model, this is the line that will surprise you. Guard it.

Caching minimum prefix

Opus 4.8 only caches prefixes of ~4,096 tokens or more; Fable 5 caches from ~2,048 tokens. Concretely: a ~3K-token system prompt will be cached on Fable 5 but silently won't cache on Opus 4.8 (no error - cache_creation_input_tokens just stays 0). If you rely on prompt caching to control cost, check this when you switch models.

Default vs. peak

In Claude Code, Opus 4.8 remains a strong default; Fable 5 is the tier you select for the hardest work. "Most capable" and "the default" are different claims - don't conflate them.

Switching Between Them Without Breaking Things

If your code parametrizes the model ID, run through this checklist before you flip the switch - most "it worked on Opus, it 400s on Fable" bugs are on this list:

Disabling thinking: omit the field, don't set it to disabled. The single most common break on Fable 5; drop the field entirely.
Re-check your cache hits. A prefix that caches on Fable 5 (at least ~2K tokens) can fall below Opus 4.8's ~4K minimum, or vice versa. Watch cache_read_input_tokens after switching - a silent 0 means the prefix is now too short to cache, and you'll quietly pay full price on every request.
Re-tune effort, don't assume. xhigh on Fable 5 and xhigh on Opus 4.8 produce different cost and latency profiles. Sweep medium / high / xhigh per route after the swap instead of carrying the old setting over.
Budget for the price delta. A wrapper that silently routes everything to Fable 5 doubles your token bill overnight. Make escalation to the top tier explicit and intentional, not a default.
The rest is shared. Adaptive thinking, removed sampling params, no prefills, structured outputs, and streaming for large max_tokens all behave the same - so you don't need model-specific branches for those.

A thin abstraction that exposes model and effort as per-task config (rather than hard-coding one model everywhere) turns this kind of switch into a one-line change instead of a refactor - and makes A/B-ing the two models trivial.

The Cost Math: When Is 2x Worth It?

"Use the best model" is bad engineering advice. The right framing is: Fable 5 pays off when the cost of a wrong answer exceeds the extra token cost.

Send to Fable 5: the planning step that sets the trajectory of a long agent run; a complex cross-service refactor where a subtle regression costs hours of review; an analysis where correctness is non-negotiable.
Keep on Opus 4.8 (or below): routine edits, summaries, classification, and the long tail of mechanical sub-tasks.

A clean pattern that keeps your bill proportional to difficulty: let Fable 5 plan and decide, and let Opus 4.8 / Sonnet 4.6 execute the parts that are already well-specified. If you're building this kind of tiered routing into an agent, the orchestration patterns are worth studying properly - this course on designing autonomous AI agents (https://cursuri-ai.ro/courses/ai-agents-automatizare) and a Claude Code mastery course (https://cursuri-ai.ro/courses/claude-code-mastery-coding-agentic) both cover model routing as a first-class concern rather than an afterthought.

Don't forget effort as a second lever. Because effort matters more on this generation than on any prior Opus, a Fable 5 call at medium can sometimes be cheaper and faster than an Opus 4.8 call at xhigh. The only way to know for your workload is to measure.

How to Actually Decide: Eval It, Don't Argue About It

Spec differences tell you what might matter. They can't tell you whether Fable 5's extra capability moves the needle on your task. The only reliable answer comes from running both models against a representative slice of your real work and scoring the outputs.

That means a small eval harness: a fixed set of inputs, a scoring rubric (exact-match, an LLM judge, or a task-specific check), and a side-by-side run of claude-opus-4-8 vs claude-fable-5 at the effort levels you'd actually use. You don't need a giant benchmark to get a signal - even 20 to 50 representative cases from your real traffic are usually enough to tell whether the 2x is buying you a measurable quality lift or just a bigger invoice. If Fable 5 wins by enough to justify 2x the cost on the hard subset, route that subset to it. If it doesn't, you just saved money with data instead of vibes. Building that discipline is exactly what a course on AI evals for LLMs in production (https://cursuri-ai.ro/courses/ai-evals-llm-productie) is for - testing, scoring, and quality gates before you commit a model to production.

The quality of your prompts also shifts the result. Since both models are steered through prompting and effort rather than sampling parameters, a sloppy prompt can make the expensive model look only marginally better than the cheap one. A structured refresh of prompt engineering fundamentals (https://cursuri-ai.ro/courses/prompt-engineering-masterclass) often closes more of the gap than upgrading the model does. And if you're wiring either model into a real application, the building-AI-apps-with-the-Anthropic-SDK course (https://cursuri-ai.ro/courses/construire-aplicatii-ai-python-sdk) walks the full path from raw API calls to production.

The Verdict

There's no single winner - there's a routing decision:

Reach for Opus 4.8 when:

You want the best capability-per-dollar for hard work.
You're building on Claude Code and want a strong, cost-sane default.
You need to explicitly disable thinking via the API (it's accepted here).
Your cacheable prefixes are comfortably above ~4K tokens.

Reach for Fable 5 when:

The task is at the extreme end of difficulty and a wrong answer is expensive.
It's the planning/decision step that steers a long agent run.
You've measured a real quality lift on your own eval that justifies the 2x cost.

Conclusion

Claude Opus 4.8 vs Claude Fable 5 isn't a fight to crown one model - it's a two-rung ladder you climb only when the task demands it. Default to Opus 4.8, escalate to Fable 5 where correctness compounds, tune effort per route, and let an eval (not a launch-day headline) make the final call. Do that, and the more expensive model becomes a precision instrument instead of a surprise on your invoice.

The courses linked throughout are part of Cursuri-AI.ro (https://cursuri-ai.ro/courses/comparatie-modele-ai), a Romanian AI-learning platform with hands-on tracks on model selection, evals, Claude Code, agent architecture, and the Anthropic SDK - all kept current with the 2026 lineup, Fable 5 and Opus 4.8 included.

Which one are you routing your hard tasks to - and where did the 2x actually pay off? Drop your routing strategy in the comments.

When Your AI Stops Pretending to Know the Answer

Mon, 01 Jun 2026 11:34:16 +0000

AI models have a confidence problem. They generate clean, authoritative output — even when the underlying reasoning is shaky. For developers, that's not just annoying. It costs time.

Anthropic's latest release, Claude Opus 4.8, is built to address this directly. The model is more likely to flag uncertainty and less likely to assert claims it can't support. According to Anthropic's internal evaluations, Opus 4.8 is roughly four times less likely than its predecessor to let flaws in generated code pass without remarking on them.

That's a meaningful shift in how the model behaves during the work that matters most.

The Confidence Problem in Code

If you've used AI for code review, debugging, or documentation, you've seen this play out. The model produces output that looks right. It compiles. The logic flows. And then, somewhere in production — or during a code review — someone catches a subtle error the AI glossed over without comment.

The issue isn't that the model got it wrong. Models get things wrong. The issue is that it didn't tell you it was uncertain. It presented a flawed answer with the same tone as a correct one.

Opus 4.8 is designed to surface that uncertainty earlier. Instead of generating polished output with a hidden flaw, the model is more likely to flag where its reasoning is thin or where it's working with incomplete information.

What This Looks Like in Practice

For developers using Claude Code, the practical impact is measurable. Anthropic says Opus 4.8 can handle codebase-scale migrations — across hundreds of thousands of lines of code — from start to merge, using existing test suites as the validation bar. The honesty improvements reduce silent failures in long-running agentic tasks, which is where confident-but-wrong outputs cause the most damage.

Anthropic also shipped a few other features alongside the model:

Dynamic Workflows (research preview) lets Claude spin up hundreds of parallel subagents within a single session. It's aimed at large-scale tasks that would otherwise require manual orchestration — available to Enterprise, Team, and Max users through Claude Code.

Effort controls let you decide how much compute the model applies to a task. High effort is the default. You can dial up to "extra" or "max" for intensive work, or pull back for faster, cheaper responses on simpler tasks.

Fast mode is now roughly 2.5 times quicker and three times less expensive than in Opus 4.7. Pricing is unchanged from the prior version.

Why Honesty Is a Feature, Not a Personality Trait

There's a tendency to frame model honesty as a philosophical or safety concern. For developers, it's a workflow concern.

When a model flags its own uncertainty, you know where to focus your review. You can trust the parts it didn't flag and spend your time on the parts it did. That's a fundamentally different — and more useful — way to work than reviewing everything because you can't tell the difference between what the model knows and what it's guessing.

This matters even more in agentic workflows, where a model is running tasks without a human in the loop at every step. A model that silently generates flawed output and keeps going is a much bigger problem than one that stops and says "I'm not sure about this."

The Takeaway

Opus 4.8 doesn't fix every trust problem in AI-assisted development. But a model that reliably surfaces its own uncertainty changes how you can structure your review process — and how much cognitive load you carry when you're working alongside it.

Getting an answer right is useful. Knowing when to question the answer is better.

Anatomy of a Coding Agent: What I Learned Building My Own

Thu, 21 May 2026 20:33:45 +0000

You use Claude Code every day. But do you really know it?

I didn’t. Not really. I could describe the surface, but I couldn’t tell you what was actually happening between hitting enter and seeing a diff. The harness was a black box, and that started to bother me. The only way I knew to fix that was to build one.

The result is oli, a single-binary terminal coding agent written in Rust that runs against Ollama by default. It got much larger than I expected. Every “small” subsystem (memory, policy, tool dispatch, provider quirks) turned out to have its own thicket of edge cases. I learned more about coding agents in a few weeks of building one than I had in a year of using them daily.

The hard parts aren’t clever prompts. They’re context management, tool design, policy gates, memory strategies and, if you want to run locally, survival engineering for models that don’t behave like the GPT-5 or Claude 4 families. This post is a tour of those parts, with the failures that taught me each one.

The Big Picture

Before diving into components, here’s what a coding agent actually looks like:

The Agent Loop

Every coding agent runs the same basic loop:

Think → call → observe → repeat. The loop is deceptively simple. Everything hard lives in the details.

Three things I learned the hard way:

Turn limits matter, even on local models. Early on, a local model I was testing got stuck, it looped 47 times trying to “fix” a file that was already correct, burning through my entire context window before I caught it. The model wasn’t broken. The harness was: no turn limit, no escape hatch, no awareness that the model had lost the plot. The instinct is to say “who cares, I’m running locally, tokens are free.” But the cost isn’t dollars, it’s coherence. As context fills, models degrade: attention spreads thinner, instructions in the middle of the window get ignored (“lost in the middle”), and every failed attempt becomes a distractor that biases the next turn toward more wrong behavior. This is especially true on local models, whose effective context is often a fraction of their advertised window — a Qwen3 advertised at 256K may stay coherent only through the first 32-64K. A runaway loop doesn’t just waste compute; it actively makes the agent stupider for the rest of the session. Now subagents get hard turn limits by default, and the top-level agent is capped too, with a config default you can override per run.

The system prompt is pinned. It survives /clear, survives memory compaction, survives everything. The first time I accidentally cleared the system prompt mid-session, the model forgot what tools it had and started apologizing for being unable to help. Pinning was an obvious fix in hindsight.

Re-entrancy is a trap. A Task tool that spawns a subagent which can itself spawn subagents quickly becomes a fork bomb. oli sidesteps the whole problem by registering Task only in the parent agent — subagents get the same tool set minus Task, so they can’t recurse.

The System Prompt

Before you say anything, the model already gets a lot of scaffolding:

The AGENTS.md + CLAUDE.md line matters. Both Codex and Claude Code established conventions for per-project agent instructions. oli reads both, at every directory level from your current location up to the filesystem root — so a workspace-wide convention can be overridden by a project-level one without copy-pasting.

Note that the system prompt text and the tool schemas are separate payloads in the provider request — a better mental model than “everything lives in one giant prompt.”

The system prompt is expensive. It consumes tokens on every single turn. I learned this when a project with nested AGENTS.md files at multiple levels ate 8,000 tokens before I’d typed anything. Now oli caps injected project context at 16KB total and truncates directory listings at 50 entries. This is also where prompt caching pays off: both the prompt and the tool schema payload are highly stable across turns. Anthropic’s API supports marking that stable prefix as cacheable, and oli supports Anthropic-style cache breakpoints on Claude routes through OpenRouter too. Anthropic prices cached input tokens at roughly 10% of the regular rate, so caching shaves a large chunk off every subsequent turn in a long session.

Tools: The Model’s Hands

The tool surface defines what the agent can do. Too few tools and it’s frustrating. Too many and the model gets confused, especially local models with smaller context windows.

A small core for the work, plus a handful of paging and notes tools. The design principles emerged from failures:

Minimal surface. I started with more, and the model kept picking the wrong tool or stacking calls when one would do. Keeping the core small and bolting on paging and notes tools turned out to be the right shape. Each does one thing. These choices mirror what Claude Code, Cursor’s Composer, and Aider converged on independently — a signal that the design space is narrower than it looks.

Bounded output. Every tool truncates at 30KB. I learned this after the model Read a minified vendor.js file and blew through 180,000 tokens in one call. Now truncation markers embed a cache ID; the model can call ShowFull(id, offset) to paginate the stashed body if it actually needs more.

The read-first invariant. Edit refuses to run unless you’ve Read the target file this session. This prevents edits based on stale context — the model can only modify what it’s actually seen this turn:

Tools own their cleanup. When you Ctrl-C a bash command, the harness has to kill not just the shell but every process it spawned. I found this out when orphaned sleep processes from cancelled test runs accumulated over a week. A tool that spawns side effects has to know how to undo them — otherwise they leak into the user’s environment, and the harness gets blamed for the mess.

Memory & Context Management

Context windows are finite. Even 200K tokens fills up fast when you’re reading files, running tests, and iterating. Every tool result eats tokens.

The default strategy is LinearWithCompact: hold messages in order, and when approaching the context limit, summarize older turns into a rolling summary. Compaction triggers at 80% of context window. It finds a cut point at a user-message boundary (never split a tool_call from its result), sends older messages to the LLM with a summarization prompt, and replaces them with a summary message.

That part is straightforward. The bug that ate three days of debugging was cancellation under compaction.

Here’s the scenario. You hit Ctrl-C mid-turn to stop the model. The REPL is supposed to roll back to the last clean state — the user prompt you just sent. Simple, when the message buffer is the source of truth: count back N messages, restore.

Except compaction had already run. The “last 12 messages” the rollback wanted to restore no longer existed — they’d been collapsed into a summary. So Ctrl-C would silently roll the conversation back to somewhere random, often before the work the user was trying to cancel.

The fix was a one-line concept that took a day to see: stop treating the message array as the source of truth for where you are. oli tracks a monotonic record_count that increments on every logical turn, independent of physical message storage. Compaction drains messages, but the record count keeps climbing. Rollback targets a record count, not an array index — so the buffer can shrink underneath without the cursor losing its place.

Generalizable shape: any system that mutates history needs a stable identifier for “where you are” that isn’t the history itself. Memory management is also where coding agents silently fail — the model forgets what file it was editing, or repeats work it already did. The visible bugs are the easy ones.

Policy & Approvals

The policy engine gates every tool call. Without it, you’re one hallucinated rm -rf away from disaster.

Bash has its own allowlist: git status, cargo test, ls, and similar safe commands auto-approve; everything else prompts. The line-mode REPL is a plain y/N flow; the richer “allow this session” and persisted allowlist behavior are TUI affordances layered on top.

There’s no hard denylist yet, and I’m ambivalent about adding one. Prompt-on-every-mutation is annoying but transparent — you see exactly what the model is about to do. A denylist invites a long tail of “obviously safe” exceptions that gradually erode the gate. Today, blocking happens by denying an Ask decision: slower, but you stay in the loop.

The first time I saw the model attempt rm -rf target/ when I’d asked it to “clean up the build” and the approval prompt caught it, I understood why this layer exists. The model wasn’t malicious. It was being helpful in a way that would have been catastrophic without the gate.

Local-Model Survival

Frontier models handle tool calls cleanly: structured tool_calls arrays in the API response. Local models via Ollama? Not so much.

Many local models emit tool calls as plain text. Just raw JSON in the middle of their response. No structured field.

oli solves this with a fallback parser. When the model’s capability entry says supports_native_tool_calls: false, the agent loop scans content for JSON objects with a name field and splices them in as if they were real tool calls.

The model capability registry tracks what each model can do. Lookups are prefix matches against the model id, so claude-3-7-sonnet-latest matches the claude- row. Today’s hardcoded entries:

Prefix	Context	Native Tool Calls
`claude-` / `anthropic/claude`	200K	✓
`gpt-4`	128K	✓
`gpt-`	16K	✓
`llama3.1` / `llama3.2`	128K	✓
`llama3`	8K	✗
`qwen2.5-coder`	32K	✗
unknown (default)	8K	✗

Smoke tests against qwen3-coder:7b and llama3 showed they don’t behave as their docs claimed for tool calls, so they’re flagged off; the fallback parser handles them. Users override via [[caps]] in config — that’s how I run qwen3-coder:30b at 256K with native tools.

The gap between “works on Claude” and “works on qwen3” is enormous. If you’re building for local models, expect to handle every edge case they throw at you — and to discover new ones every time a model release widens the gap.

Provider Abstraction

One binary, many backends. The promise only works because of the language choice: Rust gives a single static binary with no runtime to install, shipping to Mac/Linux/Windows from the same cargo build. And the borrow checker turns out to be a surprisingly good fit for an agent loop — the lifetime and ownership bugs that bite hardest in async code, the compiler catches before I run anything.

Two provider kinds are available. Ollama, OpenRouter, OpenAI, LM Studio, vLLM, and llama.cpp’s server all speak OpenAI’s /chat/completions shape, so one openai-compat implementation covers them all — you just point base_url at the right endpoint. The native Anthropic provider is its own thing because it speaks the Messages API directly and does its own OpenAI-shape Anthropic-shape translation for tools, tool results, and system prompt handling.

Caching adds a wrinkle here: native Anthropic supports prompt caching directly, but oli also supports Anthropic-style cache breakpoints in the openai-compat path for Claude models routed through OpenRouter. So “native provider” and “cached prefix” are related, but not identical ideas.

The openai-compat provider still has to handle backend quirks. OpenRouter sometimes returns 200 OK with an error object in the body. The provider layer normalizes this.

The payoff: switching backends is a config flip, not a code change.

The Extension Surface

A harness is only useful if you can make it yours. oli has three extension axes:

All extensions route through the policy gate. No escape hatches.

What I Left Out

To keep this post focused on the load-bearing components, I skipped several surfaces that ship in oli today: an MCP client (stdio + HTTP transports, with live tools/list_changed deltas), a hook dispatcher (PreToolUse / PostToolUse / Stop), session persistence as JSONL transcripts (with --resume / --continue), and the slash-command layer (/compact, /provider, /model, /sessions, etc.). Each is its own subsystem with its own trade-offs — let me know if you want any of them as a follow-up.

What This Means

The harness is invisible until it breaks. When Claude Code feels brilliant, you credit the model. When it feels broken — losing context, blocking the wrong thing, looping on a fix — that’s almost always the harness. The orchestration layer is doing the heavy lifting either way; you only notice when it fails.

The hard problems are systems problems. Memory management, policy enforcement, tool design, provider abstraction, local-model survival. Engineering challenges, not prompt engineering.

Knowing the machinery makes you a better user. Context overflow, policy gates, compaction, capability mismatches — once you can name what’s happening, you can debug it. Or work around it.

The repo is at <a href="https://github

Bridging the Context Gap: Providing Structural Awareness to AI Coding Agents in Go with GoGraph

Thu, 14 May 2026 15:44:55 +0000

The hardest part of using AI coding agents isn't getting them to write Go code. It's watching them burn through your context window just trying to figure out where things are.

If you’ve spent any time using Claude, Antigravity or Copilot on a medium-to-large Go codebase, you know the drill. You ask the agent to modify a core component. Before it writes a single line of code, it starts blindly running grep, guessing file paths, and sequentially cat-ing files.

By the time the agent finally maps out the upstream HTTP handlers, the database interactions, and the interface satisfactions, it has exhausted a massive chunk of its token limit. The context window is bloated with irrelevant side-material and raw text dumps. The more noisy, unstructured code you feed the agent, the higher the chance it gets confused and starts hallucinating bad logic.

Agents don't fail because they are bad at writing logic. They fail because they have to brute-force their way to structural awareness.

I got tired of watching my AI tools waste tokens and context guessing my repository structure, so I built Gograph. It’s a local static analysis engine and Model Context Protocol (MCP) server that gives your AI agents a deterministic, whole-repository structural map of your Go projects in a single, token-efficient JSON query.

Why RAG and Terminal Searching Aren’t Enough

Right now, the industry usually tries to solve the codebase context problem in two ways: vector embeddings through RAG, or by letting agents inspect the repository through terminal commands. Both approaches are useful, but neither is sufficient on its own for reliable understanding of a large Go codebase.

The issue with RAG is that vector embeddings are good at semantic retrieval. If you want to find code related to “user authentication logic,” embedding search can often surface relevant files or nearby concepts. But embeddings do not provide deterministic code intelligence. They cannot prove that UserStore.Update() satisfies the Datastore interface, identify every caller across package boundaries, or trace how an error propagates through several layers of middleware. Those relationships require parsing, type checking, and static analysis.

The issue with terminal search is that agents often fall back to tools like grep, rg, or reading files directly. These tools are valuable for exact strings, symbols, config keys, routes, and quick navigation. But plain text search cannot reliably capture relationships that only exist after the compiler understands the program. In Go, interface satisfaction is implicit, indirect calls may flow through interfaces, and behavior may depend on build tags, generated code, or package-level wiring. A search-only approach is likely to miss non-obvious dependencies.

For large Go repositories, reliable agent context needs more than semantic search and raw file inspection. It needs compiler-aware code intelligence: symbols, packages, imports, interfaces, implementations, call graphs, route mappings, test relationships, and error flows. RAG can help find relevant areas. Terminal tools can help inspect concrete files. But the agent also needs structured knowledge of how the code actually fits together.

Fixing It With Static AST Analysis

Instead of relying only on semantic similarity or raw text search, I wanted a tool that gives agents structured knowledge of a Go repository.

Gograph uses Go’s native parsing infrastructure, including go/ast and go/parser, to build a static graph of your repository. It runs entirely on your local machine: no network requests, no sending proprietary source code to third-party APIs. Its goal is to map concrete code structure such as packages, symbols, functions, methods, struct fields, imports, call sites, route wiring, tests, and recognizable dependency paths.

Gograph ships with more than 20 specialized static analysis commands, including tools to map concurrency primitives, identify oversized objects, discover potentially dead code, and extract SQL-related structure. However, I designed three primary commands specifically to act as the core structural guardrails for AI agents.

1.gograph plan

Before an agent touches a file, it can run plan. Gograph analyzes the static code graph around the symbol and returns an impact-oriented view of the surrounding code.

It can show callers, related packages, upstream HTTP routes where they are statically detectable, whether the execution path appears to touch persistence-related code, and which test files are likely to be affected.

This gives the agent a concrete starting point instead of forcing it to guess from embeddings or repeatedly read files into context.

2.gograph review

After the agent makes an edit, it can run review. This acts as a structural sanity check over the affected area.

It can flag likely breakage in routing paths, changed dependencies, stale tests, and interface-related drift where those relationships are visible to static analysis. It is not a replacement for compilation or go test. It is an earlier feedback layer that helps agents catch structural mistakes before running the full verification loop.

3.gograph errorflow

When a test fails with an error like "invalid token signature", the agent should not have to guess where that message originated. It can pass the string to errorflow.

Gograph searches for where the error is created or wrapped, then follows the static return and call path as far as it can identify it. When the path is visible in the source graph, it can show how the error moves from the originating function toward higher-level handlers or tests.

This is useful in larger Go services where errors often pass through repository, service, middleware, and handler layers before reaching the test output or API response.

What It Looks Like in Practice

Let’s say you need an AI agent to add a TenantID field to a User struct in a shared package.

If the agent relies only on raw search, it may find the struct, add the field, update the local constructor, and stop. The build may still fail because a POST /api/v1/users handler in another package initializes the struct directly, or because repository code, SQL mapping, and integration tests also need updates.

If the agent uses Gograph first, it can query the User symbol and get a structured view of the surrounding code. That view can show that the symbol is connected to a specific POST route, appears in repository code, participates in SQL-related paths, and is referenced by specific test files.

The agent now has a better bounded scope for the change. Instead of editing one obvious file and discovering failures one by one, it can update the struct, handler, persistence path, and tests in a single coherent pass.

Hooking It Up via MCP

Gograph works as a standalone CLI, but it is also designed to be consumed by AI agents through the Model Context Protocol, or MCP.

MCP is an open protocol introduced by Anthropic for connecting AI systems to local tools and data sources. Gograph ships with a built-in MCP server that operates over standard I/O.

Instead of forcing the model to read and interpret unstructured terminal output, the MCP integration gives it structured, machine-readable JSON.

For an MCP-compatible client such as Cursor or Claude Desktop, the configuration looks like this:

{
  "mcpServers": {
    "gograph": {
      "command": "gograph",
      "args": ["mcp", "/path/to/your/repository"]
    }
  }
}

Once registered, the agent can query the repository graph before editing. It can inspect the structural impact of a proposed change, identify likely affected files, and build a more grounded execution plan before writing code.

Getting Started

If you’re building in Go and tired of cleaning up after your AI tools, you can install Gograph right now:

# macOS / Linux (via Homebrew)
brew install ozgurcd/tap/gograph
# Or using Go:
go install github.com/ozgurcd/gograph/cmd/gograph@latest

Final Thoughts

AI agents work better when they are given structured context instead of raw text alone. RAG is useful for semantic retrieval. Terminal commands are useful for exact inspection. But large Go codebases also need code-aware context: packages, symbols, call paths, routes, tests, persistence boundaries, and error flows.

That is the problem Gograph is trying to solve.

If you’re building in Go and tired of cleaning up after your AI tools, give Gograph a try.

Source Code and Documentation: https://github.com/ozgurcd/gograph

If you have ideas for other static analysis heuristics that would be useful for AI context, I'd love to hear your feedback! Feel free to open an issue or start a discussion on the GitHub repository.

Loom Engine & Mythcore: Omniveil

Wed, 13 May 2026 14:10:48 +0000

When I founded The World Table, the goal was clear: reimagining digital interaction. But to achieve the scale we envisioned for Mythcore: Omniveil, our upcoming MMORPG, the standard architectural patterns of the last decade simply weren't going to cut it.

We needed a foundation that could handle thousands of entities without the browser breaking a sweat. That foundation is the Loom Engine.

The Architecture of Loom: Precision Over Abstraction
Most TypeScript developers reach for Classes and Inheritance by default. In the early days of Loom, we realized that the "OOP Tax" - memory fragmentation and garbage collection pressure - was our biggest bottleneck.

To build a high-performance 2D engine, I made the executive decision to pivot Loom toward Data-Oriented Design (DOD).

Why the shift?
Contiguous Memory: By using TypedArrays and a Struct-of-Arrays (SoA) approach, we keep our data tightly packed.

Bypassing the GC: Loom minimizes object instantiation in the main simulation loop. No new objects means no Garbage Collector spikes during critical gameplay.

Near-Native Throughput: We are seeing performance metrics that challenge the "TypeScript is slow" stigma, pushing the V8 engine to its absolute limits.

Mythcore: Omniveil - The Manifestation
Loom isn't just a library; it’s the heartbeat of Mythcore: Omniveil. Currently in pre-alpha, Mythcore is the proof of concept for everything we’re building at The World Table.

In our latest prototypes, we’ve successfully managed complex batch rendering and zero-allocation physics solvers. We’re proving that you can have the developer velocity of TypeScript with the raw power usually reserved for low-level languages.

The "Sadhaka" Mindset
Building an engine from scratch is a sadhana - a disciplined practice. It’s about stripping away the "easy" abstractions to find the performant truth underneath.

I’m excited to join the CoderLegion community to share more deep dives into the Loom Engine’s architecture, our work on authoritative networking, and the journey of bringing Mythcore to life.

If you’re interested in high-frequency systems, WebGL/WebGPU optimization, or the future of browser-based gaming, let’s talk.

TypeScript #GameDev #WebGPU #DataOrientedDesign #LoomEngine #PerformanceEngineering #MMORPG #Anthropic #ClaudeCode #SoloDev

If you are using Claude Code in production, the agent is not the problem

Fri, 08 May 2026 21:44:38 +0000

The agent is not the problem. The substrate around the agent is. Here is the four-file shape that made my Convex production-database write boring on 2026-05-06, plus a stdlib Python script the Claude Code agent calls but did not generate.

Before the question lands: the bridge is not an agent improvising near prod. It is a deterministic Python script the agent calls. It writes to a bounded Convex HTTP endpoint. Prod writes need an env flag and a 401-preflight to fire. The cache dedups on a composite idempotency key. The logger strips anything that smells like a secret before it hits disk. The agent did not invent any of that.

In late April, a viral Reddit thread about an agent deleting a production database was making the rounds (recap). The fear was real. My bridge is still running because the agent did not have the room to improvise. Below is what made that true. Every claim has a file path you can grep for in your own setup.

What context engineering actually means in Claude Code

Vendors are calling context engineering the skill that separates serious solo operators from people who dabble. The trend is real. NxCode says over 60,000 public GitHub repos now include some form of agent instruction file. What it means in Claude Code is concrete: a CLAUDE.md at every project root, a global one at ~/.claude/CLAUDE.md, an auto-memory layer at ~/.claude/projects/, plus the skills directory, plus the templates directory, plus the hooks. Each one is a slot where context lives across sessions instead of being retyped into the chat.

Context engineering is not prompt engineering 2.0. Prompt engineering happens in the user message. Context engineering happens in the files Claude Code reads before the user message. Identity. Business state. Registries. Decisions. Voice. Scripts. Memory.

The common framing is one big system prompt and hope for the best. That breaks the moment your work spans more than one task surface. The layered framing replaces it. Folders, files, hooks, memory, vault. Each layer answers a question Claude would otherwise have to guess at.

There is a name for the pattern people are converging on: the control stack. Project rules plus reusable skills plus bounded sub-agents plus deterministic tools. The label is just the label, but the substance is what matters. Project rules go in CLAUDE.md. Reusable skills go in ~/.claude/skills/. Bounded sub-agents are described per-task in their own SKILL or template files. Deterministic tools are scripts the agent calls (not generates) when the task needs a specific outcome.

A vibe-coded one-shot script and a rail with all of this behind it can both run on a Tuesday. The difference is what is around the script. Tests, logs, idempotency cache, config gates, audit trail.

Both ship. Only one survives Wednesday.

Only one helps when you come back six weeks later and need to remember why a flag is set the way it is. The vibe-coded one is forgotten code. The control-stack one composes.

Concretely, here is what feeds my Claude Code session every conversation, before I type anything:

~/projects/agent-os/CLAUDE.md is the load-bearing identity file. Who I am, what I sell, who I sell to, the 90-day priorities. The agent does not ask. It reads.
~/.claude/projects/-home-jon/memory/MEMORY.md is the auto-memory index. User profile, feedback rules, project state, references that survive across sessions. The agent does not relearn me every conversation.
references/framework.md is the operator playbook. How decisions get made, what to optimize for, and what holds the rest together when the work scales.
decisions/log.md is the append-only why-log. Not just what changed. Why.

Those four files are part of the substrate. The identity and memory layers are loaded by default. The others are where the agent goes when the task calls for them.

The layers, one folder at a time

The Agent OS lives in three roots. ~/projects/agent-os/ for the project layer. ~/.claude/ for the global layer. ~/vault/ for the second-brain layer. Each layer has one job, and Claude Code reads them in a known order.

connections.md is the registry of every external system Jon-OS can reach. Gmail wired via the gws CLI. Drive the same way. GitHub via gh. Gumroad via PAT. NotebookLM via the notebooklm CLI. Status and last-touched date on each. When I started the Skool bridge, the agent did not have to guess whether Convex was reachable. The registry said yes, here is the deployment slug, here is the auth model. One row per system. The bridge never blocked on "is X wired."

decisions/log.md is the append-only record of every non-trivial decision and why. Reversible decisions get a one-line entry. Load-bearing ones get the full receipts. The decision to gate prod writes on SKOOL_ALLOW_PROD_WRITES=1 plus a 401-preflight against an allowlisted Convex deployment lives there. So does the decision to keep member content deny-by-default in logs. Future me reads it. Future agent reads it. When a teammate asks "why is this flag here," the answer is already written.

references/ holds voice samples, API guides, framework writeups. references/skool-api.md had the Skool Sheets endpoint shape, the field names, and the failure modes spelled out before any code got written. The composite idempotency key was specified there as {tab_slug}:{normalized_transaction_id}, before any handler. The bridge inherits the discipline of the spec. The spec inherits the discipline of the research that produced it.

scripts/ holds gumroad_api.py, skool_sheets_to_convex.py, and a handful of others. Stdlib-only Python. Deterministic tools the agent calls, not generated on demand. The Skool bridge is skool_sheets_to_convex.py. The redacting logger is one function in that script that strips email-shaped substrings and known secret prefixes before any line lands in the journal. The agent did not write that on a hunch. It came from the spec.

~/.claude/skills/ and ~/projects/agent-os/.claude/templates/ hold reusable skills and prompt templates. The Bike Method (training wheels first, then take them off) is encoded here. Prompt template first, then SKILL.md, then orchestrator. New capability gets the lowest-autonomy version that works. It only graduates when I make an explicit edit. The content pipeline I am running this post through started life as a prompt template. The next phase turns it into a skill. Slow on purpose.

~/.claude/projects/-home-jon/memory/ is Claude Code's auto-memory layer. It survives across conversations. The workflow rule that produced the Skool bridge lives here as a feedback memory. Research, then planning, then spec, then implementation, with Codex adversarial review at each phase. The agent does not relearn that every session. It just does it.

~/vault/ is the Obsidian second-brain. PARA-routed. Sessions, drafts, insights, workflows, references. The session note for the Skool bridge ship day lives at sessions/2026-05-06-skool-rail-live-content-pipeline-aegis-staged.md. Markdown plus frontmatter plus wikilinks. Plain text, plain folders, no platform lock-in.

Each layer has one job. Adding a new system means adding one row to connections.md and maybe one script to scripts/. The layers stay stable, so the work compounds. That is the boring promise of the control stack.

A worked example: the Skool transactional rail

The Skool transactional rail is a Python bridge. It polls two Google Sheet tabs that Skool-driven Zaps populate. New paid-member rows POST to a Convex HTTP endpoint that owns my YCAH member table. The other tab parses through without posting. The bridge runs on a systemd user timer:

OnCalendar=*:0/10

Every 10 minutes on the boundary. It has been live in prod since 2026-05-06.

Here is how it got safe.

The spec lived in references/skool-api.md before the code existed. Endpoint shape, field names, normalization rules, failure modes, idempotency strategy. Researched first, written second. The composite idempotency key was decided there:

{tab_slug}:{normalized_transaction_id}

Before any handler.

The spec went through Codex twice for adversarial review. The first pass killed a cookie-auth approach that would have violated Skool's ToS. The second pass drove composite idempotency keys and the prod-write guard. Both passes still missed an inferred field assumption. I had assumed Skool's "Answered Membership Questions" trigger exposed the member's email. The dry-run caught that the field was not there. Not Codex. Not me re-reading my own spec. The dry-run, against real data. The honest version: review found a lot, but the empirical step still earned its keep.

The pivot was clean because the spec was a document, not a vibe. I rewrote the affected section to "parse the QA tab, but do not POST member rows from it (the email-bearing trigger is the New Paid Member event on the Paid Members tab)," shipped Option A, kept moving. If the spec had only lived in my head, I would have been mid-implementation when reality disagreed. Instead, I edited a markdown file.

The cache had a quieter bug. The initial _read_json swallowed JSONDecodeError and returned a default empty dict. Under the corruption test in the verification checklist (step 0e: deliberately corrupt the cache file, run the bridge, check what happens), it would have silently rebuilt the processed-events cache and double-POSTed every prod row that had already been posted. Caught and fixed before the canary ran. To be precise: the test caught it. Not the spec, not the agent, not me eyeballing the diff. The verification checklist did its job.

The other guardrails earned their keep too:

Prod-write guard: SKOOL_ALLOW_PROD_WRITES=1 plus a 401-preflight against the allowlisted Convex deployment slug means a misconfigured run cannot touch prod. Fails closed at startup, before the first row is read.
Redacting logger: strips email-shaped substrings and known secret prefixes from every line before it hits the journal. Member content is deny-by-default. The bridge never logs row contents, only IDs and outcomes.
Canary verified: jgerton+*Emails are not allowed* landed clean in prod Convex. The idempotent re-run produced 0 new POSTs, 1 skipped, 0 errored.

None of those guardrails came from the agent improvising. They came from the spec. The spec came from the research phase. The research phase came from the workflow rule in memory. The substrate persists the rules. Discipline runs them. The dry-run and the corruption test catch what reviews miss. The agent itself wrote unsafe cache behavior on the first pass. The checklist caught it.

Sidebar: my Claude Code workflow rule

The discipline above is anchored in one feedback memory at ~/.claude/projects/-home-jon/memory/feedback_workflow_research_to_implementation.md:

Research, then planning, then spec, then implementation, with Codex adversarial review at each phase.

Codex (the OpenAI Codex CLI) is the adversarial reviewer that runs alongside Claude Code in my setup. It runs against the spec, then again against the implementation, before anything ships. The reviews catch the things I am too close to see. The dry-run catches the things Codex assumes. The verification checklist catches the things the dry-run does not exercise. The agent itself catches almost nothing past the first draft, and that is fine, because the agent is not the safety net. The workflow rule is. The rule lives in Claude Code's memory layer because the rule is the part that has to survive across every session. The agent does not relearn it. It just does it.

What compounds

The audit score ticking from 77 to 85 is not the point. What got cheaper is. The /audit pass surfaced a missing freshness column in connections.md, an old voice sample I had outgrown, and a reference doc whose code paths had moved. Each fix made the next session faster. The agent stopped re-explaining state I had already encoded.

Bigger payoff: the Aegis migration. I spent a day bulk-staging 75 skills, 66 commands, 5 agents, and 8 hooks from my desktop to the always-on minipc that runs Jon-OS 24 hours a day. None of those got built. They got recon'd, staged, and gated behind a settings diff, then activated. The hard work is path rewrites and activation order, not authoring.

The one I lit up first: the notebooklm skill. NotebookLM is now reachable as a CLI on this minipc, with ~/vault/CLAUDE.md mapping each domain to its dedicated notebook. I wrote a thin wrapper at ~/.claude/workflows/nlm-queue.py so the session-extract skill can auto-source captured insights to the right notebook (queues on auth failure, drains after re-auth). That makes NotebookLM scriptable from inside the content pipeline. The post you are reading now leaned on manual research. The next version of this pipeline can lean on a NotebookLM query inside the prompt template. Same discipline, less typing. Every shipped rail makes the next one cheaper.

The slower payoff is discovery. Three new YCAH members joined from three distinct platforms in the last month. Dev.to, Reddit /r/ClaudeAI, and TikTok. Three different surfaces, reached without me hand-writing each variant. Pipeline output, then discovery, then membership. The compounding works on the audience side too.

What this is not

This is not vibe coding. I do not trust one-shot scripts near prod. Not because someone on Twitter said so. Because I have been the person who shipped a one-shot, watched it work, and then watched it quietly stop working two weeks later for reasons I had no audit trail to understand. Front-loading the work is what makes the guardrails routine instead of heroic.

It is also not stacking Notion plus Claude plus ChatGPT plus Cursor and calling it a system. Those are fine tools. The mental model treats each one as an island. The control stack treats them as one composable system with a known read order. The intended read path is identity, state, registries, decisions, voice, scripts, memory, then the conversation. The point is not magic order. The point is that the context lives in stable files. Add a tool, you add a row in connections.md and maybe a wrapper in scripts/. You do not add a context-switch tax for yourself or the agent.

It is not theory. Every implementation claim above has a file path on my machine. Set up the same shape and you can grep your own.

What to copy first

If you are going to copy one piece, copy connections.md. Knowing what your Agent OS can reach is the cheapest unlock. You will build everything else against it.

Second: a decisions/log.md you actually keep. Append-only. One entry per non-trivial decision. The audit trail compounds faster than you think. By month two, you stop relitigating choices you already made and forgot you had made.

Third: seed Claude Code's auto-memory layer with your voice, your workflow, and your role. Once it is there, every conversation gets cheaper. You stop reintroducing yourself. The agent stops asking you the same orientation questions every Tuesday.

That is the order. Connections first, decisions second, memory third. Three files, in three days, before any new tool gets wired up. The bridge that runs my member sync was not built because I had a clever agent. It was built because the substrate was already there, and I used it. The discipline is mine. The files just stayed where the next session could find them. Boring on purpose.

Open one of those three files in your editor tomorrow morning. Write the first row. The compounding starts there.

Inside YCAH, I am doing this same work in public. The 4-file substrate, the workflow rule, the spec-first discipline, applied weekly to whatever members are shipping. Practitioner depth, not vending-machine demos.

I Spent a Week Installing WSL2. The Fix Was Two Lines.

Wed, 06 May 2026 15:49:50 +0000

"WSL2? Five minutes, tops." — Me, seven days ago.

TL;DR

On Windows 11 25H2 (build 26200), enabling VirtualMachinePlatform hangs at 37.8%. Forever. The servicing stack is stuck on 24H2 (build 26100) while the OS moved to 25H2 (build 26200). Windows literally cannot service itself.

Add-WindowsCapability -Online -Name "Microsoft.Windows.HyperV.VirtualMachinePlatform~~~~0.0.1.0"
dism /online /enable-feature /featurename:VirtualMachinePlatform /all /LimitAccess

If you just want the fix, there it is. If you want to know how it took a week and 10 failed attempts to arrive at two lines of PowerShell, keep reading.

Day 1: Innocence

Simple plan. Install WSL2. Set up Ubuntu 24.04. Do actual work.

wsl --install -d Ubuntu-24.04

37.8%.

I made coffee. Came back. 37.8%.

I had lunch. Came back. 37.8%.

37.8 is now my least favorite number.

The Crime Scene


OS	Windows 11 Pro 25H2 (Build 26200.8037)
CPU	Intel Core Ultra 9 275HX
DISM version	10.0.26100.5074
Servicing stack	10.0.26100.8035

See it? OS is build 26200. Servicing stack is build 26100. The mechanic has last year's manual for this year's car. If you spotted this, you already know the ending. I did not spot this on Day 1.

Days 2-6: The Parade of Failures

GUI — Stuck. Cancel also stuck.

"Turn Windows features on/off." Checked the box. Progress bar froze.

Clicked Cancel. Cancel froze.

A cancel button that cannot be cancelled. This is the operating system from the world's most valuable company.

Task Manager. End Process. Moving on.

DISM — 37.8%

dism /online /enable-feature /featurename:VirtualMachinePlatform /all /norestart

37.8%. We meet again.

PowerShell — Same wall, different paint

Enable-WindowsOptionalFeature -Online -FeatureName VirtualMachinePlatform -All -NoRestart

Calls DISM internally. Same result. Changing the wrapper doesn't change the candy.

Uninstalled BlueStacks — Wrong suspect

Found forum posts: "Android emulators conflict with Hyper-V." I had BlueStacks 10 installed. Uninstalled it completely. Registry cleanup. Folder purge. The works.

Result: 37.8%.

BlueStacks was innocent. And now I have to reinstall it later.

Offline install from 24H2 ISO — Version mismatch

"If the download is the problem, go offline."

dism /online /enable-feature /featurename:VirtualMachinePlatform /all /LimitAccess /Source:D:\Sources\Install.wim

0x800f0912. The ISO is 24H2 (26100), the OS is 25H2 (26200). Windows refuses the source files because they're from "the wrong version." Self-compatibility is apparently optional.

Windows Update cache reset — No effect

net stop wuauserv
net stop bits
Remove-Item C:\Windows\SoftwareDistribution\Download\* -Recurse -Force
net start bits
net start wuauserv

Clean cache. Same 37.8%. Cleaning the house doesn't fix the plumbing.

Pending operations cleanup — Partial

dism /online /cleanup-image /revertpendingactions

Cleared the backlog. Feature still won't activate. Finishing your homework doesn't mean you'll pass the exam.

In-place repair install — Didn't downgrade

The nuclear option. Ran 24H2 ISO's setup.exe with "Keep personal files and apps."

40 minutes. Three reboots.

Result: OS stayed on 25H2 (26200). In-place install doesn't downgrade. But it did clean up the component store. This becomes a crucial plot point later.

Day 7: Reading the Logs (Finally Using My Brain)

A week of "try something else until it works." At this point, the question isn't what doesn't work — it's why.

Select-String -Path C:\Windows\Logs\CBS\CBS.log `
  -Pattern "Error|Failed|0x800f" -Context 2 | Select-Object -Last 20

The smoking gun:

Failed to get uup features from WU, sessionData: {
  "ModuleID":"FOD",
  "Features":[{
    "name":"Windows.HyperV.OptionalFeature.VirtualMachinePlatform.Client.Disabled~"
  }]
} [HRESULT = 0x800f0820 - CBS_E_CANCEL]

download source: 8, download time (secs): 1256, 
download status: 0x800f0820 (CBS_E_CANCEL)

1,256 seconds. Twenty-one minutes waiting for Windows Update to deliver a package it will never find.

From the DISM log, the confession:

Dism.exe version: 10.0.26100.5074
Target image: OS Version=10.0.26200.8037

The servicing stack (26100) is trying to service a newer OS (26200). It goes to Windows Update looking for FOD packages matching this combination. Those packages don't exist in the UUP catalog. So it waits. And waits. And times out at 37.8%.

A car mechanic with a 2023 catalog trying to order parts for a 2024 model. "This part number doesn't exist in our system, sir."

This is the servicing architecture of the world's largest software company.

The Fix: Use the Back Door

DISM can't download the FOD through its usual channel (UUP). But Add-WindowsCapability uses a different channel.

Same building. Front door is under construction. Back door is open. The sign only mentions the front door. Classic Windows UX.

# Step 1: Back door — install payload via alternative channel
Add-WindowsCapability -Online -Name "Microsoft.Windows.HyperV.VirtualMachinePlatform~~~~0.0.1.0"

# Step 2: Now activate using only local files (no internet needed)
dism /online /enable-feature /featurename:VirtualMachinePlatform /all /LimitAccess

100%.

One hundred percent.

First three-digit number I've seen all week.

Why This Works

[Front door — BLOCKED]
DISM enable-feature
  → Needs FOD payload
  → Windows Update UUP channel
  → Servicing stack (26100) ≠ OS (26200)
  → "Part not found in catalog"
  → 21 min timeout → CBS_E_CANCEL

[Back door — OPEN]
Add-WindowsCapability  
  → Different download channel (bypasses UUP)
  → Payload installed locally ✓

DISM + /LimitAccess
  → "Internet? Don't need it."
  → Local files only
  → Success ✓

Both commands use the same Windows servicing system. But they fetch FOD packages through different channels. DISM goes through UUP, where the version mismatch kills it. Add-WindowsCapability takes a different route. The official docs don't mention this distinction. You're welcome.

If You Found This Article

You've probably already tried and failed multiple times. That means pending operations are likely piled up. Clean house first:

# Light cleanup
dism /online /cleanup-image /revertpendingactions
# → Reboot → Run the two-line fix

# If that's not enough (in-place repair)
# 24H2 ISO → setup.exe → "Keep personal files and apps"
# → Reboot → Run the two-line fix

Complete Flow (For Fresh Starts)

1. Enable virtualization in BIOS
   HP laptops: F10 → Security or Configuration → Enable VT-x
        ↓
2. Enable Hyper-V + WSL (these work fine, ironically)
   dism /online /enable-feature /featurename:Microsoft-Hyper-V-All /all /norestart
        ↓
3. Clean pending operations (if you've been trying things)
   dism /online /cleanup-image /revertpendingactions → reboot
        ↓
4. The actual fix
   Add-WindowsCapability -Online -Name "Microsoft.Windows.HyperV.VirtualMachinePlatform~~~~0.0.1.0"
   dism /online /enable-feature /featurename:VirtualMachinePlatform /all /LimitAccess
        ↓
5. Reboot → Install WSL2
   wsl --install -d Ubuntu-24.04

Is This Your Problem?

# Check version mismatch in DISM log
Get-Content C:\Windows\Logs\DISM\dism.log -Tail 100
# "version:" ≠ "image version:" → yes, this is your problem

# Check CBS log for the specific failure
Select-String -Path C:\Windows\Logs\CBS\CBS.log `
  -Pattern "Error|Failed|0x800f" -Context 2 | Select-Object -Last 20
# "CBS_E_CANCEL" → yes, this is your problem

# Verify CPU virtualization (prerequisite)
Get-CimInstance -ClassName Win32_Processor | 
  Select-Object VirtualizationFirmwareEnabled, VMMonitorModeExtensions

Summary


Symptom	VirtualMachinePlatform stuck at 37.8%
Root cause	25H2 OS (26200) + 24H2 servicing stack (26100) = FOD download mismatch
Fix	`Add-WindowsCapability` to bypass → `dism /LimitAccess` to activate
Prerequisite	Clear pending operations
Cost	One week of evenings. One wrongly accused BlueStacks. A lasting distrust of progress bars.

Lessons

Read the logs first. "Try random things until something works" is the scenic route to nowhere.
Windows Insider means signing up for this. 25H2 is a preview build. The servicing stack hasn't caught up. Now you know.
Same building, multiple doors. When DISM fails, Add-WindowsCapability exists. The docs won't tell you.
Feed your logs to AI. Nobody should read 160,000 lines of CBS log with their own eyes.

This troubleshooting session was done with Claude Code. It pulled the critical 6 lines from a 160,000-line CBS log and helped identify the Add-WindowsCapability back door. Without it, this would have ended with a format and reinstall.

Claude Code Deep Dive Part 2: The 1,421-Line While Loop That Runs Everything

Tue, 05 May 2026 19:10:54 +0000

This is Part 2 of our Claude Code Architecture Deep Dive series. Part 1: 5 Hidden Features covered the surface-level discoveries. Now we go deeper.

The Heart of Claude Code

Every AI coding agent — Claude Code, Cursor, Copilot — runs some version of the same loop: send context to an LLM, get back text and tool calls, execute tools, feed results back, repeat. We called this LLM talks, program walks.

But Claude Code's implementation of this loop is anything but simple. It lives in query.ts, a 1,729-line async generator. The while(true) starts at line 307 and ends at line 1728 — a single loop body spanning 1,421 lines of production code.

This is not a toy. This is the engine that processes every keystroke, every tool call, every error recovery, every context compression decision for millions of users.

// query.ts — line 307
// eslint-disable-next-line no-constant-condition
while (true) {
    let { toolUseContext } = state
    const { ... } = state
    // ... 1,421 lines of state machine logic ...
    state = next
} // while (true)  — line 1728

Why a State Machine, Not Recursion

Early versions of Claude Code used recursion — the query function called itself. But recursion has a fatal flaw: in long conversations with hundreds of tool calls, the call stack grows until it explodes.

The current design uses while(true) with a state object that carries context between iterations:

// query.ts — lines 207-215 (State type, partial)
autoCompactTracking: AutoCompactTrackingState | undefined
maxOutputTokensRecoveryCount: number
hasAttemptedReactiveCompact: boolean       // circuit breaker for 413 recovery
stopHookActive: boolean | undefined
turnCount: number
transition: { reason: string } | undefined // why we continued

Each continue statement is a state transition. There are 9 distinct continue points in the code (lines 950, 1115, 1165, 1220, 1251, 1305, 1316, 1340), each representing a different reason to run another turn:

Next tool call needed
Reactive compact triggered after 413
Max output tokens recovery
Stop hook interrupted
Token budget continuation
And more

The Loop at a Glance

10 Steps Per Iteration

Each time the loop runs, it does these 10 things in order. Every step has real source code behind it.

Step 1: Context Compression (4 stages)

Before calling the API, the system tries to fit everything into the context window. Four compression mechanisms fire in priority order (imports at lines 12-16, 115-116):

Snip Compact — trims overly long individual messages in history
Micro Compact — finer-grained editing based on tool_use_id, cache-friendly (line 370: "microcompact operates purely by tool_use_id")
Context Collapse — folds inactive context regions into summaries
Auto Compact — when total tokens approach the threshold, triggers full compression

These are not mutually exclusive — they run in priority order:

The system tries lightweight options first. If snip + micro bring tokens under the limit, the heavy compressors never run.

Step 2: Token Budget Check

If a token budget is active (feature('TOKEN_BUDGET'), line 280), the system checks whether to continue. Users can specify targets like "+500k", and the system tracks cumulative output tokens per turn, injecting nudge messages near the goal to keep the model working.

Step 3: Call Model API

Line 659 — the actual API call:

for await (const message of deps.callModel({

This is a streaming call. The response arrives token by token, and the system processes it incrementally.

Step 4: Streaming Tool Execution

This is a critical optimization. Traditional agents wait for the model to finish generating all output, then execute tools. Claude Code uses StreamingToolExecutor (imported at line 96):

When the model is still generating its second tool call, the first one is already running:

Traditional Agent (sequential):
┌─────────────────────────┐┌───┐┌───┐┌───┐┌───┐┌───┐
│  LLM generates 5 calls  ││ T1││ T2││ T3││ T4││ T5│  ← 30s total
└─────────────────────────┘└───┘└───┘└───┘└───┘└───┘

Claude Code (streaming):
┌─────────────────────────┐
│  LLM generates 5 calls  │
├──┬──┬──┬──┬─────────────┘
│T1│T2│T3│T4│T5│                                       ← 18s total
└──┴──┴──┴──┴──┘
↑ tools start while LLM is still generating

In a turn with 5 tool calls, traditional waits 30 seconds. Streaming finishes in 18 — a 40% speedup from architecture alone, not model improvements.

Line 554-555 reveals an interesting detail: stop_reason === 'tool_use' is unreliable — "it's not always set correctly." The system detects tool calls by watching for tool_use blocks during streaming instead.

Step 5: Error Recovery

If the prompt is too long? Try context collapse drain. If that fails, try reactive compact (line 15-16). If the API returns 413 (prompt too long), trigger emergency compression and retry.

But there's a circuit breaker: hasAttemptedReactiveCompact (line 209, initialized false at line 275) ensures each turn only attempts reactive compact once. Without this, a genuinely oversized conversation would loop forever.

The system also handles model degradation — if the primary model fails, it can fall back to a different model.

Step 6: Stop Hooks

After the model stops outputting, the system runs registered stop hooks. These can inspect the output and decide whether to let the model continue. This is where external governance plugs in.

Step 7: Token Budget Check (Again)

Yes, checked twice — once before calling the model (should we even start?) and once after (did we exceed the budget?). The second check decides whether to inject a "keep going" nudge or stop.

Step 8: Tool Execution

If the response contains tool_use blocks, execute them. Two paths:

runTools() (from toolOrchestration.ts, line 98) — batch execution
StreamingToolExecutor (line 96) — streaming execution, gated by config.gates.streamingToolExecution (line 561)

Each tool call goes through the 14-step execution pipeline in toolExecution.ts (1,745 lines) — validation, permission checks, hooks, actual execution, analytics. That's a story for Part 3.

Step 9: Attachment Injection

After tools finish, the system injects additional context before the next turn:

Memory attachments — relevant memories from the memdir/ system
Skill discovery — matching skills based on the current task
Queued commands — any commands that were waiting

This happens after tool execution but before the next API call, ensuring the model has fresh context.

Step 10: Assemble and Loop

Build the new message list from all the pieces — original conversation, tool results, attachments, system reminders — and go back to step 1.

Why This Architecture Matters

Most open-source AI agents implement the loop as 50 lines of pseudocode: call model, parse tool calls, execute, repeat. Claude Code's 1,421-line version exists because production reality is messy:

Context doesn't fit. A real coding session easily hits 200K tokens. Without the 4-stage compression pipeline, the agent dies on every long conversation. Most agents just truncate and lose context. Claude Code compresses intelligently — lightweight first, heavy only when needed.

Models fail. APIs return 413, connections drop, rate limits hit. The 9 continue points aren't over-engineering — they're the minimum number of recovery paths needed for reliable operation. The hasAttemptedReactiveCompact circuit breaker is the kind of detail that separates a demo from a product.

Speed matters more than correctness of execution order. Streaming tool execution — starting the first tool while the model is still generating the third — is a user experience decision backed by architecture. Traditional agents feel slow because they are: they serialize everything. Claude Code parallelizes at the loop level.

Tokens cost money. The SYSTEM_PROMPT_DYNAMIC_BOUNDARY marker in prompts.ts (914 lines) splits the system prompt into static (cacheable) and dynamic sections. If two requests share the same static prefix byte-for-byte, the API caches it. Source comment: "don't modify content before the boundary, or you'll destroy the cache." This is prompt cache economics — saving Anthropic real compute costs at scale.

The Behavioral Constitution

Buried inside the prompt assembly, getSimpleDoingTasksSection() may be the most valuable function in the entire codebase. It encodes hard-won rules about what the model should NOT do:

Don't add features the user didn't ask for
Don't over-abstract — three duplicate lines beat a premature abstraction
Don't add comments to code you didn't change
Don't add unnecessary error handling
Read code before modifying it
If a method fails, diagnose before retrying
Report honestly — don't say you ran something you didn't

Anyone who has used Claude Code recognizes these rules. I've personally watched the system refuse to add "helpful" abstractions and stick to minimal changes. That's not the model being disciplined — it's the prompt constraining the model. The takeaway: don't trust model self-discipline. Codify the behavior.

How Other Agents Compare

Aspect	Claude Code	Cursor	Typical OSS Agent
Loop complexity	1,421 lines, 9 continue points	Unknown (closed source)	~50-200 lines
Compression	4-stage pipeline + reactive 413 recovery	Tab-level context pruning	Truncate or fail
Tool execution	Streaming (parallel with generation)	Sequential	Sequential
Error recovery	Circuit breakers, model fallback, emergency compact	Basic retry	Crash
Prompt caching	Static/dynamic boundary, section registry	Unknown	None

The gap between Claude Code and most open-source agents is not model quality — it's the program layer. The model is the same Opus or Sonnet for everyone. What makes Claude Code feel different is 1,421 lines of careful engineering around it.

The Bottom Line

The query loop is where "LLM talks, program walks" becomes concrete:

The LLM outputs text and tool call JSON. That's it.
The program handles compression, budget tracking, error recovery, streaming, permissions, memory injection, and 14-step tool validation.
The 1,421 lines are not the model being smart. They're the program being careful.

If you're building an AI agent and your main loop is under 100 lines, you're not handling the cases that matter. Production is not about the happy path. It's about what happens when context overflows, the API returns 413, the user's conversation hits 500 turns, and three tools need to run while the model is still thinking.

Next: Part 3 — The 14-Step Tool Execution Pipeline (coming soon) — what happens between "model says call this tool" and the tool actually running.

Previous: Part 1 — 5 Hidden Features Found in 510K Lines

Video: The AI Stack Explained — LLM Talks, Program Walks

I built a Claude Code plugin for brand building in a weekend. Here's what I shipped and what I learned.

Tue, 28 Apr 2026 23:56:38 +0000

I've been writing code for 27 years. I picked up Claude Code the day it launched and haven't looked back. Last weekend I built a plugin that does something I've wanted for a while: brand positioning, messaging, voice, and visual identity using real expert frameworks, not "generate a brand strategy" vibes.

Here's what I shipped and what surprised me along the way.

The problem

Every time I've used AI for branding work, the output is the same. "Innovative solutions that empower teams." Stuff that could belong to literally any company on earth. The issue isn't that AI is bad at branding. It's that nobody tells it what good branding actually looks like.

So I packaged the actual methodologies into Claude Code skills:

Positioning: April Dunford's 5-component framework from Obviously Awesome
Messaging: Donald Miller's StoryBrand BrandScript
Voice: NN/g's brand voice dimensions + Aaker personality model
Visual identity: Chris Do's stylescape method

Each skill follows the real framework. The positioning skill works through Dunford's five components in order because the order matters. It's not "AI interprets the concept of positioning." It's "AI follows a specific methodology and checks its own output."

The anti-slop system

This is the part I'm most proud of. Every skill runs its output through quality checks before showing it to you:

Swap test: Could a competitor claim this? If your value proposition is "we provide innovative solutions that empower teams," that fails. Every software company on earth could say that. The skill flags it and helps you find what's actually specific to you.

Specificity test: Catches banned generic words (innovative, cutting-edge, leverage, empower, seamless, revolutionary, synergy) and replaces them with the concrete thing they were hiding.

Business-type test: Would this positioning work for both a lawn care company and a SaaS? If yes, it's too generic.

How the pieces connect

All 10 skills share state through a single brand-brief.md file with YAML frontmatter. Positioning fills in fields. Messaging reads those fields and fills in more. Voice reads messaging. Visual identity reads all of it.

Each component gets a confidence score: validated (backed by real customer data), researched (desk research), or assumed (educated guess). Downstream skills flag when they're building on assumptions. They don't stop you, they just make sure you know what's solid and what's still a guess.

What surprised me

The plugin system is more powerful than I expected. Claude Code plugins are just directories with structured markdown. No compiled code, no API calls, no build step. A skill is a markdown file with instructions that Claude follows. You can package entire methodologies into installable tools that anyone can clone and use.

Anti-slop checks actually work. I ran the toolkit on my own brand and it caught two of four tagline candidates as too generic. The discipline of checking your own output against real criteria matters more than I thought.

Adaptive interactivity solves the "blank page" problem. The positioning skill detects how much you know and picks one of three modes: research-assisted (you know nothing), guided (you know some things), or fast validation (you know your market). People at different stages get different experiences from the same tool.

Try it

git clone https://github.com/jgerton/brand-toolkit.git
claude --plugin-dir ./brand-toolkit

Run /brand-toolkit:start and it figures out where you are.

MIT licensed. Full getting started guide here.

I'm building more tools like this and sharing everything in my community. If you're into Claude Code beyond the basics, or you want to build your own plugins, come hang out.

How I got my AI agents to communicate across repos — and shipped SAMP doing it

Tue, 28 Apr 2026 05:29:41 +0000

Situation. I was working on lumen-argus, a project that runs across three Claude Code sessions in three different repos. They needed to share context — "I just refactored the auth module," "the schema migration landed, pull main." For weeks I was copy-pasting between terminal windows like a caveman.

Task. I wanted cross-session, cross-repo messaging for AI agents. Cheap. Fast. Local. Ideally something I could read with cat if anything went wrong.

Three constraints:

Token cost per message had to be near zero.
No new servers, no daemons, no MCP handshake.
It had to work for any agent — Claude Code today, Cursor or my next project tomorrow.

Action. I surveyed the existing options. mcp_agent_mail, Agent Teams, broker daemons — all of them spin up an HTTP server, register identities, run a SQLite store, and burn tokens on polling hooks. Overkill for three agents swapping a dozen messages a day.

So I borrowed Linus Torvalds' playbook from git:

Per-writer append-only logs. One file per agent: log-<alias>.jsonl. No file ever has two writers, so there's no locking, no interleave, and Syncthing / Dropbox / iCloud can't cause merge conflicts.
Content-addressed IDs. id = sha256({ts, from, to, thread, body})[:16]. Same content → same id, so dedup after sync is automatic.
mtime short-circuit. Before parsing anything, stat the log files; if nothing changed, exit immediately.

I packaged it as SAMP (Simple Agent Message Protocol) — a vendor-neutral spec — and shipped a reference implementation, agent-message: three Claude Code slash commands (/message-send, /message-inbox, /message-reply), a msg shell helper for humans, and a tiny Python wrapper any other agent CLI can spawn.

Result.

1 Bash tool call per send/receive from Claude Code. No MCP init, no ack roundtrip.
0 LLM tokens when humans (or cron, or scripts) read/send via the shell helper. The model is never in the loop.
~30 ms latency — that's python3 startup. Everything else is a file append.
Works offline. Syncs across machines via Syncthing / Dropbox / iCloud with zero conflicts by construction.
One install script. No pip, no npm, no Docker.

Docs: https://slima4.github.io/agent-message/
Repo: https://github.com/slima4/agent-message
Spec: https://github.com/slima4/agent-message/blob/main/SPEC.md

If you're juggling multiple agent sessions and copy-pasting between them, give it a try. PRs and issues welcome.

kasetto - declarative AI agent environment manager, written in Rust

Mon, 20 Apr 2026 21:09:16 +0000

Hey community!

I want to share an open-source tool I built for myself, and that I hope will be useful to other developers working with AI agents.

The Problem

The more AI coding tools we adopted, the messier our setup got. Skills and MCP servers installed manually, via individual commands, or copy-pasted from docs. Scattered across Claude Code, Cursor, Codex, Windsurf - with no way to version any of it, no way to share it with teammates, no way to reproduce it on a new machine or project.

Every new team member meant walking them through the same manual steps. Every new machine meant doing it all over again. And if someone changed a skill or added an MCP server, there was no way to propagate that to the rest of the team.

Sound familiar?

The Idea

I built kasetto to fix that. The idea is borrowed from things I already loved - the declarative reproducibility of dotfiles, the simplicity of uv for Python packages. What uv did for Python, kasetto aims to do for AI agent skills.

One YAML config describes your entire setup: skills, MCP servers, target agents. Commit it, share it, and everyone on the team gets the exact same environment. No manual editing, no drift between machines or teammates. New machine? One command.

The Name

Kasetto (カセット) is the Japanese word for cassette - as in a cassette tape. A cassette was a self-contained, portable thing: you recorded something once, handed it to someone, and it played back exactly the same on any device. No setup, no drift, no "works on my machine." That's exactly what kasetto does for your AI agent environment - package it once, share it, and it reproduces identically everywhere.

Why kasetto

Declarative - one YAML config, version it, share it, bootstrap a whole team in seconds
Multi-agent - 21 built-in presets: Claude Code, Cursor, Codex, Windsurf, Copilot, Gemini CLI, and more
Multi-source - pulls from GitHub, GitLab, Bitbucket, Codeberg including self-hosted and enterprise
MCP management - merges MCP servers into each agent's native settings file automatically
Global and project scopes - install skills globally or per-project, each with its own lockfile
CI-friendly - --dry-run to preview, --json for automation, non-zero exit on failure
Single binary - no runtime dependencies, written in Rust, fast cold starts

How It Works

Define your config:

agent:
  - claude-code
  - cursor
  - codex

skills:
  - source: https://github.com/org/skill-pack
    skills: "*"
  - source: https://github.com/org/skill-pack-2
    skills:
      - product-design
  - source: https://github.com/org/skill-pack-3
    skills:
      - name: jupyter-notebook
        path: skills/.curated

mcps:
  - source: https://github.com/org/mcp-pack

Then sync:

kst sync

That's it. Kasetto pulls the skills and MCP servers, installs them into the right agent directories, and merges MCP configs into each agent's native settings file. The next time you run sync, only what changed gets updated.

Command Overview

Kasetto ships with a focused set of commands - each does exactly one thing:

kst sync              # pull skills + MCP servers and install them
kst sync --dry-run    # preview what would change without touching anything
kst sync --json       # structured output for CI pipelines

kst list              # browse installed skills and MCPs interactively
kst list --json       # dump installed state as JSON

kst init              # scaffold a kasetto.yaml in the current directory
kst doctor            # check your environment and diagnose issues

kst clean             # remove all installed skills and MCP entries
kst self update       # update kasetto to the latest release
kst self uninstall    # remove kasetto and all its files
kst completions       # generate shell completions (bash, zsh, fish, etc.)

The binary is available as both kasetto and kst - the short alias makes daily use quick.

Install

macOS / Linux
curl -fsSL https://raw.githubusercontent.com/pivoshenko/kasetto/main/scripts/install.sh | sh

Homebrew
brew install pivoshenko/tap/kasetto

Cargo
cargo install kasetto

What's Next

The roadmap includes agents management and hooks management. If you have ideas or run into issues, open an issue - feedback from real users shapes the direction.

github.com/pivoshenko/kasetto

If kasetto saves you time, a GitHub star means a lot. And drop a comment below - I'd love to hear what your AI agent setup looks like today, and what pain points you're still hitting.

Claude's default teaching shape has no return: the 5-node loop that fixes it

Mon, 20 Apr 2026 21:03:04 +0000

Ask Claude to teach you a non-trivial concept and watch the shape of the reply. It almost always descends: definition, syntax, an example, maybe a second example, a closing sentence that is either a summary or a handoff. The descent is fine. The problem is there is no return.

The opening hook — the analogy or scenario the reader would have used to latch onto the concept — is never revisited. Syntax gets retained. Mechanism does not. A week later the reader can name the API but cannot explain why it works, because the concept was never re-grounded into the surface form they started in.

I teach myself by having a fixed contract that forces the return. Five nodes. Every non-trivial concept travels them in order. If the teaching exchange does not close back on the opening analogy, the loop is incomplete and the concept has not landed — regardless of how detailed the middle was.

This is the rule I run in claude-code-agent-skills-framework under .claude/rules/concentric-loop.md. It carries a WHY tag and a retire-when clause so it decays cleanly when Claude's default teaching shape improves enough to make the rule unnecessary.

The five nodes

The loop travels analogy → code → system intermediaries → hardware/math → analogy. The final node is not a new analogy. It is the same analogy, now meaning more because the reader has traveled the physics underneath it.

Node	What it is
1. Analogy (OPEN)	A lived-experience scenario the reader already reasons fluently inside. Cooking, driving, a physical object in the room.
2. Code	The first machine-legible layer. Python, TypeScript, shell. I/O contract named before any line is written.
3. System intermediaries	OS syscalls, networking, file descriptors, memory management. What the kernel is doing when the code runs.
4. Hardware / math	CPU/GPU, IEEE 754, linear algebra, probability, gradients. The physics of correctness.
5. Analogy (RETURN)	The same analogy as node 1, reinterpreted through the descent.

The descent is node 2 → 3 → 4. The return is not a victory lap. It is the gate that decides whether the reader has upgraded their mental model or only added facts to it.

Practitioner anchors per node

Each node is pinned to a named methodology from a working 2025-2026 practitioner. If a teaching exchange cannot be traced to at least one of these per node it traverses, the descent is ungrounded and I pause and re-anchor.

Node 1 (analogy). No practitioner here — the anchor must come from the reader's own life, not a canon text. Borrowing an analogy from a book is how analogy inflation starts.

Node 2 (code / I-O framing) — Chip Huyen. Every code node opens with an explicit input/output specification: what goes in, what comes out, what data is available at what latency tier (online / nearline / offline). The latency-tier framing originates with Netflix (Amatriain and Basilico, 2013) and Huyen mainstreamed it in Designing Machine Learning Systems. The node sounds like: "Before we write the function, state the contract. What is the input type, the output type, and what data are you assuming is already computed vs. computed on demand?"

Node 3 (system intermediaries / empirical baseline) — Eugene Yan + Hamel Husain. Before any ML or agent component is introduced, Yan's "start with the problem, not the technology" asks: what regex, SQL, or rule-based filter already gets 50-70%? Before building on top of an LLM, Husain labels 20-100 real outputs by hand. The manual trace becomes the eval harness. The node sounds like: "Before we pick the model, show me the 30-line regex that would already solve half of this. Before we tune the prompt, label 25 outputs and tell me which ones are wrong and how."

Node 4 (build-to-understand) — Jeremy Howard + Sebastian Raschka. Howard (fast.ai Part 1) runs top-down: get a working artifact end-to-end first, then spiral into mechanism. Raschka (Build a Large Language Model from Scratch) runs bottom-up: raw tensors, manual attention, everything by hand. The two balance each other. Howard for momentum ("I built a thing"), Raschka for mechanism ("I built the thing's guts"). The node sounds like: "Get it working end-to-end on 10 rows first — we will earn the right to optimize. Then we peel the library open and rebuild the core in 40 lines."

Node 5 (atomic derivation / return) — Andrej Karpathy + Julia Evans. Karpathy: shrink the concept until it fits in your head. micrograd is 100 lines of autograd; nanoGPT is 300 lines of training. The return to the analogy lands when the reader has seen the guts small enough to hold. Evans is the OS descent safety net: when the abstraction leaks, drop to strace / tcpdump / perf / /proc. The node sounds like: "Now that you have traced the whole thing, reduce it to the 40-line version you can explain on a whiteboard. If the abstraction leaks, we run strace and watch the syscalls."

Five failure modes the loop has to catch

The shape of the loop is not the hard part. The failure modes are.

1. Patronizing return. The closing analogy is simpler than the opening one. This signals the teacher condescended during the descent — softened the mechanism — and the reader gets a dumbed-down echo of where they started. The return must land at equal or higher sophistication, enriched by the descent.

2. Analogy leakage. The reader starts reasoning about the analogy instead of the system. "Functions are like machines that take input and return output" breaks at closures, first-class functions, recursion. If the analogy never breaks, the reader is reasoning about the analogy, not the mechanism. Gentner's structure-mapping says the places the analogy does NOT map are where the deepest meaning lives — surface at least one.

3. Descent-avoidance. The return becomes permission to skip math or OS. "We closed the loop on that one, moving on." The loop is not complete until nodes 3 AND 4 are traversed. A loop that skips the descent is a shape, not a proof.

4. Premature return. Returning before mechanism-level understanding lands. The Bransford transfer test below is the gate.

5. Analogy inflation. Multiple analogies accumulate. The reader remembers the metaphors and forgets the mechanisms. One analogy per concept. The return reuses the opening analogy. Do not replace.

The Bransford transfer test (loop-completion gate)

Bransford and Schwartz, "Rethinking Transfer" (1999), is the empirical spine. Transfer requires re-encountering the concept in a different surface form. Descent-only teaching produces what Whitehead (1929) called "inert knowledge" — the reader cannot apply it outside the original context.

After the return, pose a novel problem in a new surface form. Different domain, different vocabulary, different practitioner's framing. If the reader solves it, the loop worked. If the reader can only reproduce the original analogy, the loop collapsed into memorization and needs another descent with a different analogy or a deeper cut.

This test also works as an eval for Claude's output. Swap the system prompt or the input schema. Check whether the agent's correctness transfers or was memorized against the original framing. The three failure signals: (1) the agent can only reproduce the original analogy, (2) it solves the old problem but not the transfer, (3) it solves the transfer only after a hint.

Whole-loop practitioners worth studying

These four execute the entire loop in a single artifact — open, descent, return — and are worth reading to feel the shape end to end.

Julia Evans — zines and blog (jvns.ca). Scenario opens, syscall/kernel middle, practical close.
Jeremy Howard — fast.ai Part 1. Whole game first, then mechanism, then whole game with new eyes.
Andrej Karpathy — Zero to Hero. Opens with analogy ("a neural net is just a function"), descends through autograd/backprop, returns to "now you can train GPT."
Bret Victor — "Ladder of Abstraction." The loop is the argument.

Pick any post by any of the four. Mark where the open is, where the descent hits its deepest point, and where the return lands. You will start seeing the shape everywhere it exists and everywhere it is missing. The second list is longer than the first.

That is the whole practice. Contract the shape into a rule file. Apply it to every concept you explain and every concept Claude explains to you. Refuse to call the concept landed until the return fires.

Aman Bhandari. Operator of an AI-engineering research lab running Claude Opus as the coaching partner, plus a QA-automation surface shipping against a real sprint workload. Public artifacts: claude-code-agent-skills-framework and claude-code-mcp-qa-automation. github.com/aman-bhandari.

I Built a 35-Agent AI Coding Swarm That Runs Overnight

Mon, 30 Mar 2026 20:18:33 +0000

*Follow-up to *The Week I Stopped Coding

A month ago, I wrote about the moment I stopped coding and started orchestrating AI agents. That post was about the shift — the emotional and philosophical pivot from developer to director.
This post is about what happened after.
I built a system. Two physical machines on my home network, 14 containers, 35 concurrent AI coding sessions, and a 5-layer memory architecture that teaches agents not to repeat each other's mistakes. It scans my project management board every two minutes, picks up tickets, creates isolated git worktrees, spawns Claude Code sessions, writes code, creates pull requests, and updates ticket statuses — all without me touching a keyboard.
It processes 20-40 tickets overnight. I wake up to PRs.

I've Seen This Before

In 2015, I was drawing CI/CD pipeline diagrams on whiteboards at Kohl's. Build → Test → Publish → QA → Deploy → Stabilization → Release. The full continuous delivery loop, managed by hundreds of people across multiple teams — developers, QA engineers, DevOps, project managers, release coordinators.

I look at that diagram now and I see my swarm's ticket lifecycle. The stages are identical. Linear scan is the ticket intake. The Claude Code session is the development cycle. Sub-agents run the build, test, and review gates. gh pr create is the publish step. Vercel auto-deploys on merge. Prometheus watches the stabilization metrics. The only difference is who's executing each stage.
In 2015, that loop required a branching strategy document that went through 11 revisions, a deployment runbook with IBM coordination steps, Chef cookbooks for node management, and a standing army of engineers. In 2026, it's one Node.js script and a vector database.
I'm not saying the people don't matter — they built the institutional knowledge that's now encoded in CLAUDE.md files and Qdrant collections. But the execution layer has fundamentally changed. The same pipeline I designed for human teams a decade ago now runs autonomously on two machines in my house.

The Hardware: Two Machines, One Network

No cloud compute for the swarm itself. Two machines on my home network — a Linux desktop and a Mac Studio I picked up for mobile builds.

Dragon (desktop) — Arch Linux, AMD ROCm GPU, 14 Podman containers. This is the primary orchestration node. It runs the director, the dashboard, Qdrant for vector search, Ollama for embeddings, and the full Prometheus/Grafana monitoring stack. 15 concurrent session slots.
Hive (Mac Studio) — The only machine with Xcode, iOS simulators, Android emulators, Fastlane, and Maestro for mobile QA. 20 concurrent session slots. Three macOS LaunchAgents handle its director, worker, and git-watcher processes.
They talk over SSH and a shared Qdrant instance. The desktop pushes build tasks to the hive's Qdrant — I use the vector database as a task queue because macOS LaunchAgents get EHOSTUNREACH when connecting back to the desktop IP. Flipping the direction solved it.
Total capacity: 35 concurrent AI coding sessions across 6 repositories.

The Three Layers

The architecture has three distinct layers, each operating independently.

Layer 2: Ops Runner. Infrastructure health. Zombie process detection every 15 minutes. TTL sweeps that mark tasks stuck over 30 minutes as failed. Metrics export to Prometheus — 43 metrics every 5 minutes. A React dashboard with 6 tabs that gives me visibility into what the swarm is doing. Without this layer, you don't know if the swarm is working or burning money.
Layer 3: Directors. This is the AI layer. Two directors — Dragon on the desktop handling backend and infrastructure (event-api, game-library, venues, monitoring, ops), Hive on the Mac Studio handling frontend and mobile (shindig, website). Each scans Linear every 2 minutes, routes tickets to the correct repo, creates git worktrees for isolation, and spawns Claude Code sessions.
The director is about 2,400 lines of Node.js. It's the single most important piece of the system — and in major need of refactoring. Now that I'm wrapping back around to making the ops swarm self-sufficient, it needs to follow its own linting and testing protocols. The irony of an autonomous coding system that doesn't enforce code quality on itself is not lost on me.

How a Ticket Becomes a PR

Linear scan (every 120 seconds). The director queries for tickets in Agent Queue, QA Queue, QA Testing, or In Review. It checks attempt history — each ticket gets 3 shots before it's skipped.
Ticket routing. Title prefix [website] goes to the website repo. No prefix? Keyword matching. The detectRepo() function is blunt but effective:

function detectRepo(issue) {
  const text = `${issue.title} ${issue.description || ''}`.toLowerCase();
  // Check explicit repo names first
  for (const repo of ['shindig', 'venues', 'event-api', 'game-library', 'website', 'monitoring']) {
    if (text.includes(repo)) return repo;
  }
  // Mobile/app keywords → shindig
  const shindigKeywords = ['maestro', 'e2e test', 'testflight', 'app store', 'play store',
    'fastlane', 'ios', 'android', 'mobile', 'kotlin', 'swift', 'xcode', 'gradle',
    'composable', 'jetpack', 'kmp', 'multiplatform', 'simulator', 'emulator',
    'firebase auth', 'deep link', 'push notif', 'in-app purchase', 'storekit',
    'billing', 'aab', 'ipa', 'bundle id', 'provisioning', 'signing key',
    'app group', 'widget', 'crashlytics'];
  for (const kw of shindigKeywords) {
    if (text.includes(kw)) return 'shindig';
  }
  // Ops/infra keywords → ops
  const opsKeywords = ['swarm', 'ops', 'ci/cd', 'pipeline', 'deploy', 'config',
    'infrastructure', 'docker', 'podman', 'container', 'github action',
    'orchestrat', 'director', 'dashboard', 'grafana', 'prometheus',
    'script', 'automation', 'devops', 'agent', 'memory', 'qdrant',
    'terraform', 'gcp', 'cloud run', 'fly.io', 'vercel'];
  for (const kw of opsKeywords) {
    if (text.includes(kw)) return 'ops';
  }
  return 'unknown'; // skip rather than routing to wrong repo
}

Fair warning: this is quick, dirty, get-it-running code. Not pretty. It works, it's being refactored, and I'm showing it because the pattern matters more than the polish.
This was the first pass. It's not sophisticated. It doesn't need to be. The title prefix catches 80% of tickets. The keyword fallback catches most of the rest. Unknown tickets get skipped — better to miss a ticket than route it to the wrong repo.
Since then, the routing has gone through a full arc. I added Linear labels, repo-specific tags, and more complex matching rules. It got more sophisticated — and harder to maintain. Now I'm simplifying back down: labels and tooling handle the routing upstream, so the director doesn't need 50 keywords to figure out where a ticket belongs. The lesson is the same one every system learns — the first simple version works, the complex version works harder, and the final version is simple again on purpose.

Worktree creation. git worktree add creates an isolated directory with its own branch: agent/fir-{ticketId}. Multiple tickets for the same repo can run in parallel without stepping on each other. This is essential — without worktree isolation, concurrent agents create merge conflicts on every commit.
Session spawn. The director launches Claude Code with the ticket description, all comments, the repo's CLAUDE.md rules, and RAG context from prior agent learnings — all injected into the system prompt. Model starts at Sonnet. If it fails twice, it auto-escalates to Opus.
Execution. The Claude Code session reads code, plans an approach, and spawns its own sub-agents — a researcher (Haiku), a coder (Sonnet), a tester (Haiku), and a reviewer (Haiku). Each sub-agent gets a fresh context window. No context pollution from the parent.
PR creation. The session commits, pushes, creates a PR targeting the repo's base branch, and updates the Linear ticket status.
Cleanup. Worktree removed. Pool slot freed. Next scan picks up more work.
The director also batches up to 4 tickets per repo into a single session, so the agent has broader context and can address related issues together. A typical ticket takes 5-60 minutes depending on complexity. The director fills available pool slots continuously. By morning, I have a stack of PRs to review.

Inside the Director: processTicket()

The heart of the system is processTicket(). This is the function that takes a ticket from the queue and turns it into a coding session. Here's what happens under the hood — model escalation, worktree creation, rate limit detection, and the failure classification that took me weeks to get right:

async function processTicket(ticket, config, state) {
  let worktree;
  try {
    // Model escalation: after N failed attempts, upgrade to stronger model
    const prev = state?.ticketsWorked?.[ticket.identifier];
    const failedAttempts = prev ? prev.attempts : 0;
    const threshold = config.escalationThreshold ?? ESCALATION_THRESHOLD;
    const escalated = failedAttempts >= threshold && config.model !== config.escalationModel;
    const ticketConfig = escalated
      ? { ...config, model: config.escalationModel }
      : config;

    if (escalated) {
      log(`MODEL ESCALATION: ${ticket.identifier} failed ${failedAttempts}x ` +
          `on ${config.model} → upgrading to ${config.escalationModel}`);
    }

    acquireLock(ticket.identifier, ticket.repo);
    worktree = createWorktree(ticket.repo, ticket.identifier);

    const result = await runClaudeSession(ticket, worktree.worktreePath, worktree, ticketConfig);

    if (!result.success) {
      const tail = result.output.slice(-300);

      // Detect rate limit OR auth failure errors
      const isRateLimit = RATE_LIMIT_PATTERNS.some(p => p.test(tail));
      const isAuthFailure = AUTH_FAILURE_PATTERNS.some(p => p.test(tail));
      const isFastFail = result.duration_ms < FAST_FAIL_THRESHOLD_MS && !result.timedOut;

      // Fast failures (< 10s) are never real work — don't burn attempts
      if (isFastFail) {
        result.rateLimited = true;
        log(`FAST FAIL: ${ticket.identifier} died in ` +
            `${Math.round(result.duration_ms / 1000)}s — not counting as attempt`);
      }

      if (isRateLimit || isAuthFailure) {
        if (!rateLimitState.detected) {
          rateLimitState.detected = true;
          // Parse reset time, default to 4am Central
          const resetMatch = result.output.match(
            /resets?\s+(\d+)\s*(am|pm)\s*\(([^)]+)\)/i
          );
          // ... calculate sleep duration, auto-pause director
          notifySlack(`:warning: Director hit rate limit. Auto-pausing until reset.`);
        }
      }
    }

    return { ticketId: ticket.identifier, success: result.success, ... };

  } finally {
    releaseLock(ticket.identifier);
    cleanupWorktree(worktree);
  }
}

Same caveat as above — this is working code, not clean code. The director script is 2,400 lines of Node.js that grew organically as failures taught me what it needed to handle. Refactoring it is on the roadmap.
The escalation logic is simple: attempts 1-2 run on Sonnet. Attempt 3 auto-upgrades to Opus. The rate limit detection is what took the most iteration — the system had to learn the difference between "this ticket is hard" and "the infrastructure is down." That distinction saved me from permanently skipping dozens of viable tickets.

How Do You Solve AI Agent Memory Loss?

AI agents are amnesiac by default. When I started, a Claude Code session got 200K tokens of context. Now Opus 4.6 has a 1M token window. Bigger helps — but the fundamental problem is the same. The moment the session ends, everything it learned disappears. The next agent assigned a similar ticket starts from zero and makes the same mistakes.
This is the fundamental problem of autonomous AI coding at scale. I solved it with 5 layers of memory, each serving a different persistence scope.

Layer 2: CLAUDE.md files. Checked into git at each repo root. Every agent session in a repo automatically loads these rules — branch patterns, build commands, quality standards, things the agent must never do. This is institutional knowledge encoded as configuration.
Layer 3: File memory. Claude Code's auto-memory system at ~/.claude/projects/. Over 20 topic files covering build pipelines, secret management, deployment procedures, lessons learned. Survives across sessions on the local machine.
Layer 4: Vector memory. Qdrant stores nearly 16,000 knowledge points and all agent outcomes. Before starting work, agents query for relevant prior learnings using semantic search. After completing work, they record what happened — success or failure, with context. This is how the swarm learns. A failed Gradle build gets recorded. The next agent searching "shindig android build" finds it and doesn't repeat the same mistake.
Layer 5: Linear tickets. The human-agent interface. I embed decisions directly in ticket descriptions and comments. Agents read both before acting. This is the only layer where I actively participate in the memory system.
The key insight: agents query Qdrant before starting work and record outcomes after finishing. A memory-agent container consolidates learnings every 6 hours. The swarm genuinely learns from its own history.

The Failures

This is the part that matters. Anyone can describe an architecture. The real story is in how it broke.

124 Pull Requests Overnight

I woke up to 124 open PRs on one repo. About 90 were duplicates — the same tickets processed over and over because the director never checked whether a PR already existed. It would scan Linear, find tickets in Agent Queue, spawn sessions, create PRs — but never move tickets out of Agent Queue. Next scan cycle: same ticket, new branch, new PR.
While I was closing duplicates, the hive director kept creating new ones. 7 more appeared during cleanup.
The fix: Dedup guard. Check for existing PRs before creating new ones. Move tickets to In Progress when work starts, In Review when the PR is created. Deterministic branch naming — no random suffixes.
The lesson: If your agent loop doesn't track what it already did, it will do everything twice.

Every Session Ran on Opus

I noticed rate limits being hit in hours instead of lasting all day. The director script never passed a --model flag. Claude Code defaults to Opus — the most expensive model. 747+ sessions ran on Opus before I caught it.
One missing CLI flag. Token consumption was 3-5x what it needed to be. A $15/day operation became $65/day.
The fix: Added --model sonnet as default. Model escalation: attempts 1-2 use Sonnet, attempt 3 auto-escalates to Opus. Immediate 3-5x cost reduction.
The lesson: Defaults matter enormously at scale. A single missing flag multiplied by 1,000 sessions turned a cost-effective operation into a budget-burner.

46 out of 46 Sessions Failed in One Cycle

The director launched 46 sessions. Every single one died within 1-20 seconds with "You've hit your limit." The director treated these as normal failures, incremented attempt counters, and after 3 "failures" permanently skipped each ticket.
By morning, 37 tickets were stuck in limbo and dozens were marked as "max attempts exceeded" — even though the failures had nothing to do with the tickets themselves.
The fix: Rate limit pattern matching. Auth failure detection. Fast-fail threshold — sessions dying in under 10 seconds don't count as real attempts. If >80% of a cycle's sessions fail fast, auto-pause the director and sleep until the rate limit resets.
The lesson: Your orchestrator must distinguish between "the task failed" and "the infrastructure failed." Burning ticket attempts on rate limits is like marking a restaurant order as "rejected by customer" because the kitchen caught fire.

The Agent That Sent Me on a Wild Goose Chase

A Haiku-model agent was assigned an Apple Sign-In bug. After a brief code scan, it confidently told me: "The Firebase Console needs com.firefly.shindig.dev added as an authorized domain."
I spent 20 minutes checking the Firebase Console. It was already correct. The .dev bundle ID doesn't even exist — the app uses com.firefly.shindig.ios.
The real problem was three code bugs the agent never found.
The fix: Verification protocol. Agents can't tell humans to change external config without file-and-line code evidence. Memory files take precedence — if memory says it's configured and working, the agent needs strong evidence before claiming otherwise. Config-level claims get escalated to Opus for verification.
The lesson: An agent that confidently sends you on a wild goose chase is worse than one that says "I don't know." Cheaper models need guardrails that prevent authoritative claims about systems they can't inspect.

Claude Code authenticates via OAuth. Tokens expire and refresh automatically. I tried three approaches to get auth working in Podman containers:

Run claude login inside the container. Works until restart — credentials wiped.
Base64-encode credentials as an env var. The entrypoint script always decodes on startup, overwriting any token refresh.
Copy host credentials at build time. Stale by the time the container runs.
The fix: Bind-mount the host credentials file directly into the container:

volumes:
  - ${HOME}/.claude/.credentials.json:/home/swarm/.claude/.credentials.json:rw

Login once on the host, container stays authenticated across restarts, rebuilds, and token rotations. Set the env var to empty string so the entrypoint skips injection.
The lesson: Live auth tokens must be shared, not copied. Any approach that snapshots a token creates a stale copy.

Five Zombie Detectors, All Broken

After the 124-PR incident, I discovered agent processes that finished work but never exited. They consumed memory and held file locks, preventing new sessions.
I had five separate zombie detection mechanisms. Not one caught the problem.
The bash script only checked for duplicates, not resource thresholds. The task-level checker only looked at output file freshness. The cleanup script explicitly skipped daemon processes. The ops runner only checked Qdrant task state. The container-based detector couldn't see outside its own namespace.
The fix: One detection mechanism that actually works end-to-end. Process-level zombie detection in the ops runner. Session timeout as a catch-all.
The lesson: Five bad detectors are not better than one good one. Each was built for a specific variant of the problem but had blind spots. The result was false confidence.

The Numbers

Over 7 weeks of operation:

Metric	Value
Total agent runs	6,500+
Repos covered	6
Peak day (March 5)

Claude Code agent teams: what the docs don't tell you

Tue, 17 Feb 2026 08:06:17 +0000

Claude Code quietly shipped agent teams as an experimental feature. The idea is simple: instead of one AI agent working through your task sequentially, you spin up multiple agents that work in parallel, communicate with each other, and coordinate through a shared task list.

I've been running team sessions for the past week. Some went well. Some burned through tokens and produced nothing useful. Here's what I figured out.

You need to enable it manually

Agent teams are off by default. Add this to your settings:

// .claude/settings.json or ~/.claude/settings.json
{
  "env": {
    "CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS": "1"
  }
}

Or export it in your shell: export CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1

Subagents and agent teams are different things

This tripped me up at first and I've seen the same confusion everywhere. Claude Code has two parallelism mechanisms, and they work nothing alike.

Subagents use the Task tool. You spawn a focused worker, it does a thing, and returns results to the parent. Workers can't talk to each other. The parent manages everything. Token cost is lower because results get summarized back into the parent's context.

Agent teams are fully independent Claude Code sessions. Each teammate has its own context window, loads project context (CLAUDE.md, MCP servers) automatically, and can message other teammates directly. They coordinate through a shared task list with file-locked claiming and dependency tracking.

The practical difference: subagents are like sending someone to fetch an answer. Agent teams are like putting three people in a room to work on a problem together.

Here's when each one makes sense:

Use subagents when...	Use agent teams when...
You need quick, focused results	Teammates need to discuss and challenge each other
Tasks are independent — no cross-talk needed	Work requires coordination across multiple layers
You want lower token costs	Parallel exploration adds real value
The parent can manage all coordination	Tasks have clear file boundaries but need collaboration

I'd estimate 70-80% of tasks that feel like they need a team actually work fine with subagents. The Task tool with subagent_type set to Explore, Plan, or general-purpose handles most research and implementation tasks without the coordination overhead.

The cost math

Each teammate is a full Claude session with its own context window. A 3-teammate team uses roughly 3-4x the tokens of sequential work.

That's not a rounding error. For a task that takes 20 minutes sequentially, spinning up a team to finish it in 8 minutes costs 3-4x more. Whether that trade-off makes sense depends on how much your time is worth relative to API spend.

The tasks where teams clearly pay off:

Multi-file features with clean boundaries (frontend + backend + tests)
Large refactors where multiple directories can be worked on simultaneously
Adversarial review patterns (one agent implements, another tries to break it)

The tasks where they don't:

Anything touching fewer than 4-5 files
Sequential work where step 2 depends on step 1's output
Quick bug fixes (the coordination overhead exceeds the time saved)

File conflicts are the #1 failure mode

Two teammates editing the same file doesn't produce a merge conflict. It produces data loss. One agent's changes silently overwrite the other's.

This was my most expensive lesson. Before any parallel coding, you need to map out exactly which agent owns which files. No shared files. If two tasks need to touch the same file, they run sequentially, not in parallel.

The pattern that works: decompose your task into pieces where each piece owns a distinct set of files. If you can't draw clean boundaries, the task isn't a good candidate for a team.

Teammates don't know what you know

This is counterintuitive. Your main Claude Code session (the "lead") has your full conversation history — the bug you described, the architecture you discussed, the constraints you mentioned. When you spawn a teammate, they start with a blank conversation. They load CLAUDE.md and MCP servers, but they don't inherit any of your context.

This means your spawn prompts need to be detailed. Not "implement the auth module" but "implement an auth module using JWT tokens stored in httpOnly cookies, following the patterns in src/middleware/auth.ts, compatible with the Express 5 router setup in src/app.ts, with unit tests in tests/auth.test.ts."

The more context you front-load into the spawn prompt, the less the teammate drifts. I started writing spawn prompts that were 200-300 words and the quality of output went up immediately.

The workflow that actually produces results

After several failed attempts, here's the sequence I settled on:

1. Decide if you need a team at all.

Ask yourself: can I decompose this into 3+ parallel tasks with zero file overlap? If no, use sequential work or subagents.

2. Decompose into agent-sized pieces.

Each piece needs: a clear goal, explicit file ownership, a definition of done, and an integration contract (how this piece connects to the others). Vague task descriptions produce vague results.

3. Map file boundaries.

Write it down. Agent A owns these files. Agent B owns these files. No overlap. If you skip this step, you will lose work.

4. Plan first, then swarm.

Spawn one agent in plan mode to design the architecture. Review and approve the plan. Then spawn parallel agents to implement against the approved plan. This prevents agents from making conflicting architectural decisions.

5. Run a retrospective.

After the team finishes, look at what each agent actually did, how many tokens each consumed, and where time was wasted. The cost breakdown alone will change how you structure the next run.

Things that will bite you

A few gotchas that aren't in the docs:

No session resumption. If your terminal session drops, /resume and /rewind don't restore teammates. The team is gone. This matters for long-running tasks — save checkpoints or break work into shorter team sessions.

Tasks get stuck. Teammates sometimes forget to mark tasks as completed, which blocks any dependent tasks downstream. If something looks frozen, check the task list manually.

Shutdown is slow. Teammates finish their current API request before stopping. If an agent is mid-generation on a long response, you'll wait.

Drift happens. Letting a team run unattended for 30+ minutes increases the chance of wasted work. Agents can go down rabbit holes, misinterpret requirements, or produce code that conflicts with another agent's approach. Check in periodically.

One team per session. Clean up the current team (shut down all teammates, then delete the team) before starting a new one.

Start with non-code tasks

If you haven't used agent teams before, don't start with parallel implementation. Start with tasks where parallel exploration is valuable but file conflicts aren't a risk:

Multi-angle PR review: one agent checks logic correctness, another checks test coverage, a third checks security and error handling
Competing hypotheses debugging: agent A investigates "this is a race condition," agent B investigates "this is a stale cache," they report findings and you decide
Research from multiple angles: one agent reads the library docs, another searches for known issues on GitHub, a third looks at alternative libraries

These tasks let you learn how messaging, task claiming, and coordination work without the stress of parallel file edits.

A 19-prompt playbook

After running enough team sessions to see the patterns, I built a set of reusable prompts covering the full lifecycle:

Decide (prompts 1-5): Should I use a team? How do I decompose the task? What model for each agent? How do I map file boundaries?
Orchestrate (prompts 6-12): Plan-then-swarm coordination, delegate mode, adversarial code review, parallel TDD, handoff reports, real-time steering
Quality (prompts 13-15): Hooks that auto-validate work before an agent goes idle or marks a task complete, plan approval checklists
Recover (prompts 16-19): Unsticking looping agents, optimizing token costs, retrospectives, anti-pattern detection

The full playbook is free: Claude Code Agent Teams Playbook on NerdyChefs.ai

The honest take

Agent teams are a power tool, not a default workflow. The coordination overhead — context duplication, file boundary management, spawn prompt writing, monitoring for drift — means they only pay off for genuinely parallel work with clean boundaries.

For a solo developer working on a focused feature, sequential Claude Code with occasional subagent calls is cheaper and more predictable. For a large cross-layer feature where three agents can work on frontend, backend, and tests simultaneously without touching each other's files, teams save real time.

The key is being honest about which category your task falls into before you spawn anything.

What patterns have you found with agent teams? I'm particularly interested in hearing about non-obvious use cases where the parallel coordination actually paid off.

Coder Legion - Recent posts tagged claudecode

Claude Code For Free Unlimited: Local Setup with Ollama + Qwen 3.8

Claude Code Design Canvas: Every Screen of Your App From One Prompt

How to Use Claude Code with Opus 5.5 & Fable 5.1 for Free (No Card Required)

🎥 Watch the Video Tutorial

What You Get

How much is 500K tokens?

Why Use Claude Code with Free Tokens?

Claude Code & Cursor: Why Your AI Agent Lies to You (And Our 3-Tier Adversarial Tribunal Skill)

1. The Anatomy of "First-Draft Sycophancy"

2. Enter critic-refine v1.1.0: The 3-Tier Adversarial Engine

Why Phase 1 Forbids Boilerplate

The Anti-Complacency Rule

3. Killing Confirmation Bias: The "Zero-Context Blind Audit"

4. The Anti-Sycophancy Deductive Rubric

5. The Complete SKILL.md Specification (v1.1.0)

🧪 Put It to the Test (I Want Your Feedback!)

Claude Haiku 5.5 Pricing: Stay Under the 100K-Token Price Cliff

The short answer

How Claude Haiku 5.5 pricing works

What counts toward the 100,000-token threshold

Why prompts that fit on Claude Haiku 4.5 land over the line

Count before you send

Retrieval and document jobs: pack to a budget, split instead of stuffing

Agent loops: the cliff arrives mid-run

Watch the line in production

When the long-prompt price is the right price

Other migration changes that move the bill

FAQ

A migration checklist

Remote Control for API-Based Claude Code: Approve Bedrock, Vertex & Foundry Sessions From Your Phone

Claude Code’s Remote Control needs a Claude subscription login, so API-provider sessions are stuck in the terminal — here’s how I gave them one back with hooks, a file queue and a single Python file

The problem

An analogy before the tech

Why the obvious answers don’t fit

The idea: borrow the Remote Control you already have

1. Hooks on the API-based session

2. A file queue

3. The relay session

Questions, and why answers are mapped by position

A two-way conversation

Teams: one cloud account, many people

This isn’t just my problem — the open requests it answers

Getting started

What I learned building it

Honest limits

Why this matters

Links

ChatGPT, Claude, Gemini, or Cursor? Which AI Tool Is Your Go-To and Why?

ChatGPT, Claude, Gemini, or Cursor? Which AI Tool Is Your Go-To and Why?

The Developer's Usual Suspects

Join the Discussion!

97% of what my coding agent billed for was re-reading its own context

Why it looks like this

The part you can actually change

Measuring it yourself

Two traps, in case you write your own counter

Limits

The data

GoGraph updates, Providing Structural Awareness to AI Coding Agents in Go.

Meta-Architect for AI Coding Agents

Meta-Architect is an open-source workflow governor for AI coding agents.

What it includes

Why it’s different

🧩 Quick start

AI agent installation prompt

Install into an AI vendor host

The Anthropic “Obsidian Brain” Leak Never Happened.

When AI Agents Start Doing Your Coding Job

AI #ClaudeCode #Coding #Programming #Developers #SoftwareDevelopment

Developer Weekly Briefing — August 14, 2026

Anthropic makes Claude Code's auto mode the default — and the data behind it is worth understanding

Cursor CLI ran code from cloned repos before its own trust prompt ever loaded

Microsoft's new testing agent targets the trust gap in AI-generated code

An AI agent leaked a sales team's financials. Mimecast built something to catch the next one.

Also from Coder Legion this week

How to use Agent Router credits with Claude Code as the example...

What Is Agent Router, and Why Are They Giving Away Credits?

Getting Your Credits...

Setting Up Claude Code With Agent Router Credits (Windows Terminal)

2. Enter `critic-refine` v1.1.0: The 3-Tier Adversarial Engine

5. The Complete `SKILL.md` Specification (v1.1.0)

`prior_attempts` is the asking primitive