The Expensive Part Is Remembering

An autonomous agent can spend more resources re-reading accumulated context than generating new output.

The important unit is the complete sequence of model requests. A tool result becomes part of the next request; the next result becomes part of the one after that. Even discounted cached input can accumulate across a long workflow.

This article explains the accounting and control mechanisms without publishing private usage records, invoices, account arrangements, or project telemetry.

The right optimization order depends on the workload. Measure input, cache reads, cache writes, output, completed tasks, and quality before choosing a lever. A small share of token volume can still carry a large share of cost when rates differ.

The numerical worked example below is hypothetical. It demonstrates arithmetic, not observed usage, measured savings, or a promised outcome. Provider price and allowance information elsewhere is historical and must be checked before operational use.

The part nobody explains properly

If you have only ever used a coding agent from a terminal, sitting there watching it work, you have one mental model of cost: I type, it answers, that costs something. That model is wrong in a way that stops mattering the moment you automate.

In a simple stateless tool loop that resends its full history, each follow-up request carries the accumulated conversation. Twenty sequential tool rounds would require twenty-one model requests if each round uses one request and no calls are batched. Real systems may use server-side conversation state, compaction, parallel tool calls, or selective context. Measure the input actually processed rather than assuming every agent resends every byte.

Prompt caching discounts eligible repeated input. That can make a long workflow less expensive, but it does not make accumulated context free. A smaller per-token rate can still apply to a large and repeatedly transmitted prefix.

Four meters, counting four different things

The single biggest source of confusion here is that people say "cost" when four different systems are counting four different things. Two are denominated in dollars and two in time-boxed allowances. They interact, they have different reset behaviour, and hitting one tells you almost nothing about the others.

Codex expresses typical included capacity as estimated message ranges. Those are not fixed message counters: task size, model, context and tools affect consumption. The credit rate card is a separate accounting unit.

A model-specific limit and an account-wide spend ceiling require different responses. Switching models may help with the former; it cannot establish headroom under the latter. A controller should classify the limit it actually received before choosing a fallback.

Where cost can accumulate

This deliberately simplified, hypothetical workload uses round numbers to make the accounting visible. It is not derived from private session logs.

In this hypothetical example, cache reads account for 90% of token volume. That is not their cost share: each category must be multiplied by its own rate. The example makes no claim about how frequently real workloads have this distribution.

Keep the accounting baselines separate. A list-price equivalent is a calculation at specified rates; it is not proof of an invoice, a subscription credit conversion, or cash paid. Compare optimization scenarios against the same rate card and state the assumptions.

A small fresh-input share would not mean instructions are free. Stable instructions may be written into a cache and then read repeatedly at a discounted rate. Their category changes while their presence in subsequent requests remains.

Context size is a separate distribution worth measuring.

Record the median, mean, and upper percentiles of context carried per request. Then determine whether expensive context is concentrated in a small tail or spread across ordinary requests. Those shapes call for different interventions.

Model selection changes the rate applied to eligible tokens. Context management changes how many tokens the workflow carries. Both can matter, and neither should be ranked without measurement and quality checks.

What a cache read actually costs, and the cliff underneath it

For the illustrative cache arithmetic below, use the Claude Opus 5 API multipliers: a cache read costs 0.1 times base input, a five-minute write 1.25 times, and a one-hour write twice base input. These are not universal across models: Fable’s current cached-input rate has a different ratio. Verify the model and surface before using the example.

5-minute TTL
  2 uncached requests      = 1.0 + 1.0        = 2.00
  1 write + 1 read         = 1.25 + 0.1       = 1.35   -> pays off at request 2

1-hour TTL
  2 uncached requests      = 1.0 + 1.0        = 2.00
  1 write + 1 read         = 2.0 + 0.1        = 2.10   -> still behind
  3 uncached requests      = 3.00
  1 write + 2 reads        = 2.0 + 0.1 + 0.1  = 2.20   -> pays off at request 3

Then there is the part that is documented, easy to miss, and structurally nasty.

A long test suite, a wait on CI, or a scheduled resume can cross a cache lifetime. Verify the applicable caching behavior for the actual product and authentication surface. Do not assume a subscription and a metered API have identical economics.

A sleeping controller does not itself generate a model request. The cost-relevant event is the next request and whether its eligible prefix is still cached. Avoid paid keepalive traffic unless its complete cost and purpose have been evaluated.

