Same Model, Different Brain: Why GPT-6 Astra Stalls in Codex and Thrives in Claude Code

A few weeks ago, I moved a set of non-trivial engineering tasks over to GPT-6 Astra. I run autonomous coding agents daily for vulnerability research, harness generation, and systems refactoring. These are not five-line script requests. They involve traversing large codebases, tracing cross-module data flow, updating build targets, and fixing subtle runtime regressions.

My initial runs with Astra took place inside OpenAI Codex. The experience was baffling.

The model showed flashes of brilliance on isolated reasoning, but across long sessions it struggled to land real work. It would inspect a file, run a test, pause, re-inspect the same file, rewrite code it had just modified, and occasionally revisit hypotheses it had disproved twenty minutes earlier.

As sessions dragged on, its focus degraded. When context compaction kicked in, Astra often remembered the overall goal while losing its grasp on what had already been verified and what concrete step needed to happen next. Worse, my subscription usage evaporated. Sustained sessions routinely drained a full day of Astra allowance in a few hours.

I assumed Astra was simply prone to agentic drift on deep-horizon work. Then I switched the harness. I pointed Claude Code at the same GPT-6 Astra model through its API endpoint.

The change was immediate and jarring.

Astra became purposeful. It stopped running circular audits of its own edits. It retrieved only the files it needed, made surgical changes, ran the test harness once or twice, and stopped when the criteria were satisfied. Context compaction rarely derailed it. Over an hour of intensive refactoring, my Astra allowance barely registered the workload.

This is a qualitative, firsthand observation, not a formal benchmark. The two runs were not controlled trials, and subscription accounting is opaque. I cannot infer an exact quota formula from the meter. But the functional difference was unmistakable.

It forced an obvious question: how can the same frontier model feel dysfunctional inside one coding agent and exceptionally capable inside another?

The answer has less to do with raw model intelligence than with the architecture of the harness wrapped around it.

The illusion of model autonomy

It is tempting to treat an AI agent as a direct manifestation of the underlying model. When an agent succeeds, we praise the model's reasoning. When it spins in circles, we blame model degradation or benchmark gaming.

In practice, model capability is only an upper bound. The useful unit is the integrated system: model, context, tools, state, and loop.

This is an informal model, not a rigorous equation. It captures why frontier models regularly fail in autonomous environments.

When you interact with a model through an agent, the model never interacts directly with your codebase. It interacts with a prompt synthesized by the harness. The harness decides which files are exposed, how command outputs are formatted, what history is preserved, what is truncated, when the model is prompted again, and how intermediate steps are verified.

Above all, the primary resource being managed is not the nominal context-window length. It is attention.

A 200,000-token window does not imply equal attention to all 200,000 tokens. Flooding it with execution telemetry introduces distractors and forces the model to keep reconciling obsolete hypotheses with the current task. When an agent fails to converge, the failure may sit in context engineering and loop mechanics rather than the model's reasoning ceiling.

Inside Codex: the cost of stateless history

OpenAI's engineering post Unrolling the Codex agent loop explains the core mechanics. Codex operates as an unrolled sequence: model, tool, model, tool, until the model returns a final answer.

Codex does not currently rely on previous_response_id. OpenAI says this keeps requests stateless and supports Zero Data Retention configurations. Instead, earlier messages and tool interactions are included again as the input grows.

Across a session, that produces quadratic growth in the amount of JSON transmitted. This needs one important qualification: it does not imply quadratic inference compute. OpenAI designs the old prompt to remain an exact prefix of the new one so prompt caching can reuse prior work.

Caching makes the repeated prefix cheaper for the provider. It does not make the active working context small for the model.

GitHub issue #44305 contains a useful independent audit of complete Codex rollout logs. In one 11.4-minute run, 34 model requests and 33 tool calls processed 3.52 million cumulative input tokens. Of those, 3.37 million were cached. The active request grew from 16.7K to 158.3K tokens. A second run reached 197K and processed more than 12 million cumulative input tokens.

A later report, issue #44884, describes long-running workloads where small shell operations were associated with roughly 100K to 250K input tokens per request. The author observed a Pro 20x weekly allowance going from 14% used to 100% used over about 28 hours. The report carefully avoids claiming a known server-side quota formula. So do I.

The practical problem is downstream attention. A grep, file read, diff, or failed test can persist in the transcript and remain present for many later decisions. A redundant inspection is not only redundant once; its output can keep taxing every step that follows.

