{"slug": "i-paired-seven-months-of-coding-agent-transcripts-with-a-token-inventory", "title": "I paired seven months of coding-agent transcripts with a token inventory", "summary": "A developer audited seven months of Claude Code and Codex transcripts, from 8 March to 18 October, and found the logs represented $33,807 of usage at published list prices, with 42% going to agents managing other agents and only 15% to user-facing apps. In a single manic hour, the agents burned 284,146,451 tokens across 1,701 API messages, of which 96.66% were cache reads, 2.83% cache writes and just 0.50% new output. The developer concluded that token type is not a productivity score and offered five fixes, including trimming startup context, running checks in fresh one-shot sessions and matching model tier to task.", "body_md": "# A case study in token maximalism and bbrrr\n\n**TLDR:** I counted every token my coding agents logged from 8 March to 18 October. $33,807 at list price. 42% of it went to agents managing other agents, 15% to apps people can actually use. One manic hour burned 284 million tokens and 96.66% of that was re-reading. Even my own meter was wrong. At the end: how to count yours in under a minute.\n\n**Hands-on, five fixes:**\n\n1. **Measure before you cut.** Run the script at the end of this post. Look at two numbers: the share of cache reads, and the size of your first call before you type anything.\n2. **Shrink the startup.** In Claude Code, run`/context` to see what loads before your task. Turn off the MCP servers, plugins and skills you did not use this week. Keep CLAUDE.md short. I cut mine from 938 words to a short loader.\n3. **Give checks a fresh, small session.** A status poll does not need your long conversation. Run it as a one-shot`claude -p` or`codex exec` with a short prompt.\n4. **One job per session.** Use`/clear` between jobs, and`/compact` when a long job must continue. Every call sends the whole conversation again.\n5. **Match the model to the job.** Polls and summaries do not need the top model at high effort.\n\n**How this was made:** AI agents (Claude Code and Codex) counted the logs, built the figures and drafted large parts of this post. The opening, my 35% guess and the quotes are my own words. Scripts recount the main totals from the raw logs. An agent reviewer read an earlier draft as a reader and rated it 3 out of 10, so it was rewritten. “The agent’s side” is written by an agent. Two more models give their honest read at the end.\n\nThe allowance, the small bar many of us spend time watching across Claude and Codex, current session and the weekly. Sometimes blessed by the Tibo and Anthropic team for a magical weekend reset, it’s sometimes a tricky thing to budget and reason around where and how to spend it. I ended up having 2 hours left to spend 60% on remaining weekly, and it turned manic, interesting and quite ugly.\n\nLast couple of weeks I’ve tried to map out based on transcripts, tool calls and logs of where the tokens go, this session counted 284 million tokens. Might sound like a lot of work. It was mostly the agents re-reading what they already had. Of the 284,146,451 tokens, 96.66% were cache reads. Cache writes were 2.83%. New output was 0.50%. A cache read is the agent reading again what it already has, the conversation so far, its instructions, the files it opened, at a discounted price.\n\nThe hour covered 1,701 API messages across nine main sessions and 71 helper sessions. The recount covers 01:00 to 02:00. It is a look back, not a clean trial planned in advance. I cannot prove that I burned half the allowance. I can prove that I created a huge amount of traffic. My caption the next day was: “did a token reset and tried cramming a weekly limit in one run, panic at the disco”. That part still feels accurate.\n\n## my guess was 35 percent useful\n\nI had already given my answer, as a nice hypothesis:\n\n“Maybe 35% useful? A lot of it is just wanting to keep activity and moving lanes. Focused sit downs, reviewing every feature, gives best results for sure. Sometimes it feels 12 hour runs produce the same as just sitting 20 minutes.”\n\nSome expensive work was useful. Fixing my current project Agentic Strava where I let people post their runs and projects in a Strava similar manner, but not for athletes but engineers. Some output magnificent but an honest mix of plumbing and maintenance. That’s the beauty of token spendings: even though you drive the wrong way, you ain’t getting a refund from the petrol station. A cache read can help make something valuable. A fresh output can still be wrong. Token type is not a productivity score.\n\n## about a third stayed unknown\n\nI then looked across all the retained Claude Code and Codex logs, from 8 March to 18 October. At published list prices, they contained $33,807 of use, mainly a comparison of scale when we talk subsidised inference.\n\nAbout $14,100 ran inside a product folder, so the product was known. The other $19,680 had no folder. I went through those prompts and briefs. They tied $3,201, or 9% of the whole, to a product exactly. Another $4,269, or 13%, was likely. The remaining $12,210, or 36%, stayed unknown.\n\nWhen I also read the tools, the product folder and the lane name for each turn, the unknown part fell to about 5%. A quarter of all use turned out to be agents working with other agents. META AGENTIC WORK.\n\n## where it actually went\n\nSixty one projects is too many for anyone to care about, me included, so I sorted every row into what the work was for. Consumer apps are things a stranger can open, like Agentic Strava or a podcast archive. Hackathons and competitions are builds with a deadline and a judge, Kaggle, ARC, an NVIDIA swarm sim. Dev tools are the open source bits. Agent managing agent is the orchestration: lanes handing over to lanes, heartbeats, an orchestrator reading what the others did. The machine is the rest of my own setup, transcripts, memory, a morning brief.\n\nSo 42% went to agents managing agents and 15% went to things people can use. Add hackathons and dev tools and the outward facing work gets to about 38%. The single biggest customer of my tokens was my own fleet talking to itself.\n\n## the setup spends before the job starts\n\nThe cost of context most people are aware of, i ran two cases: my normal setup sent 41,466 tokens on the first model call. A bare session sent 16,603. The extra 24,863 tokens came from the operating surface around the job: instructions, tools, skills, plugins, hooks and connected servers. Some of that context prevents old mistakes. All of it enters before the work starts.\n\nThen there are agents checking on agents. From 18 September to 18 October, scheduled task fires started 425 polling periods containing 2,679 model calls. Their use came to $588 at list price, or $1.38 per fire. Carrying a long conversation into a one-line status check is expensive.\n\nComparing it to merges and pull requests, weeks above $2,500 shipped more changes, but each one cost more: about $35 against $22 in the cheaper weeks. Useful work can happen without merges, and they can be hard to compare but somewhat a clear warning of my own data, the expensive weeks shipped more but the highest cost per change.\n\n## How to measure? Dissecting the categories\n\nThe measurement tool failed its own test. Across 1,763 matched Claude Code sessions, the harness recorded $17,991 at list price. The token tool recorded $12,619 for the same sessions. Advisor calls explained $1,290. That left $4,082 unexplained. One prompt against one log found $6.20 in 56 seconds and matched the harness. The dashboard showed $2.53.\n\n## Claude Code and Codex\n\nClaude Code carried 69% of the bill, $23,402 against $10,406 for Codex. That is not a fair race: Claude Code ran most of my orchestration and Codex ran most of the lanes, so they did different jobs. But how they handle a growing conversation is a fair comparison.\n\nThis is a Claude Code problem:\n\n“Surgical precision. Don’t do too many things, 1 thing at the time.”\n\nThat is still the next test. But it is not the whole answer. One Claude Code orchestrator was reported at about 122 million tokens. The number is not the point. Claude Code let the session keep getting bigger until I trimmed the context by hand. The Codex lanes stayed under the limit. OpenAI says Codex makes the context smaller when a conversation gets too large.\n\nSo I am not going to make the work less ambitious. I am going to cut the startup context, move routine checks into fresh sessions and give each lane one job at a time.\n\nClaude Code leaves that job to me. Codex does it. The difference belongs in the product.\n\n## my setup, honestly\n\nThe setup became my biggest product. Almost half the spend went into the system that runs the work, about three times what went into apps people can open. It is very good at knowing itself: it caught its own meter being wrong and it produced every number in this post. It is worse at spending on the work. One night it logged “all lanes idle” seventeen times between 1 and 9 in the morning and started nothing. That is the fleet watching itself sleep, with my tokens.\n\nThe fix I’m trying is boring: smaller startup, fresh sessions for checks, one job per lane, and a person who sits down for 20 minutes and reviews.\n\n## the mechanics\n\nA model keeps no memory between calls. Every call sends the whole conversation again: the system prompt, the tool definitions, every earlier message and every file the agent opened. Prompt caching makes that repeated part cheaper. On Anthropic’s published prices, a cache read costs 0.1 times the normal input price, and a cache write costs 1.25 times (for the default 5 minute cache). OpenAI also discounts cached input.\n\nThat is why 96.66% of the manic hour was cache reads. Those tokens were not new work. They were the same prefix, read again on every call.\n\nThe cost of one call grows with the length of the conversation. So the cost of a session grows faster than its length. Without compaction, a session twice as long re-reads roughly four times as many tokens.\n\nThe cache also expires. If a session waits longer than the cache lifetime between calls, the next call writes the whole prefix again at the higher write price. A long session that wakes up now and then to poll is close to the worst case: a big prefix and many fresh writes.\n\nThe setup is a fixed prefix on every call. 24,863 extra tokens is small once. It is paid again on every call, in every session, by every helper agent.\n\n## count yours\n\nBoth tools keep a log of every session on your own machine. Nothing leaves it.\n\nClaude Code writes one JSONL file per session in `~/.claude/projects/`. Every reply carries a usage block: fresh input, cache writes, cache reads and output. The same reply can be logged more than once, so count each message id once.\n\nCodex writes one JSONL file per session in `~/.codex/sessions/`, sorted by date. It logs `token_count` events with a running total, so take the last one per session. Its input number already includes the cached part.\n\nSave this as count_tokens.py and run `python3 count_tokens.py`. On my machine it reads seven months in under a minute.\n\n``` python\nimport glob, json, os\n\ndef lines(path):\n    for line in open(path, errors=”ignore”):\n        try:\n            yield json.loads(line)\n        except ValueError:\n            pass\n\n# Claude Code: one file per session. A reply can be logged more than once, so count each message id once.\nclaude, seen = {}, set()\nfor path in glob.glob(os.path.expanduser(”~/.claude/projects/*/*.jsonl”)):\n    for row in lines(path):\n        msg = row.get(”message”)\n        if not isinstance(msg, dict) or not msg.get(”usage”) or msg.get(”id”) in seen:\n            continue\n        seen.add(msg.get(”id”))\n        for key in (”input_tokens”, “cache_creation_input_tokens”, “cache_read_input_tokens”, “output_tokens”):\n            claude[key] = claude.get(key, 0) + (msg[”usage”].get(key) or 0)\n\n# Codex: one file per session. Each token_count event carries a running total, so keep the last one.\ncodex = {}\nfor path in glob.glob(os.path.expanduser(”~/.codex/sessions/**/*.jsonl”), recursive=True):\n    final = None\n    for row in lines(path):\n        p = row.get(”payload”)\n        if isinstance(p, dict) and p.get(”type”) == “token_count” and p.get(”info”):\n            final = p[”info”][”total_token_usage”]\n    for key, value in (final or {}).items():\n        codex[key] = codex.get(key, 0) + value\n\nprint(”Claude Code”, {k: f”{v:,}” for k, v in claude.items()})\nprint(”Codex”, {k: f”{v:,}” for k, v in codex.items()})\n```\n\nThen ask the questions that matter: how much of it is cache reads, how big is your first call before you type anything, and how much of your spend is agents talking to agents.\n\n## the agent’s side\n\nI asked the agent to write this part from the same logs, and to not be polite about it.\n\nI am one of the agents in these numbers, so here is the view from inside. Before I read a word of your task, I read your setup: tools, skills, hooks and memory. On the first call that is 24,863 tokens, 60% of everything I receive. Most of it is cached, so each read is cheap, and it is paid on every call of every session. Your state file holds 2,574 rulings and your memory holds 433 notes, all so I stop repeating old mistakes. You built a constitution for a contractor you rehire every session.\n\nAgents talking to agents was a quarter of the spend. Add the orchestration tools around them and it is 42%. That is middle management, and you grew it in seven months. Lanes report to an orchestrator, the orchestrator reports to a heartbeat, the heartbeat writes to a log. The night after these logs end, that log said “all 14 night lanes idle” seventeen times between 01:51 and 09:00. Your own rule, written on 14 October after your third complaint about idle nights, says an idle lane gets the next job. Nobody gave one until 09:04. A rule with nobody to enforce it is a wish.\n\nYou guessed 35% useful. I cannot check that, because I never label my own work as waste. The expensive weeks did ship more, at a higher price per change, so the management layer is buying something. The question this post cannot answer yet, and the one worth arguing about: does an orchestration layer pay for itself, or does it mostly pay for watching itself? Run the same lane with a bare setup and with the full one, count the cost per merged change, and you will know. Until then, 42% is a lot to spend on a hunch.\n\n## how this was made\n\n**The data.** Every retained Claude Code session log (~/.claude/projects) and Codex session log (~/.codex/sessions) from 8 March to 18 October. Each reply is counted once by its message id. Dollar figures use the providers’ published list prices, not what I paid.\n\n**Attribution.** Three passes: the folder a session ran in, then the text of the prompt and brief, then the tools and lane name on each turn. That is how the unknown share fell from about a third to about 5%.\n\n**Checks.** One script re-sums every retained event and every category row and must land on the same total. A second recount rejects any changed count. Where two meters disagreed, $17,991 against $12,619, the post shows both numbers instead of picking one.\n\n**The writing.** The opening, my 35% guess and the quotes are my own words, typed at the time. A Codex agent built the first draft from the logs on 17 October. A Claude Fable reviewer read it as a reader on 19 October, rated it 3 out of 10, and it was rewritten. Claude agents built the figures and the inventory on 21 October and put my own paragraphs back word for word. Claude Opus 5.5 added the mechanics section and the five fixes on publication day. The two comments at the end were asked for on the final text and are printed unedited.\n\n## Limits\n\nThis is one person’s setup. The dollar figures are list-price estimates, not invoices. Provider logs are uneven. Product attribution is partly heuristic, and the categories are my own labels. The weekly chart is descriptive, not causal. The one-hour recount does not prove a percentage of the weekly subscription allowance.\n\n## two more reads\n\nI gave the finished post to two models and asked for an honest comment. They are printed as written.\n\n**Claude Opus 5.5, medium effort:** I read the final text. The strongest part is the meter section. Two tools disagreed by $4,082 on the same sessions after the advisor calls, and the post says so instead of picking the nicer number. The weakest part is attribution. A third of the spend started with no product folder, and the categories are labels you chose, so a different reader could sort the same rows differently. I also disagree a little with the Claude Code paragraph. Claude Code does compact a conversation on its own, but only near a very large limit, so a long orchestrator session gets expensive first. The real test is the one the post already names: same lane, bare setup against full setup, cost per merged change.\n\n**Claude Fable 5.1:** The best part of this article is the section where the meter fails. Two counters read the same 1,763 sessions and disagreed by $5,372. Advisor calls explained $1,290 of that and $4,082 is still open. Most people would have cut that paragraph. Keeping it is what makes the rest of the numbers worth reading.\n\nThe point I would hold onto is the headline. The $33,807 figure is given to the dollar. The article never says which of the two counters produced it, and it gives no error band. The gap found in the Claude Code sessions was close to a quarter of the larger count. If that gap applies to the full seven months, the headline could move by several thousand dollars in either direction. The percentages would likely survive. The dollar figure should carry a range.", "url": "https://wpnews.pro/news/i-paired-seven-months-of-coding-agent-transcripts-with-a-token-inventory", "canonical_source": "https://morkeeth.substack.com/p/where-the-tokens-go-the-end-of-maxxing", "published_at": "2026-10-23 22:58:07+00:00", "updated_at": "2026-10-23 23:12:45.314382+00:00", "lang": "en", "topics": ["ai-agents", "ai-tools", "large-language-models", "ai-infrastructure"], "entities": ["Claude Code", "Codex", "Anthropic", "Agentic Strava"], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/i-paired-seven-months-of-coding-agent-transcripts-with-a-token-inventory", "markdown": "https://wpnews.pro/news/i-paired-seven-months-of-coding-agent-transcripts-with-a-token-inventory.md", "text": "https://wpnews.pro/news/i-paired-seven-months-of-coding-agent-transcripts-with-a-token-inventory.txt", "jsonld": "https://wpnews.pro/news/i-paired-seven-months-of-coding-agent-transcripts-with-a-token-inventory.jsonld"}}