The multiplier stack

Several design choices influence consumption. Their benefits can be worth preserving, but each should be measured as part of a complete workflow rather than judged from token counts alone.

Three of these deserve a second look, because the obvious reading of each is wrong.

If parallel and sequential executions make identical requests at identical rates with identical cache behavior, their total token cost is the same. Concurrency concentrates consumption into less elapsed time. In practice it can also change cache reuse, retries, duplicated work and routing, so compare both total cost and consumption rate rather than assuming the bill is invariant.

A fixed orientation block is carried on subsequent requests, not merely at initial load. For a hypothetical 10,000-token prefix repeated across 100 eligible cache reads, the transmitted read volume is one million tokens. This is arithmetic, not a report of project usage. The changing working context must be measured separately.

If interactive and background processes share an allowance, background work can reduce apparent interactive headroom. If they use different identities, the meters may be separate. Establish the authentication boundary before interpreting symptoms.

How Claude's meters actually work

Claude plans can impose session and weekly limits, with additional model-specific limits on eligible plans. The current plan documentation and usage display determine which apply to a particular user.

On organizational plans, allowance and extra-usage controls can apply at different scopes. Consult the plan’s current documentation and the authorized administrator’s settings to distinguish per-user windows from organization, group, or user spend ceilings.

Three distinctions belong in a controller’s limit handling.

Budget controls need a reaction time appropriate to the workflow’s consumption rate. A coarse monthly ceiling is useful as an outer boundary, but it does not replace task-level attribution, visible failures, or resumable work.

Vendor benchmarks for ordinary developer use can provide context, but they are not predictions for autonomous workflows. Agent teams, repeated context, retries, and concurrent consumers can change the workload substantially. Compare like-for-like tasks before drawing an efficiency conclusion.

How Codex's meters actually work

OpenAI publishes estimated local-message ranges per five-hour allowance window. Its documentation explicitly says these are estimates, not fixed message limits. Local and cloud work share plan usage capacity, and additional weekly limits may apply.

The ranges are wide because messages differ in model, task size, context and tool use. A long agentic task can consume more capacity than a short exchange, but the documentation does not justify assuming every automation always lands at the bottom of a range. Use the current usage dashboard and measured workload.

Codex credits have their own published consumption rate card. OpenAI states that purchase prices and discounts depend on the plan or agreement. An API price divided by a credit rate is not evidence of the cash price paid for credits, so no universal dollar conversion is used here.

The current pricing page estimates about 5–30 credits for an average GPT-5.6 Codex message, with actual usage depending on the task. Workspace pooling and administrator controls vary by plan. Sol’s listed promotional rates are scheduled through at least November 21, 2026; check the current page before budgeting.

Headless and interactive are not the same meter

The interface alone does not identify the accounting surface. Both the authentication method and the product’s documented behavior matter when interpreting headless and interactive use.

Authentication is a key accounting boundary, together with the product, plan and administrator configuration. Inspect the credentials the process actually uses rather than inferring billing from whether it has a graphical interface.

Claude: a separate programmatic credit, announced then paused

Anthropic announced that from 15 June 2026, non-interactive usage would move off the subscription allowance and onto its own monthly credit. The scope was specific: the Agent SDK in your own Python or TypeScript projects, the claude -p command in Claude Code, the Claude Code GitHub Actions integration, and third-party apps authenticating through the Agent SDK. Interactive Claude Code, the web app and Cowork were explicitly excluded and would keep drawing the plan allowance.

The following amounts belonged to the announced, subsequently paused design. They are historical proposal figures, not current available monthly credits:

Under that paused proposal, credits would have been consumed at standard API list rates, refreshed monthly without rollover, then fallen through to separately enabled usage credits or stopped when no further credits were available. Those mechanics are not the current subscription behavior.

A monthly credit amount and a subscription price are different quantities. To evaluate a proposed automation allowance, estimate the intended workload at the specified rates and state the uncertainty. Do not infer usable capacity solely from the sticker price.

Codex: distinguish plan authentication from API billing

Codex documentation supports ChatGPT plan authentication and API-key authentication across its supported clients, including programmatic use. Plan-authenticated usage follows the applicable included allowance or credit arrangement; API-key use follows Platform billing. Headless execution alone does not establish a separate allowance.

