I Was Collecting Token-Saving Tips, Then I Opened My Logs and Changed the Order#

2026-10-25

On a wooden desk under a lamp, a small robot strains to push an endless paper scroll, a person’s hand examines the scroll through a magnifying glass, and a small folded note sits beside the robot

Plenty of tips, but where to start?#

Token consumption is one of the most common topics among people who use coding agents like Claude Code and Codex. As people hit their subscription limits early or see API bills grow beyond expectations, articles on how to save tokens keep piling up. I use both tools every day, so I went looking for these articles too.

The tips that show up across most of them look roughly like this:

Clear the conversation with /clear between unrelated tasks
Keep instruction files such as CLAUDE.md / AGENTS.md short
Use a cheaper model and a lower effort (how much reasoning the model spends) for routine work
Turn off MCP (Model Context Protocol, the standard for connecting external tools to an agent) servers you don’t use
Filter long output, such as test logs, before it reaches the agent

None of this is wrong. The question was where to start. Many tips came with numbers like “60–90% savings” or “85% savings,” but most of those were measurements from third-party blogs or tool authors, and I had no way of knowing whether they would hold for my usage pattern. So before applying anything, I aggregated the session logs that both tools keep locally.

Here is the conclusion up front. Most of my usage came from a handful of very long sessions. Some popular tips did almost nothing for me, and others were effective but came with conditions. This essay records that diagnosis and the plan I made from it. I have not applied the changes yet, so the effects are estimates based on the logs.

Cost is “context size × number of calls”#

An agent resends the entire conversation with every request: the system prompt, instruction files, everything said so far, and every tool result. Each file the agent reads and each command it runs adds another request, so cost grows roughly as “context size at that point × number of calls.”

Prompt caching (reusing the already-processed beginning of a request) eases this considerably. Tokens read from the cache are billed at a fraction of the base input price. They are not free, though, so cache reads grow along with the conversation. I covered what caching reuses inside the model, and why hit rate itself is not the goal, in an earlier essay. For this one, the equation above is all you need.

What the logs showed#

Claude Code keeps session records under ~/.claude/projects/, and Codex keeps them under ~/.codex/sessions/, both as JSONL (one JSON object per line). Each response records the tokens its request used, split into input, cache reads, cache writes, and output, so a short script can aggregate them. For Claude Code, something like this is enough to get started:

import collections, glob, json, os

total = collections.Counter()
for path in glob.glob(os.path.expanduser("~/.claude/projects/*/*.jsonl")):
    for line in open(path):
        try:
            record = json.loads(line)
        except json.JSONDecodeError:
            continue
        if record.get("type") != "assistant":
            continue
        usage = (record.get("message") or {}).get("usage") or {}
        for key in ("cache_read_input_tokens", "cache_creation_input_tokens", "output_tokens"):
            total[key] += usage.get(key) or 0

print(total)

In Codex, token_count events carry the session’s cumulative usage, so reading the last one in each session is enough. I looked at two repositories: this blog’s repository (mostly writing) and a work repository where most of the activity is coding. Three things stood out.

First, a handful of long sessions accounted for most of the usage. In the blog repository, one of the last 24 sessions accounted for about a third of all cache reads. That session made more than 300 API calls, and its context grew past 600K tokens. Codex was the same. Most of my Codex usage came from the work repository, where a single session accounted for more than half of all input tokens and made over 1,000 calls.

Second, conversations in the work repository were always large. In Claude Code, the median context per call was 340K tokens, the top 10% exceeded 640K, and the maximum reached 900K. With default settings, models with a 1M-token context window don’t auto-compact until the conversation reaches about 967K tokens. In effect, I was letting conversations grow almost that far.

Third, the cost breakdown differed by repository. Since each token type has a different price, I converted usage to Opus 5.5 API list prices to compare shares. I use a subscription, so this doesn’t match any actual bill; it’s a way to see where my plan limits go, in relative terms. Cache writes are priced at the one-hour cache rate, which applies to the main conversation on a subscription.

Repository	Cache reads	Cache writes	Output (incl. reasoning)
Blog (writing)	~21%	~50%	~29%
Work (coding)	~50%	~31%	~19%

In the work repository, conversations were large, so cache reads made up half. The blog repository had relatively shorter conversations but a larger share of cache writes, most likely because a lot of new content kept coming in. That repository saw more than 80 browser screenshots and image file reads, and I often came back to a large session after stepping away. The cache expires after a period of inactivity, and the first request after it expires writes the entire conversation to the cache again.

