Every coding agent operates within a hard ceiling, and when that window fills with file reads, test outputs, and edit history, the session either halts or suffers from 'quiet forgetting.' A new analysis from the developer of Ordewell, an Apache 2.0 licensed tool, argues that the standard fix of restarting and restating tasks is inefficient because it discards valuable reasoning. Instead, the proposal suggests a structural shift: decompose work into smaller, independent tasks before execution begins.

The Token Bloat Problem

The context window is not selective memory; it holds everything at once. The primary culprit for rapid exhaustion is not user input, but tool output. A single read of a large source file can consume tens of thousands of tokens, and a combination of reads, searches, and test runs can deplete half the budget before any code is written. This creates a session that feels sharp initially but becomes foggy and unreliable near the end, often dropping specific constraints like 'no-GraphQL rules' or abandoned approaches.

Why Compaction Is Only a Patch

Standard remedies like Claude Code’s /compact command replace the transcript with a lossy summary. While steering the compaction with specific instructions (e.g., '/compact keep the no-GraphQL rule') helps, it is still a band-aid. The author notes that if you find yourself compacting the same task more than once, it is a signal that the task is larger than a single window can carry. Project files like CLAUDE.md or AGENTS.md preserve stable rules but cannot hold in-flight state, such as which files have already been read or the current status of a partial refactor.

Ordewell’s Structural Approach

Ordewell approaches the problem by treating the plan as an artifact that outlives any single session. The tool reads the repository, generates an ordered plan with dependencies, and then executes each task in a fresh session within its own git worktree. By default, independent tasks run concurrently, three at a time. This ensures that each session only contains the specific task plus the outcomes of its prerequisites, rather than the entire conversation history. If a task fails, it is isolated on the plan, allowing developers to edit and rerun it without replaying the entire context.

Command-Line Workflow and Limitations

The workflow involves three primary commands: 'ordewell plan' to generate the task list, 'ordewell run' to execute, and 'ordewell handoff review' to manage dependencies. Developers can adjust task models and dependencies using commands like 'ordewell task-model 3 sonnet' or 'ordewell task-deps 3 1,2'. However, the author is honest about the limits: decomposition moves the wall but does not remove it. A single task that is inherently too large for one window remains a problem, and the handoff between tasks is lossy, meaning details that exist only in conversation history may not survive the transition to the next task.

Key Takeaways

  • Tool output, not user prompts, is the primary cause of context window exhaustion in coding agents.
  • Compaction commands like /compact are lossy patches that should not be used repeatedly for the same task.
  • Ordewell advocates for decomposing work into independent tasks executed in fresh sessions with isolated git worktrees.
  • The approach relies on storing the plan as an editable artifact on disk, allowing for targeted reruns of failed tasks.
  • Parallelism increases throughput but does not raise the context limit for any individual task.

The Bottom Line

Ordewell’s structural decomposition is a pragmatic evolution for agent workflows, shifting the burden from managing a single fragile session to orchestrating a resilient plan. While it does not eliminate context limits, it transforms them from a session-ending failure into a manageable scheduling constraint.

Sources

https://dev.to/ordewell/when-a-coding-agent-runs-out-of-context-mid-task-1coo