API-key authentication can be an explicit way to place programmatic work on metered billing. That is an architectural choice about accounting and control, not evidence that the same executable has a separate automatic allowance whenever it runs headlessly.

All four combinations, side by side

These are documented accounting choices, not evidence of either vendor’s private strategy. Build the controller around observed authentication, published limits and explicit configuration, with room for those rules to change.

Check the account boundary

Before comparing two sessions, establish which authorized identity and authentication mode each process used. Similar commands can draw from different accounting systems.

In a hypothetical comparison, an interactive session uses identity A while an automation worker uses identity B. One may succeed while the other is limited without there being any product-level difference between interactive and headless accounting.

Separate authorized identities can improve attribution and limit the impact of background work when the product and organization support that arrangement. Whether to do so depends on the permitted account structure and operational requirements.

Subscription authentication and API-key authentication must also be distinguished. A subscription window being exhausted is not equivalent to a metered API invoice, and a price-equivalent calculation cannot bridge that distinction by itself.

Side by side

Compare both the pricing unit and the allowance mechanism. Long context and frequent requests can matter differently across products. A workload should be evaluated on the surface that actually runs it.

Hitting the wall is the design working

The engineering tradeoff is to preserve useful capabilities while making their resource requirements visible.

Fresh contexts can make workers restartable. Deep reasoning can support difficult decisions. Retries can recover transient failures. Independent review can catch errors the first model missed. Parallelism can improve throughput, and failover can improve availability. Each benefit still needs evidence and a clear stopping rule.

A system can execute its instructions correctly and still lack adequate resource controls. The remedy is explicit attribution, limits at useful operational scopes, and visible resumable stops rather than assumptions about how long an allowance should last.

Limit-event counts alone are a weak comparison. A probe can encounter the same exhausted state repeatedly, and providers may count different units. Keep event frequency, consumed resources, and completed work separate.

A review worker that cannot run should report itself as blocked, preserve the pending review, and expose the failure to its controller. It must not record a review that never happened. Resource exhaustion can become a correctness problem if the surrounding system mistakes inactivity for a healthy state.

Seven operating principles

The blueprint

A useful blueprint begins with measurement and compares proposed changes against a common baseline. The following guidance describes questions to test, not a ranking established by private telemetry.

First inspect the context distribution. A few extreme requests and a consistently large ordinary request call for different interventions.

If a small tail dominates, investigate those requests and their causes. If cost is broadly distributed, reducing ordinary carried context may matter more. Either way, retain the evidence needed for correct work and verify task outcomes after a change.

A hypothetical cost calculation

For illustration only, assume 100 units of baseline cost: 70 from cache reads, 20 from cache writes and fresh input, and 10 from output. These are invented round numbers, not observed spending or vendor prices. Each scenario below changes one category while holding all others fixed; real workflows may change request counts, output, latency, and quality together.

Under those hypothetical assumptions, reducing output cost by 30% saves three units overall. Reducing cache-read cost by 30% saves 21 units. The lesson is to measure the baseline before choosing a lever, not to assume one category is always dominant.

Savings from multiple changes cannot simply be added when the changes affect overlapping work. Model the combined scenario explicitly, then validate it against completed tasks and retained quality.

Changing models can alter correctness and retry behavior; reducing context can remove information the task needs. Compare complete outcomes rather than treating arithmetic reductions as guaranteed improvements.

Move 0: instrument, before changing anything

A total token count does not attribute cost to individual behaviors. The first step is to connect usage with task, process, model, authentication surface, and completion evidence without publishing confidential records.

Use the telemetry the actual client supports. Claude Code documents OpenTelemetry metrics and local usage/context views; other clients expose different fields and coverage. Record model, token categories, task identity and authentication surface where available. Mark missing coverage and distinguish estimated list cost from subscription charges or invoices. No exporter is assumed to work across every provider and authentication mode.

Make attribution explicit in the operational design. Use supported account and process boundaries, record the actual accounting surface, and keep raw records private. Avoid inferring billing identity solely from the wording of a session’s first message.

Move 1: cap what every request carries

Context management is worth testing when repeated input is substantial. Adopt it with evidence that the information required for correct work still reaches the model.

Subagent isolation can keep large intermediate logs out of a parent’s context while returning the findings it needs. Anthropic’s published research system describes condensed summaries from subagents. That is a design example; its results do not establish savings for another workflow.