Checking the tips against my logs#

Lowering effort barely moves Codex usage#

Many articles recommend lowering reasoning effort for routine work, sometimes with a figure like 40–60% savings. In my Codex logs, though, output and reasoning tokens combined came to less than 0.5% of input tokens. Most of the input was conversation read from the cache. Even accounting for output being priced tens of times higher than cached input, I estimate that halving reasoning tokens would save a single-digit percentage of the total. Effort matters for work with a large output share, and my Codex usage isn’t that.

Switching to Sonnet halves the cost, on the condition of quality#

The math for switching models is simple. On the official price list, Sonnet 5.5 costs exactly half of Opus 5.5 on every line: base input, cache writes, cache reads, and output. Both models price cache reads at 0.05× the base input price, so the 50% ratio holds even in the work repository, where long conversations make cache reads the largest share.

Model (per 1M tokens, as of 2026-10)	Base input	Cache write (1 hour)	Cache read	Output
Opus 5.5	$4	$8	$0.20	$20
Sonnet 5.5	$2	$4	$0.10	$10

If the same work gets done with the same number of tokens, switching to Sonnet 5.5 cuts the cost in half. The catch is that “if.” If the smaller model takes more turns, or if Opus has to fix its mistakes, the savings shrink. Switching models has a large effect, but it also moves another variable: quality.

The “7×” for agent teams came with conditions#

Claude Code has an experimental feature called agent teams, in which several Claude sessions collaborate as a team. The official documentation says that teammates running in plan mode (a mode that plans before executing) use about 7× more tokens than a standard session. I had this feature flag turned on, but the logs showed it wasn’t what drove my usage. Of 324 subagent runs in the work repository, only 2 were team-related. The 7× applies when a team actually forms and runs in plan mode; leaving the flag on doesn’t increase usage by itself.

I still decided to turn the flag off. According to the documentation, while the flag is on, a subagent that Claude launches with a name starts as a teammate, even if you never asked for one. Here is how the two differ:

Aspect	Subagent	Teammate
Lifetime	Returns a summary and exits after one task	Stays alive until asked to shut down
Communication	Reports results only to the main agent	Messages other teammates directly; shared task list
Tokens	Adds one summary to the main conversation	Resends its whole conversation every time it receives a message

Most of my work is delegation with a clear scope, so subagents are enough. I’ll turn teams on only when a task needs several perspectives to challenge each other before an answer emerges.

Browser verification was piling up in the main conversation#

In the work repository, the agent often drives a logged-in browser to check screens. The logs showed that all 659 browser tool calls happened in the main conversation, with none in subagents. More than 160 images entered the main conversation, and once an image is in, it rides along with every request until the session ends.

When I checked my harness (the rules and tool setup I give the agent), nothing told it to hand browser work to a subagent. I knew the tip “delegate output-heavy work to subagents,” but I had never checked whether my harness actually worked that way.

The order I settled on#

I ordered the changes as “low quality risk and high impact first.”

1. Compact a finished session on the spot#

The common tip is to clear the conversation with /clear when a task is done. I work a little differently. I leave finished sessions as they are and start new work in a new session, because tasks I considered done often need follow-up work. A session that just sits open sends no requests and uses no tokens, and in terms of cost, /clear and a new session are the same.

The remaining problem was returning to that session hours later. For a 600K-token session at Opus 5.5 list prices, the difference is large:

/compact right after finishing, while the cache is warm: about $0.12 in cache reads, plus the summary output
Resuming hours later without compacting: about $4.80 for the first request to write all 600K tokens back to the cache
Running /compact when resuming hours later: about $2.40 for the summary request to read the whole conversation uncached, plus the summary output

So I set this rule: when I finish a task, I run /compact on the spot, keeping only what follow-up work needs (changed files, decisions, open issues), and leave the session as it is. It fits well with the habit I described in Context Switching in the Age of AI Agents of leaving a resume note before stepping away.

2. Lower the auto-compaction threshold step by step#

The autoCompactWindow setting in Claude Code sets the context size at which auto-compaction happens (100K–1M tokens). The question was what to set it to. The first number that comes to mind is around 200K, the default before 1M-token models, but the official documentation doesn’t recommend a value. I couldn’t find any consensus on a specific number for 1M-token models online either; the prevailing advice is to compact ahead of time at natural breaks in your work.

So I ran a simulation on my logs. I kept the actual growth of context in each session and assumed that crossing the threshold shrinks it to a summary of about 25K tokens, then recalculated the total context volume.

