termdeck
Features
Usage and cost
Where the tokens went, by project, by model, by day, with a number attached.
Where the numbers come from
Neither Claude nor Codex stores a cost figure after a turn is done, so there is nothing to look up. Termdeck re derives spend by scanning the transcripts already on your machines and counting the tokens each turn recorded.
The scan returns tokens only. Your browser estimates cost using a model pricing table refreshed by the server daily. If the pricing source is unavailable, Termdeck uses the last successful table or bundled fallback rates.
Two things the scan gets right that a naive count does not
- Sub agent work is included. Sub agents write their own transcripts, and on real projects they account for a meaningful slice of total spend. Leaving them out would quietly undercount every number on the page.
- Duplicated history is counted once when the transcript identifies the request. Claude streaming snapshots and copied messages share a message ID. Codex forks retain turn IDs and cumulative token counters, which let Termdeck recognise copied usage without adding it again. Older Codex records without turn IDs can only be deduplicated within their own session.
Reading the page
Open Usage from the sidebar. The top row is the summary for the selected range:
| Metric | Meaning |
|---|---|
| API equivalent cost | What these tokens would have cost at published API rates. See the note below. |
| Input tokens | Everything sent to the model, with the share served from cache called out separately. |
| Output tokens | What the models generated, alongside the number of agent turns. |
| Active sessions | How many chats contributed, how many are live, and across how many machines. |
Below that: cost per day as a bar chart across the full width, then the model mix showing which models are actually consuming your budget, beside the token composition. Under those, a table by project, drilling down to individual runs.
Show under $10, next to the date range at the top of the page, controls which days, models, projects, and sessions are visible. Each day is tested against its combined cost across machines and models. The summary still includes the full selected range, and model percentages keep their share of the full priced total when smaller models are hidden.
API equivalent cost is an estimate, not your invoice. It applies standard model rates to recorded token counts. Subscription charges, service tiers, long-context surcharges, historical rate changes, and provider-specific charges can differ. Approximate model matches and tokens without a known price are called out on the page. Cache-write duration details divide the recorded write total; they do not add extra tokens to it.
Date ranges
Presets cover the common questions, and the two date fields take an explicit range for anything else. The range lives in the URL, so a link to "last month for this project" is a link you can send to someone.
On Starter the page goes back 7 days. The 14d and 30d presets stay visible and open an upgrade prompt, and the start date cannot go earlier than a week ago. Pro shows your whole history.
This page refetches only when you ask it to, on a preset click, a committed date, or first load. It deliberately does not update live, because a range you are halfway through typing should not be replaced by an event arriving from a machine.
Why cache read matters
Cached input tokens cost a fraction of fresh ones. A high cache read percentage means your chats are reusing context efficiently, which is usually a sign that the work is well scoped. A low one on a long chat often means the context is churning, and compacting or starting a fresh chat will cost less than continuing. The cache also expires when a chat sits idle (an hour for Claude on a subscription, five minutes on an API key, about 30 minutes for Codex), and the composer says so when it has; see Managing the context window.
The What's driving your limits card is an approximate explanation from local Claude transcripts. Repeated blocks and copied messages count as one request, with distinct tool calls preserved. Its percentages describe overlapping characteristics weighted by tokens, so they do not add to 100%. A failed machine read is shown as unavailable, separately from a successful read with no activity.
Questions this page answers well
- Which project is consuming the budget, when three are running at once.
- Whether routing routine work to a cheaper engine is actually saving anything.
- Which day the spend spiked, and which run did it.
- Whether a premium model is being used for work a smaller one would have handled.
Scope and limits
- Covers Claude and Codex transcripts. Grok usage appears in the live limits panel rather than here.
- Covers projects added to Termdeck on your connected machines. Offline machines and failed reads leave gaps, which the page reports.
- Only transcripts still available in the scanned session directories contribute. Deleted or trashed sessions and Codex's separate archived-session directory are outside the scan.
- Date ranges use your browser's current timezone offset. A historical daylight-saving change can shift activity near midnight into an adjacent day.
- Scanning a large history takes a moment the first time. Nothing is uploaded: the scan runs on each machine and only the totals cross the wire.