What it measures
An agent that runs for four minutes and hands back a diff has spent your money and your context window without telling you. PounceCode puts the numbers on the status bar while it works and keeps them with the conversation afterwards.
ctx — how much of the window is gone
A percentage is only useful if the denominator is real. This one is measured against the window the selected model actually has, found by whichever of these works first:
| Source | How |
|---|---|
| The provider's API | Google's native endpoint reports inputTokenLimit per model. Where a provider states it, that is the answer. |
| The endpoint itself | Ollama reports the architecture's context_length; an OpenAI-compatible server such as vLLM reports max_model_len. Local models are the case where a table is most likely wrong, and the endpoint always knows. |
| A known model | A table of specific models whose windows are published and stable. |
| A family default | A per-family estimate, shown with a ~ so you can see it is an estimate rather than a measurement. |
| An error | When a request overflows, the provider's error usually states the real limit. That number is learned and used from then on. |
| Nothing | It shows a dash. A confident 0% is worse than an honest "unknown". |
csh — cache hits
A well-shaped prompt keeps its stable parts in the same order every turn, so the provider can serve most of the input from cache at a fraction of the input price. csh is the share of this turn's input tokens that came back as a cache hit.
It is a design signal, not a vanity number
A high cache rate means the system prompt, sources and history are stable turn to turn. A rate that collapses mid-conversation means something is being rewritten that should not be — the number is how you notice.
It appears when there is one
Providers that do not report cache usage get no csh segment, rather than a zero that would read as "your prompt is badly formed".
Cost
Cached input is not billed at the input rate, and counting it as though it were overstates the cost of exactly the conversations that are cheapest to continue. PounceCode prices the three streams separately:
in=13 cached=4206 — thirteen input tokens for a conversation that plainly sent thousands. Both numbers now roll into the input total, which is why the context percentage moves the way you would expect.
Kept with the conversation
These are not just live readouts. Each turn stores what it used, so a conversation you come back to can still tell you what it cost and where the time went.
| Recorded | Why it is worth keeping |
|---|---|
| Tokens in / out | The basic spend, per turn rather than per session. |
| Cached tokens | Lets cost be recomputed correctly later, and shows prompt stability over a whole conversation. |
| Tool errors | A turn that spent four rounds recovering from a bad path looks identical to a clean one on token count alone. |
| Duration | Wall-clock per turn. Slow and expensive are different problems with different fixes. |
| Model and profile | So a comparison between two models is a comparison, not a recollection. |
Rate limits
When a provider says no, it usually says for how long. PounceCode reads the standard signals rather than guessing: Retry-After, the OpenAI x-ratelimit-reset-* headers, Anthropic's anthropic-ratelimit-*-reset, and the retryDelay Google returns in the error body. Where a provider gives nothing, it backs off on a schedule and paces subsequent requests, easing back up as they succeed.