Threshold	Work: total context	Work: compactions per session	Blog: total context
700K	−13%	~0.6	No change
500K	−27%	~2.4	−10%
400K	−41%	~3.1	−10%
300K	−50%	~5.7	−15%
200K	−62%	~11.9	−26%

These estimates are optimistic. They leave out the cost of re-reading files after compaction, the cost of the compaction requests themselves, and rework caused by lost details.

My first plan was to start at 700K and lower it gradually. The table, however, showed that only 7% of calls exceed 700K, so it would do little and teach me little as a first step. Instead, I’ll start at 500K, use it for one to two weeks, and if I don’t lose context after compaction, lower it to 400K and then 300K. I’ll also write what to preserve during compaction in a # Compact instructions section of the instruction file. In Codex, model_auto_compact_token_limit plays the same role.

3. Hand output-heavy execution work to subagents#

Work where only the result matters but the process produces a lot of output, such as browser verification, running tests and builds, or analyzing logs, goes to subagents. A subagent works in its own context and returns only a summary, so the main conversation doesn’t grow. Setting the model to Sonnet in the agent definition file also halves the price. Since these tasks require little judgment, the quality risk is low. Subagents start from an empty context, though, so handing them very short tasks actually costs more.

4. Models and effort come next, through a trial#

The hardest question was whether to hand coding itself to Sonnet. The price is half, but I tend to set direction through conversation, so handing coding to a subagent adds the cost of passing on context and reviewing the result. An alternative is Claude Code’s advisor feature: Sonnet handles routine work and consults Opus only at decision points such as planning, recurring errors, and confirming completion. Each consultation has Opus read the whole conversation uncached, though, so it only pays off once conversations are kept short.

So I’ll trial both approaches in one repository for one to two weeks and decide after comparing them. As for effort, I’ll leave it as is in Codex, where output makes up a small share, and in Claude Code I’ll start by reverting the writing repository to medium, the Opus 5.5 default. I had pinned effort at high and only now learned that the Opus 5.5 default is medium.

5. What I decided not to do#

Several articles recommended external tools, such as wrappers that shrink command output or MCP servers for querying code structure, but I put them on hold. Most reported effects were single measurements or numbers from the tools’ authors, and I wanted to see how far the changes above move the baseline first. I also left out settings with conflicting reports across articles, such as forcing a larger Codex context window.

I also found one reason it’s hard to follow blog posts as written. According to the official documentation, Codex profiles (named bundles of settings such as model and effort) have been read from ~/.codex/<name>.config.toml files since 0.134.0, but many articles still show the old syntax.

Closing#

What I got from this research wasn’t a new tip. There were already plenty of tips. What I needed were numbers to judge how much each tip would do for my usage pattern, and those numbers were already sitting in my local logs. “Lower the effort” did almost nothing in Codex, and “clear the conversation” turned into “compact it where you finish” for the way I work.

The other lesson is to check the numbers and configuration examples attached to tips against the official documentation before copying them. Most savings figures were single measurements with conditions attached, and even official numbers, like the 7× for agent teams, mean something different once you drop the conditions. In some cases, like Codex profiles, the syntax itself had changed.

This is still the planning stage. I’ve kept these numbers as a baseline, and about two weeks after applying the changes, I’ll measure again the same way and write a follow-up.

Appendix: Configuration examples#

Claude Code user settings (~/.claude/settings.json), with only the auto-compaction threshold and the team flag:

{
  "autoCompactWindow": 500000,
  "env": {
    "CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS": "0"
  }
}

What to keep during compaction goes in the project’s CLAUDE.md:

# Compact instructions

When compacting, preserve the paths of files being worked on, decisions made, remaining to-dos, and the branch and PR number.

A subagent for browser verification is defined under .claude/agents/. Replace the tool names to match the browser MCP server you have connected.

---
name: browser-verifier
description: Handles browser interaction and screen verification. Delegate to this agent first whenever a browser check is needed.
model: sonnet
effort: medium
tools: mcp__<browser-server>__navigate_page, mcp__<browser-server>__take_snapshot, mcp__<browser-server>__take_screenshot
---

Report each check as pass / fail with the evidence, summarized as text.
Take a screenshot only when a text snapshot isn't enough to decide.

Codex settings (~/.codex/config.toml):

model_auto_compact_token_limit = 200000
tool_output_token_limit = 10000

[mcp_servers.<server-name>]
enabled_tools = ["<tool-a>", "<tool-b>"]