How to Squeeze More Juice Out of Coding Agents Without Burning Money

Coding agents make continuation almost frictionless. You give the agent a goal, it searches the repo, edits files, runs tests, inspects logs, tries a fix, fails, tries another fix, and keeps looping. When the context window fills up, the tool compacts the session and the loop continues, which feels productive from the outside because files are changing, commands are running, and the agent never really stops.

After enough turns, the behavior often changes. The agent proposes a solution you already rejected, forgets why a previous patch failed, mixes files from two unrelated parts of the codebase, rereads irrelevant logs, or starts producing longer plans instead of making sharper decisions. Claude Code users often call this context rot, while the coding-agent community also talks about the dumb zone, a term associated with Dex Horthy, founder of HumanLayer, and his Research-Plan-Implement approach for coding agents. LinearB’s Dev Interrupted episode with Horthy frames RPI as a way to escape that dumb zone.

The practical goal is simple: keep the agent in the range where it has enough information to act, while avoiding the point where the session becomes too large, stale, and noisy for the model to reason well.

1. When intelligence gets cheaper, your bill can rise

The unintuitive economic problem is that cheaper intelligence can increase AI spending.

Stanford’s 2025 AI Index reported that the cost of querying a GPT-3.5-level model on MMLU dropped from $20 per million tokens in November 2022 to $0.07 per million tokens by October 2024, a reduction of more than 280x. At the same time, Menlo Ventures estimated that enterprise generative AI spending reached $37 billion in 2025, up from $11.5 billion in 2024. Reuters’ Live Markets coverage of the post-DeepSeek market debate explicitly framed the question through Jevons paradox: when a resource becomes cheaper to use, demand for it can increase enough that total consumption rises.

For coding agents, the mechanism is obvious once you start using them heavily. You delegate smaller tasks, launch more parallel sessions, let loops run longer, ask the model to “just try,” and spend tokens on problems that previously would not have justified a model call. The unit cost drops, then usage expands faster.

The expensive part is also repeated. A 90k-token session carried through 20 more turns means the model may process roughly 1.8 million input tokens before counting tool outputs, logs, retries, or generated code. Even with caching or subscription pricing, the quality problem remains: the agent is reasoning from a large accumulated state, and the marginal token is often noise.

2. Long context has diminishing returns

A larger context window gives the model more capacity, but capacity and usable context diverge quickly in real workflows.

The research is now strong enough that “context rot” should be treated as an engineering constraint rather than a vague anecdote. Chroma evaluated 18 LLMs, including GPT-4.1, Claude 4, Gemini 2.5, and Qwen3 models, and found that models do not use context uniformly; performance becomes increasingly unreliable as input length grows, even on deliberately simple tasks.

The paper Context Length Alone Hurts LLM Performance Despite Perfect Retrieval is especially relevant because it isolates the failure mode. Across math, question answering, and coding tasks, five open- and closed-source models degraded by 13.9% to 85% as input length increased, even when the models could retrieve all relevant information perfectly. The degradation remained even when irrelevant tokens were replaced by minimally distracting whitespace, and even when relevant evidence appeared immediately before the question.

Other long-context benchmarks point in the same direction. RULER found that, although many models claim context windows of 32k tokens or more, only half maintained satisfactory performance at 32k. NoLiMa removed literal lexical overlap between the question and the evidence; at 32k, most evaluated models fell below half of their short-context baselines. LongCodeBench found a coding-specific collapse on LongSWE-Bench, with Claude 3.5 Sonnet solving 29% of issues at 32k context and only 3% at 256k.

One useful distinction from the TMLS context-rot article is the difference between positional degradation and length degradation. Lost-in-the-middle is positional: the evidence is present, but its location hurts performance. Context rot is length-related: performance drops as the input grows, even when the evidence is placed favorably. Treating both as the same problem leads to weak fixes; reordering passages can help positional degradation, while length degradation requires reducing or compressing the context itself.

3. Use 100k tokens as a coding-agent red line

A popular rule says to stay under 50% of the context window: that is a decent instinct, but it is too simple. AgentPatterns makes the more useful point that degradation seems closer to an absolute token range than a fixed percentage of the advertised window, with practical onset often around 32k to 100k tokens depending on the task type. Its guidance is stricter for reasoning-heavy work, while The Claude Codex translates the dumb zone on a 200k-token window to roughly 60k to 150k tokens depending on user experience and task complexity.

For coding agents, I would use this operating rule:

Stay under roughly 100k total context tokens by default.