01model → inspect → model → search → model → edit02      → test → model → inspect again → model → compact

Transcript memory vs. state memory

This architecture exposes a critical distinction between transcript memory and state memory.

Transcript memory is the chronological record of everything that happened: I ran ls, it returned eight files, I opened file two, the compiler failed, I tried another command.

State memory is an abstracted snapshot of reality: the header parser is fixed and its tests pass; the lexer still fails on null bytes; the next action is to patch its input guard.

Human engineers do not keep every stale stack trace in active working consciousness. We extract the state update and let the raw text go. A transcript-heavy agent instead asks the model to reconstruct the current world from a growing archaeological record.

Issue #43103 describes the same visible failure pattern I experienced with Astra in Codex Desktop: premature stops, repeated compaction, code rework, and large amounts of activity without convergence. Issue #34095 gives the lost object a useful name: the execution frontier.

The execution frontier is the exact operational edge of the task:

1. What has already been completed?
2. What has been empirically verified?
3. What remains broken or unaddressed?
4. What is the single next concrete action?

If compaction preserves the mission but blurs that frontier, the model does not suffer total amnesia. It suffers something subtler: loss of convergence.

How the execution frontier collapses

The failure is a feedback loop. Exploration produces raw output. Raw output expands the context. Distractors make the current frontier harder to identify. The model runs more checks to recover certainty. Those checks create more output. Eventually compaction compresses the history, but may preserve the high-level objective more reliably than the small facts that determine the next action.

The agent remains intensely active while net forward progress approaches zero.

This is why the behavior can look like weak reasoning. The model is repeatedly solving a degraded reconstruction problem before it can resume the engineering problem the user actually gave it.

The Anthropic approach: just-in-time context and durable state

When I moved Astra into Claude Code, that failure loop largely disappeared. Anthropic's public writing makes the design philosophy legible.

In Effective context engineering for AI agents, Anthropic treats context as a finite resource with diminishing returns. Its guiding principle is to supply the smallest high-signal set of tokens that makes the desired next action likely.

Claude Code uses a hybrid strategy. CLAUDE.md supplies project-level instructions up front, while glob, grep, and shell primitives let the agent retrieve files just in time. The filesystem becomes long-term storage and indexing; the context window remains working memory.

Anthropic also describes Claude Code's compaction explicitly. The model preserves architectural decisions, unresolved bugs, and implementation details, discards redundant tool results and messages, then continues with the compressed state plus the five most recently accessed files.

This does not mean Claude Code never accumulates noise or never loops. It means the harness has an explicit policy about what should survive and what should be evicted.

For long-running work, Anthropic argues that compaction alone is insufficient. Its experimental harness externalizes progress into durable artifacts: a feature list, a progress file, clean Git commits, and validation gates. A fresh session reads those artifacts, checks the current repository state, and resumes from a named next item instead of reverse-engineering the project from a transcript.

What durable state changes

The key improvement is not a larger memory. It is a better boundary between kinds of memory.

• The conversation carries the immediate decision context.
• The filesystem carries durable notes and project constraints.
• Git carries verified checkpoints and recoverable history.
• Tests carry evidence that a state is actually complete.

When the context resets, the agent does not need the full story of how it arrived. It needs the current state, the evidence behind that state, and the next unresolved item.

The harness is part of the intelligence

It is easy to see why Codex was built this way. Stateless requests, Zero Data Retention support, and prefix caching provide real privacy and infrastructure benefits. Those benefits are not imaginary, and the architecture is not irrational.

But an infrastructure optimization can still impose a cognitive cost on the model. Even when a long prefix is cheap to reuse, the model must operate within the context assembled by the harness. If much of that context is superseded shell output, stale file reads, and failed traces, apparent intelligence falls.

This changes how I evaluate coding agents. The base model is only one component of an operating runtime. Real capability is modulated by tool schemas, retrieval strategy, eviction policy, state representation, compaction, validation, and stop conditions.

Through Codex, Astra repeatedly saturated its working context in my sessions, lost the execution frontier, and fell into self-auditing loops that burned allowance without reliably landing the task.

Through Claude Code, the same model worked with a tighter prompt footprint, stronger context hygiene, and more durable state. Its underlying reasoning became visible because the harness stopped asking it to read its own footprints before every step.

Before this experiment, when an agent failed to finish a refactor, I assumed the model had hit its reasoning ceiling. Now I first ask whether the harness suffocated it.

We should stop asking only which model is smartest. We should also ask what the harness is doing to that model's attention.