Logged Usage
Logged Usage is for learning how to run sessions more efficiently — not accounting. Use it to understand which tasks, prompts, and workflows cost the most so you can improve over time.
The figures shown are estimates derived from the JSONL session files Claude Code writes to disk. Some API costs are not written to those files. For accurate billing, always refer to your Anthropic Console or subscription dashboard. Anthropic is the sole source of truth for your actual spend.
What Logged Usage tracks
Section titled “What Logged Usage tracks”Cate reads Claude Code’s local JSONL session files and aggregates token counts into cost estimates using Anthropic’s published retail API pricing. It applies these estimates at the issue level, so you can see what a specific ticket or feature cost — not just a single chat.
What makes this different from other Claude Code cost trackers:
- Issue-level aggregation. Costs roll up across all sessions tied to a Jira, Linear, or GitHub issue — planning, coding, review, and pairing sessions combined. This is the first tool to track spend at the ticket level.
- No double-counting of batched messages. A common error in other trackers; Cate corrects for it.
Claude Pro, Max, and Teams
Section titled “Claude Pro, Max, and Teams”Estimates use retail API key pricing by default. If you’re on Claude Pro, Max, or an enterprise agreement, your actual cost may be zero or significantly different. See Settings → General to estimate your discount.
The Usage tab
Section titled “The Usage tab”Click Usage in the left sidebar to open the project-level usage view.
Summary cards
Section titled “Summary cards”Four cards at the top give a quick read on the selected time window (1d / 7d / 30d / Custom):
| Card | What it shows |
|---|---|
| Logged Usage | Total estimated cost across all sessions in the window |
| Logged Usage / Issue | Average cost per issue — useful for spotting outliers |
| Issues | Number of issues with at least one logged session |
| PRs | Number of pull requests opened |
Daily Cost chart
Section titled “Daily Cost chart”A stacked bar chart breaking down spend by day and by model. Each bar segment corresponds to a model (e.g. haiku-4, opus-4, sonnet-4). Use this to spot expensive days and correlate them with the work that happened.
Top Issues by Cost
Section titled “Top Issues by Cost”A ranked list of the most expensive issues in the time window. Click any row to expand it and see the individual sessions that contributed to that cost.
Time Spent chart
Section titled “Time Spent chart”A stacked area chart showing how time was spent across workflow phases: Planning, AI Coding, AI Review, Reviewing, and Pairing. This is useful for understanding where sessions are running long relative to the value delivered.
Issue table
Section titled “Issue table”The table below the charts lists every issue with logged usage. Each row shows:
- PR — whether Cate opened a PR for this issue
- Issue — the issue ID and title
- Est. Cost — total estimated cost for that issue
- In / Out — input and output token counts
- CW / CR — cache write and cache read tokens
- Duration — total wall-clock time across all sessions
- Last Activity — when the most recent session ran
Expand any issue row to see the individual sessions that made it up, broken down by workflow phase (Planning, AI Coding, AI Review, Reviewing).
Session usage view
Section titled “Session usage view”While inside any agent session, click Usage in the top toolbar to open the session-level usage panel.
This view refreshes every 30 seconds. Enable Tail (top right of the panel) to refresh every 5 seconds.
Summary cards
Section titled “Summary cards”| Card | What it shows |
|---|---|
| Total Tokens | Combined input + output + cache tokens for this session |
| Cache | Cache write and cache read token counts |
| Hit Rate | Percentage of input tokens served from cache |
| Est. Cost | Estimated cost, adjusted by your discount factor from Settings → General |
Cache hit rate — the most important metric
Section titled “Cache hit rate — the most important metric”A high cache hit rate (80%+) means most of your input tokens are being served from Anthropic’s prompt cache rather than billed at full input rates. Cache reads cost roughly 10× less than standard input tokens.
If your hit rate is low, common causes:
- The context window is being cleared between requests (compaction triggered too aggressively)
- The system prompt or large context blocks are changing between turns, breaking cache keys
- Sessions are very short — the cache warms up over multiple turns
Token usage chart
Section titled “Token usage chart”A chart showing token counts per request, broken down by Cache Read, Cache Write, Input, and Output. The red line overlays the running cache hit rate. Use this to watch the cache warm up over the course of a session and to spot requests that are unusually expensive.
Request table
Section titled “Request table”A per-request breakdown of every API call in the session. Columns:
| Column | Description |
|---|---|
| # | Request sequence number |
| In / Out | Input and output tokens for this request |
| CW / CR | Cache write and cache read tokens |
| Cost | Estimated cost for this request |
| Hit% | Cache hit rate for this request |
| Total Cost | Running cumulative cost |
Using this data to work more efficiently
Section titled “Using this data to work more efficiently”The goal of Logged Usage is to help you develop better practices around how agent sessions consume tokens — so you can write tighter tasks, structure context better, and avoid waste.
A few patterns worth watching for:
- High cost per issue with low PR count — tasks may be too large or too vague. Smaller, well-scoped issues tend to be more token-efficient.
- Low cache hit rate in coding sessions — consider whether your CLAUDE.md or system prompt is stable across turns. Frequent changes break cache keys.
- Planning sessions that cost as much as coding sessions — a spec that requires many revision cycles may need a clearer initial prompt.
- Expensive AI Review sessions — review agents re-read the full spec and diff. Very large PRs drive up review cost; stacked PRs (via Epics) help keep individual PR size manageable.