Claude Code subagents support explicit model configuration and isolated contexts. Nested delegation is controlled by the supported depth setting and version. A summary can keep large intermediate logs out of the coordinator’s context, but tool results and completion reports still need deliberate boundaries. Preserve the workflow’s model-quality policy instead of automatically downgrading every exploration task.

Anthropic reports two separate evaluations of context management. On an internal agentic-search evaluation, context editing improved performance by 29%, or 39% when combined with memory. Separately, a 100-turn web-search evaluation used 84% fewer tokens with context editing. Those are different measurements on vendor workloads, not a combined guarantee for another agent.

Tool output preprocessing can reduce irrelevant material before it enters context. Preserve full diagnostics in a local artifact and return the evidence needed for the task; filtering that hides the cause of a failure is not an improvement.

Just-in-time retrieval loads specialized material when it becomes relevant instead of placing every workflow in the initial prompt. Keep stable governing instructions available and verify that discovery reliably finds the full sources the task requires.

Current Claude Code supports deferred MCP tool discovery, with behavior depending on the configured provider and client version. CLI and MCP integrations both have context and operational costs. Compare returned output, discovery, authentication, permissions and task reliability; neither interface is automatically pure overhead.

Move 2: tier the models on input, not on output

Model routing should be evaluated across reading, reasoning, output, and verification. A cheaper input rate alone does not establish a cheaper successful task if errors or retries increase.

The difficult part of model routing is deciding which tasks can retain the required quality on a different model. Status reconciliation and log analysis can still require judgment. Use representative evaluations before changing an established quality policy.

The advisor-executor pattern separates execution from higher-level review or planning. It is an architecture to evaluate, not a measured saving claimed here. Preserve the strongest-model requirements of the workflow wherever they apply.

Move 3: give the loop a budget it can feel

A monthly ceiling is an outer boundary. Task-level accounting, visible pauses, and resumable state make resource control meaningful at the scale where work happens.

The Messages API task-budget beta accepts output_config.task_budget with a minimum total of 20,000 tokens and the task-budgets-2026-03-13 header. It is advisory guidance, not an enforced spending limit, and the model can exceed it. Its task accounting counts new work differently from retransmitted billable input. A graceful finish is an intention to evaluate, not a guarantee.

Managed Agents separately supports an enforced session list-cost budget. The service stops issuing new model requests when the tracked cost reaches the cap and leaves the session resumable. Enforcement happens between requests: the request that crosses the cap finishes, so final cost can exceed the threshold. This is a Managed Agents control, not a universal CLI or subscription dollar limit.

Retry only when the next attempt has a plausible path to progress. Detect unchanged blockers, preserve the state, and escalate according to the workflow’s rules. Repeatedly rebuilding the same context cannot resolve a missing external precondition.

Move 4: schedule against the meters

Scheduling affects rolling allowances and cache reuse. It can also change latency and completion time, so evaluate it against the workflow’s requirements rather than assuming it is free.

Spreading work over allowance windows may reduce short-window pressure when longer-term capacity remains. It does not establish a cash saving. The controller should use the actual limits it can observe and stop visibly when work cannot proceed.

For cache-sensitive work, understand whether normal pauses exceed the applicable lifetime. Group related work when the task permits, but do not add paid traffic merely to keep a cache warm without measuring the total effect.

For independent work that can wait, consider the provider’s supported batch API and current discount. Confirm its completion window, model support and failure handling before choosing it for a scheduled verification or documentation job. An asynchronous request is useful only when its timing still fits the workflow.

Avoid choosing the fix before the measurement

Two tempting shortcuts illustrate why attribution matters.

A high cache hit rate does not mean cache reads are the cheapest category in total. Conversely, a small number of expensive cache writes can matter. Multiply each token category by the relevant rate before prioritizing either.

Shortening instructions may reduce repeated input, but removing required policy or verification can damage outcomes. Keep stable instruction prefixes, retrieve specialized procedures on demand, and measure the full workflow after a change.

An implementation order to evaluate

Instrument first. Then inspect which tool outputs and retained context dominate ordinary requests, test scoped retrieval and summaries, and preserve full diagnostics. Evaluate any model-routing change against quality requirements. Add task-level controls and scheduling with visible failure handling. The order should follow evidence from the actual workflow.

The test is whether complete, accepted work uses resources more predictably without losing quality or required review. No private billing records or measured savings are published here, and the hypothetical calculations above should not be mistaken for results.