{"slug": "claude-code-and-codex-are-logging-your-token-usage-locally-here-is-how-to-read", "title": "Claude Code and Codex are logging your token usage locally. Here is how to read it.", "summary": "Claude Code and Codex store detailed token usage logs locally, including prompt cache hit rates, which developers can analyze without API calls. A developer created ModelMeter, a tool that reads these logs and displays cache efficiency metrics in a dashboard.", "body_md": "Your AI coding agent's token data is already on your machine. You just haven't looked at it yet.\n\nClaude Code and Codex both write local logs after every session. Those logs include detailed token breakdowns: uncached input, cache hits, cache writes, output. No API call needed, no provider dashboard, no guessing. The number that matters most, your prompt cache hit rate, has been sitting on your disk every time you wondered why you were burning through your weekly limit so fast.\n\n**Claude Code** writes a JSONL transcript for every session under `~/.claude/projects/`\n\n. Each assistant message carries a `usage`\n\nblock:\n\n```\n{\n  \"type\": \"assistant\",\n  \"uuid\": \"f0c8...\",\n  \"message\": {\n    \"model\": \"claude-opus-4-...\",\n    \"usage\": {\n      \"input_tokens\": 137,\n      \"cache_read_input_tokens\": 815193,\n      \"cache_creation_input_tokens\": 5521,\n      \"output_tokens\": 4260\n    }\n  }\n}\n```\n\nThat split is the whole game. `input_tokens`\n\nis uncached input. `cache_read_input_tokens`\n\nis context served from the prompt cache. `cache_creation_input_tokens`\n\nis context written to cache. `output_tokens`\n\nis the response. On a long agent session, `cache_read`\n\nshould dwarf `input_tokens`\n\n. If it does not, you are re-paying for the same context on every single turn.\n\n**Codex** writes rollouts under `~/.codex/sessions/`\n\n. It emits `token_count`\n\nevents with a cumulative running total per session:\n\n```\n{ \"type\": \"token_count\", \"info\": { \"total_token_usage\": {\n  \"input_tokens\": 0, \"cached_input_tokens\": 0,\n  \"output_tokens\": 0, \"reasoning_output_tokens\": 0\n}}}\n```\n\nBecause Codex counts are cumulative, you take the delta between events rather than summing them.\n\nA few lines of Node walk the JSONL, sum usage per model per day, and dedupe by message `uuid`\n\nfor Claude and by session delta for Codex, so you never double-count:\n\n``` js\nimport { readFileSync } from 'node:fs'\n\nfor (const line of readFileSync(file, 'utf8').split('\\n')) {\n  if (!line.trim()) continue\n  const o = JSON.parse(line)\n  const u = o.message?.usage\n  if (!u || seen.has(o.uuid)) continue\n  seen.add(o.uuid)\n  // accumulate u.input_tokens, u.cache_read_input_tokens,\n  // u.cache_creation_input_tokens, u.output_tokens by o.message.model\n}\n```\n\nNotice what you do not need: the prompt text, the response text, or any API key. Model names and token counts are enough to compute everything useful. A usage tool should never have to read what you typed, and this one does not.\n\nOnce you aggregate, one metric matters more than the rest: your prompt cache hit rate.\n\n```\nhit_rate = cache_read / (cache_read + cache_creation + uncached_input)\n```\n\nOn a flat plan, this is your real efficiency lever. A high hit rate means you are reusing context instead of resending it. A low one means you are burning tokens, and your usage limit, on the same context over and over. The fix is usually structural: stabilize the front of your prompt so the cache prefix stays intact, keep tool definitions lean, and stop reshuffling system context between turns.\n\nOne honest caveat: on a subscription you do not pay per token, so any dollar figure is an API list-price equivalent, not your actual cost. It is a useful sense of scale, nothing more. The signals that genuinely matter are token volume and cache hit rate. Any tool that flashes a \"you spent $X this month\" number at a flat-plan user is being a little loose with what that number means.\n\nI wrapped all of this into [ModelMeter](https://modelmeter.dev). A one-line collector reads those local logs and sends the token counts, and only the token counts, to a dashboard that shows your cache hit rate, ranks where your tokens are going, and labels every figure by how it was derived: computed from real tokens, a gated estimate, or \"coming\" when it needs request-level data the logs do not contain.\n\n```\nnpx modelmeter-collect init <your-token>\nnpx modelmeter-collect\n```\n\nAdd a Claude Code `Stop`\n\nhook or a 60-second cron job and it stays live, updating after each prompt. It works for Claude Code, Codex, or both. It also accepts usage from a metered API key via a copy-paste snippet, or from a CSV export if you would rather not run the collector at all.\n\nFree to try at [modelmeter.dev](https://modelmeter.dev).\n\nWhether or not you use ModelMeter: you are not flying blind. Your subscription coding tool has been writing detailed usage data to your local disk after every session. Go read it. You will almost certainly find that your biggest efficiency lever is a single number you have never once looked at.", "url": "https://wpnews.pro/news/claude-code-and-codex-are-logging-your-token-usage-locally-here-is-how-to-read", "canonical_source": "https://dev.to/newtorob/claude-code-and-codex-are-logging-your-token-usage-locally-here-is-how-to-read-it-580", "published_at": "2026-06-18 02:40:21+00:00", "updated_at": "2026-06-18 02:51:18.725356+00:00", "lang": "en", "topics": ["developer-tools", "large-language-models", "ai-tools"], "entities": ["Claude Code", "Codex", "ModelMeter", "Anthropic", "OpenAI"], "alternates": {"html": "https://wpnews.pro/news/claude-code-and-codex-are-logging-your-token-usage-locally-here-is-how-to-read", "markdown": "https://wpnews.pro/news/claude-code-and-codex-are-logging-your-token-usage-locally-here-is-how-to-read.md", "text": "https://wpnews.pro/news/claude-code-and-codex-are-logging-your-token-usage-locally-here-is-how-to-read.txt", "jsonld": "https://wpnews.pro/news/claude-code-and-codex-are-logging-your-token-usage-locally-here-is-how-to-read.jsonld"}}