That number is a heuristic, but it gives the reader something actionable. When the session reaches 80k tokens, check whether the existing conversation is still valuable. When it approaches 100k, either compact with explicit instructions or start fresh with a handoff file. For architecture work, hard debugging, multi-file refactors, and anything requiring precise memory of failed attempts, aim lower when possible, often in the 32k to 60k range. For simple retrieval or repo exploration, you can tolerate more, but the extra context should still earn its place.

The important habit is to manage the session before it becomes visibly dumb. Once the agent is already looping, forgetting, or agreeing too easily, the transcript has probably become part of the problem.

4. The fix is context engineering

Anthropic describes context engineering as the practice of curating and maintaining the optimal set of tokens during inference, including system instructions, tools, external data, message history, and everything else that enters the context window. Its guiding principle is to find the smallest high-signal token set that maximizes the chance of the desired outcome.

For coding agents, context engineering means deciding what the model sees at each stage of the task: which files it reads, which logs stay on disk, which constraints are promoted into persistent instructions, which failed attempts are preserved, which tool outputs are summarized, and when the session should be compacted or cleared. Claude Code’s own docs make this concrete: CLAUDE.md files and auto memory load as context, shell output can be added to the conversation, and invoked skills enter the conversation and stay there for the rest of the session.

This is why context engineering is more than prompt writing. A prompt starts the work; context engineering controls the informational environment in which every later model call happens.

4.1. Design code for context

A useful mental model is that one line of code often costs around 8 to 10 tokens, depending on language, formatting, comments, and naming style. That means a 100-line file is often around 1k tokens, a 500-line file is often around 4k to 5k tokens, and a 2,000-line file can become a context event by itself.

That gives a practical target: keep most files around 100 to 500 lines when the architecture allows it. This is not a formatting religion; the point is to create units of code that an agent can read, understand, edit, and test without dragging half the repo into its working memory.

Large files cost twice. They require more tokens to inspect, and they usually contain more unrelated responsibilities, which makes the agent carry irrelevant details while trying to reason about a local change. Smaller files with clear boundaries make the agent’s search and editing behavior better, and they also make human review easier.

4.2. Keep skills short

The same logic applies to agent skills, rules, and persistent instructions. A 500-line skill file may feel complete, but it becomes a recurring context cost whenever it is invoked. In Claude Code, invoked skill content enters the conversation and stays there for the rest of the session; after compaction, Claude Code reattaches invoked skills within a budget, keeping the first 5,000 tokens per skill and 25,000 tokens total across reattached skills.

My rule of thumb: keep SKILL.md files under 100 lines, and make them shorter whenever possible.

A good skill should contain the invocation conditions, the workflow, the key constraints, the commands to run, and links or paths to deeper documentation. It should behave like a compact operating procedure, not like a tutorial. Put long examples, reference tables, API notes, and edge-case documentation in separate files that the agent can read on demand.

A skill that always loads 3,000 tokens to save the agent from searching 200 tokens is a bad trade.

4.3. Put long logs on disk

Logs are one of the fastest ways to rot a session. A failing test can produce thousands of lines, a build can emit pages of warnings, and a training script can dump metrics, stack traces, progress bars, and repeated messages. Once that output lands in the conversation, later turns have to carry it.

A better pattern is to save full logs to disk and put only a compact pointer in the conversation:

Full test output is in .agent/logs/parser-empty-input.log.
The relevant failure starts at "FAILED test_parser_handles_empty_input".
Use rg, tail, sed, or awk to inspect the relevant section.
Do not paste the full log into the conversation.

This preserves access to the raw evidence while keeping the active context small. The same pattern works for benchmark output, stack traces, JSON responses, search results, and generated reports. The conversation should hold the decision-relevant summary; the filesystem should hold the durable evidence.

4.4. Compact before auto-compact

Auto-compact has a timing problem: it runs near the hard capacity limit, while context rot usually begins much earlier, especially for coding tasks that require reasoning, multi-file consistency, and memory of failed attempts.

Claude Code’s docs say auto-compact is enabled by default and runs when context approaches the limit. In the current Claude Code model configuration docs, Sonnet 5 sessions with a 1M context window auto-compact at about 967k tokens by default. That is useful for keeping a session alive, but it is far beyond the 100k-token operating budget I would use for coding work.

By the time auto-compact fires, the agent may already have spent many turns in a degraded region. The summary is also being produced from a messy transcript that may contain obsolete plans, repeated failed attempts, stale logs, and contradictory corrections. A generic summary can preserve the wrong things and lose the exact constraints that mattered.

Manual compaction should happen earlier and with instructions:

Compact this session for continuation.
Keep:
- The original goal.
- The current implementation status.
- The files changed and why.
- The exact failing command and current error.
- Constraints that must not be violated.
- Hypotheses already tested.
- Failed approaches and why they failed.
- The next two recommended actions.
Discard:
- Verbose logs already saved on disk.
- Old plans that no longer apply.
- Repeated explanations.
- Unrelated files inspected during exploration.
- General background that is not needed for the next step.

When the next task is related and the debugging history still matters, compact with focus. When the next task is unrelated, clear the session and start with a minimal handoff. Claude Code’s own docs recommend clearing between unrelated tasks and using custom compaction instructions, and its troubleshooting docs suggest focused compacting, smaller file reads, subagents, or clearing when large outputs refill the context.

4.5. Prefer rewind when the trajectory is wrong

Corrections are expensive because they preserve the wrong path. If the agent misunderstood the goal early, adding “No, do it this way instead” leaves the failed attempt, your correction, and the new instruction in the transcript. The model now has to reason around all three.

When the tool supports it, rewind or edit the previous instruction. Claude Code’s checkpointing docs describe rewinding to previous code and conversation states when work gets off track, and The Claude Codex makes the practical context point: correcting pollutes the trajectory, while rewinding removes the bad path from it.

This is especially useful during the first few turns of a task. If the agent begins from a bad framing, rewrite the starting prompt while the session is still small.

4.6. Use Research, Plan, Implement as a context boundary

The Research-Plan-Implement workflow works well because it creates natural points for intentional compaction. HumanLayer describes this as frequent intentional compaction: structuring development around context management, keeping utilization in a safer range, and inserting human review at high-leverage points.

A clean version looks like this:

1. Research: inspect the codebase, identify relevant files, understand constraints, and write RESEARCH.md.
2. Plan: turn the research into PLAN.md, with phases, files, tests, risks, and acceptance criteria.
3. Implement: execute one phase at a time with only the plan, relevant files, and focused test commands.
4. Review: start fresh with the diff, the plan, and the acceptance criteria.

The useful state persists through files, commits, tests, and short markdown artifacts. The transcript can be compacted or discarded because the important information has been moved into durable, readable form.

4.7. Use subagents for context isolation

Subagents are useful when a side task would flood the main conversation with search results, logs, or file contents. Claude Code’s subagent docs describe subagents as separate context windows that return summaries, and its cost docs warn that each agent instance maintains its own context window, so team size and runtime still matter.

A good pattern is to send exploration to a read-only subagent, then return only the short result:

Use a read-only subagent to inspect the auth module.
Return:
- The 5 most relevant files.
- The current control flow.
- Any invariants that must be preserved.
- The focused tests to run.
Do not return full file contents unless necessary.

This keeps the main session clean while still giving the agent a way to investigate. Context isolation is especially useful for repo exploration, log triage, code review, and comparing alternative designs.

4.8. Write a minimal handoff file

A handoff should be short, factual, and easy for a fresh agent to act on:

# Agent handoff

## Goal

Implement X without changing Y.

## Current state

- Branch compiles.
- Focused test fails: `pytest tests/test_parser.py::test_empty_input`
- Full logs: `.agent/logs/parser-empty-input.log`
- Relevant error marker: `EMPTY_INPUT_REGRESSION`

## Relevant files

- `src/parser.py`: main implementation
- `tests/test_parser.py`: failing test
- `src/errors.py`: public error types; keep API stable

## Constraints

- Do not change public exception class names.
- Preserve behavior for whitespace-only input.
- Keep the fix local unless evidence requires a wider refactor.

## Failed attempts

- Tried normalizing input before tokenization; broke quoted strings.
- Tried catching the parser exception in the caller; hid useful error messages.

## Next step

Inspect `src/parser.py` and `tests/test_parser.py`.
Propose the smallest local fix.
Run the focused test first, then the parser test file.

This kind of file lets a new agent start from the current state without reading the whole transcript. It preserves constraints, evidence, and failed attempts, while dropping the long conversational trail that produced them.

4.9. Use the boring coding-agent loop

The efficient loop is boring, which is exactly why it works:

1. Start with a compact goal.
2. Load only the relevant files.
3. Make the smallest coherent change.
4. Run the most focused test.
5. Save full logs to disk.
6. Summarize only the useful failure.
7. Update the handoff file.
8. Compact or clear before the session rots.

The 100k-token rule gives the loop a concrete operating budget. At 80k, inspect the context. At 100k, compact with instructions or clear. For hard reasoning tasks, act earlier.

Coding agents become much more effective when context is treated as part of the architecture. Small files, short skills, compact logs, focused prompts, explicit handoffs, subagents for noisy exploration, and early manual compaction all serve the same purpose: each model call gets a cleaner state, and the agent spends more of its budget on the problem instead of the transcript.