Article 3 · From practice

Same model, fewer tokens: what heavy agent users change first

Developers who run coding agents all day hit their usage limits every week. They pay for waste daily, so they find it early.

Between June and October 2026 we read about 27,000 messages in a private community where such developers compare notes on subscriptions and the API. We set aside every shortcut that changes the model or the provider: cheaper resellers, smaller models, switching providers, playing subscription prices against API prices. Seven habits remained. Each one keeps the model you chose.

They are field reports, and we have not measured them yet. For each habit you get the mechanism behind it and a test to run on your own tasks.

1. Switch off the swarm unless the work truly splits

The most repeated lesson of the period: spawned subagents cost more than they look.

A subagent starts with a slice of the context and a compressed brief. It reads the code, then returns a summary. The main model pays to read that summary and reasons on second-hand evidence. You pay for every subagent’s reading plus the expensive model’s work on a weaker input. If the result is wrong, you pay again for the correction.

Several members reported the same fix: one instruction at the start of the task — do the work yourself, do not spawn agents. One of them saw quota use drop from about 6% to about 2% for twenty minutes of the same kind of work, with output they rated higher. Others confirmed the direction on other models.

“Ultra” and swarm modes add parallel sessions. Members described tasks that stretched from minutes to hours, with the context compacting every few messages.

Measure a swarm like any added expense. If spawning agents raises the cost per accepted task while the accepted results stay the same, the extra agents bought nothing.

Swarms still have a place. Read-only review and a full scan of a very large repository split cleanly into independent parts. When work runs in parallel, separate sessions — each with one task and its own working copy — avoided resending a growing shared conversation.

In Codex, agents.max_concurrent_threads_per_session limits how many spawned threads can run at once.

2. Save high reasoning effort for the plan

A common setup by October: high effort for planning, medium for implementation, low for read-only scouting. Codex has a separate key for this, plan_mode_reasoning_effort, so the plan can use a higher level than the work that follows.

The reasoning given was consistent. Higher levels kept checking and re-checking after the task was done. Medium tended to stop when the work was finished.

Treat the switch as a quality experiment. Members also reported the opposite: a lower level that left simple work unfinished until they raised it again. A cheaper call that needs a second attempt can cost more. Fix the acceptance checks first, then compare levels on the same tasks.

3. Pay for speed only when someone is waiting

Fast tiers charge for speed. On OpenAI’s pricing page, checked on 14 October 2026, the Fast rates listed for GPT-5.6 Sol and GPT-6.1 Sol are double the Standard rates for the same model.

On subscriptions the effect showed up as quota. One member gave the same read-only question to the same model twice. The ultrafast run finished in five minutes and used more than ten times the quota of the normal run, which took eighteen.

If nobody is waiting for the answer, the normal tier — or a batch API, where the task allows it — keeps the model and lowers the bill.

4. Keep threads short and related work together

Each new turn sends the conversation so far. A cache can cut the price of that repeated input; the volume stays the same. One member analysed 300 of their own tasks and found spend per task rising steeply with the number of messages in the thread.

Two habits came out of this:

• Run a chain of related tasks in one session, so the agent does not relearn the project for each one. Start a fresh session for unrelated work.
• Pick the context window on purpose. Members who compared a one-million-token variant with a 256k variant of the same model reported more tokens for the larger window and no better results. Codex exposes the window as model_context_window.

Watch for loops. One member left an agent near its context limit; it alternated between compacting and repeating the same operation until the session’s allowance ran out.

5. Make the cache visible

Cached input is where long agent sessions can save most. Anthropic’s documentation lists cache reads at 0.1 times the base input price, with exceptions for some models in its pricing table. The default cache lasts five minutes and is refreshed each time it is used. A one-hour cache costs twice the base input price to write. Every response reports cache_read_input_tokens and cache_creation_input_tokens.

Members pointed out that most agent tools record cache usage in their session logs. An agent can compute the hit rate per day from those files. A falling hit rate points to a changed prefix, reordered instructions or pauses longer than the cache lifetime. Our first article covers keeping a prefix stable; the second shows how far caching can move a bill.

6. Trim what loads on every call

Some input is sent with every request whether the task needs it or not.

• Built-in instructions. Codex lets you replace them with your own file through model_instructions_file. One member who removed them reported much faster responses. Test before you rely on it: built-in instructions also carry behaviour you may need.
• Project instructions. Codex reads AGENTS.md up to project_doc_max_bytes. A file longer than the limit is cut, and the instructions at the end are not loaded. Know the limit, or keep the file within it.
• Documentation. One member’s rule: a fixed core set for every task, topic documents only when the task touches them.
• Tools. Load tool definitions when the task needs them; our first article covers the trade-off with cache reuse.
• Memory. Features that pull fragments of earlier chats into context can add irrelevant text you pay for. Check what they inject.

Output-compression utilities got mixed reports. Several members saw agents run commands a second time without the compressor, which erased the saving. Asking the model to write more compactly worked better: one member found it kept every detail at about half the length.

7. Feed reviewers and loops less

Two smaller habits saved repeated work:

• Give a reviewer the task and the code. The main agent’s intermediate notes, rationales and summaries cost tokens and steer the review towards the agent’s own conclusions.
• Stop a one-error-at-a-time loop. One member’s agent spent hundreds of millions of tokens deploying, failing on the next check, fixing one line and deploying again. Reading the whole script once and fixing every check in one pass ended it.

Guard the bill while you experiment

• Pin the model identifier in your product’s configuration. One member’s coding agent changed it to a more expensive model while testing an app.
• Check automatic top-up rules before long runs. Another member found a much larger charge than they expected an hour after enabling credits.
• Repeat runs. The same prompt on the same code used very different shares of the quota on different days.

Seven tests for the same model

Change one thing at a time. Count failed attempts and retries in the cost. Keep a change only if accepted results stay the same and the bill goes down.

Start with the test that sits on the largest share of your bill. Describe one workload and your acceptance criteria in the form on our home page; it turns them into a test plan you can send to the lab.

Plan an efficiency test →