Sean Egan
Ask the agent

OPERATIONS LEDGER

What the agents are doing, by the numbers

Token use across every coding-agent seat, added up from the session logs by a script that runs each night. If a day is missing, the script didn't run that night, and the gap stays visible rather than being filled in.

—

tokens processed since 1 July 2026

About the local model

Qwen3-235B-A22B-Instruct. 235 billion parameters in a mixture-of-experts design, with about 22 billion active for any one token. Quantized to 4-bit (AWQ) so it fits across two NVIDIA DGX Sparks, each with 121 GB of unified memory. Served by vLLM, split across both units in pipeline-parallel, behind an OpenAI-compatible API, with a 64,000-token context. It runs around the clock at about 96% of the pair's memory ceiling, so nothing else shares those machines. It is too slow for a person waiting on a reply; it takes the batch, judgment, and drafting work that would otherwise spend frontier tokens.

Watch

Loading…

Why the number is large

Yes, it is a lot. An agent with a long memory re-reads its context on every turn, and that context sits in a cache, so each turn counts the whole thing again at about a tenth of the price. The table separates what was re-read from what was new.

Tokens Share
Cached context re-read – –
New context (written to cache or sent uncached) – –
Written by models – –

The split covers Claude Code and Codex, where the logs record it. Bob and the local model are counted as totals.

Token hygiene

A large number is only a problem if it is careless, so this is what I do to keep it from being careless.

  1. Keep the cache warm on purpose. The tool list is pinned byte-for-byte and new context is appended last, so the long prefix stays cached from turn to turn.
  2. Send less each turn. The per-turn context packet went from about 46,000 characters to between 6,500 and 19,000, and first-turn input fell 24%.
  3. Stop paying for lookups. Tool-discovery calls fell from 11% of tool calls to 0.03 per use.
  4. Don't ship boilerplate. Tool results no longer repeat the tool's description; 1.3 million characters stopped shipping.
  5. Route by cost. The most capable model plans and writes, cheaper models build and check, and the local model takes the bounded work. On the day the model page shipped, 32% of calls ran on my own hardware.
  6. Measure before adding context. From 3,000 to 46,000 tokens of context, accuracy held at 180 of 180 and speed fell 7.5 times. The extra context cost time and added no accuracy.
  7. Cost every prompt change. Rewriting a standing instruction costs about 200,000 uncached tokens once, so a change has to save enough to pay that back.
  8. Cap the agent on this site. It has a rate limit and a daily budget computed from its own ledger, and it stops when the budget is spent.

The ledger is public so the number can be checked, and so can the claim that it is mostly cache.

Tokens per day

Last 90 days, stacked by tool. Hover or tab to a bar for the exact count.

Scrolls sideways to show all 90 days on narrow screens.

Totals since 2026-07-01

Share by model

Sorted by volume, colored by tool.

Most of the Claude volume is cached context being re-read; output tokens are 0.2% of the total, which is what long, memory-heavy sessions look like.

Per machine

Logs are collected from three machines, the VPS, my GPU box (bigmem) and my Mac; the eleven seats are the coding agents across all five machines: seven Claude Code, three Codex and one Grok.

Machine Tool Tokens Sessions Turns First session Status

Method

The script reads the session logs directly: ~/.claude/projects for Claude Code, ~/.codex/sessions for Codex, on whichever machine it runs on. For Claude Code it sums input, output, cache write, and cache read tokens. Cache read dominates, because a long session re-reads its own memory on every turn. A Claude Code sub-agent (a Task-tool call, or a fork) writes its own transcript file, and those are included too, counted toward the parent session rather than as extra sessions. For Codex it sums input and output; Codex also reports a cached-input count, but that's a subset of input already counted once, so it's excluded to avoid double counting. Forked and subagent threads inherit the parent session's running counter at the moment they fork. The script sums each turn's marginal delta instead of the session total, so a fork doesn't re-count everything that came before it. A machine that's asleep or unreachable when the collector runs keeps showing its last known total, with the time it was last seen, instead of dropping to zero. The script itself: /ops/token_usage.py.

Caveats

Last updated: loading….