tokens and requests counted on this machine, by model and day
Token usage
#DGC keeps a small local record of what every model request cost in tokens, so you can see which models you lean on and how much, without trusting a dashboard somewhere else. It covers every provider DGC talks to: a local Ollama or llama.cpp server, an OpenAI-compatible host, Anthropic, and so on.
Where to see it
#- In the editor: Settings → Token Usage. Pick a range (Today, 7 days, 30 days, This month or All time) to see input, output and cached-input totals, the request count, a table by model with each one's share, and a day-by-day strip for input and output.
- In the terminal:
/usageinside DGC, ordgc usagefrom the shell. Both take a range:dgc usage --range 30d. Add--jsonfor a machine-readable report.
Days follow this computer's local time, and the report says which time zone it used.
What is counted
#One row is recorded for each model request that finished, with the numbers the provider itself reported: input tokens, output tokens and cached input tokens. Each row notes which route sent it: your conversation, a sub-agent, the fallback model, or context compaction. A sub-agent's requests are counted once, as its own.
- Unmetered requests. A request the provider accepted but that ended without a usage report (you cancelled it, the stream broke, or a stalled attempt was retried) is still counted as a request, marked unmetered, because it may have cost tokens nobody reported. Its tokens are not in the totals, and the report says so when there are any.
- Reported zero. An explicit zero-token report is metered; it is distinct from a missing report.
- Consistent views. Totals, the top 100 model rows and daily bars use one database snapshot, even when another DGC process records usage at the same time.
- OpenAI-compatible endpoints. DGC asks these to include usage in the stream. An endpoint that rejects the request is asked again without it and is not asked again until DGC restarts (the editor's backend keeps that memory across every chat it runs). Its requests then show as unmetered rather than as zero tokens.
- Not counted: turns delegated to a subscription CLI (Claude Code, Codex and the others) run in the vendor's own tool, so DGC never sees their token counts.
The prompt cache's clock
#In the editor's Work chat, a small clock after the context meter says how long the provider keeps this conversation cached, so the next message is read from the cache instead of at full price:
- 4m beside the clock: the cache is warm, about four minutes left. It changes once a minute, never in seconds. Its tooltip says "Prompt cache warm, about 4 min left."
- The clock alone, in the error colour: the cache has gone. The tooltip says why: likely expired after so long idle, the conversation was compacted past it, or Ollama unloaded the model.
- The clock dimmed, with no minutes: DGC can't time this cache. Minutes are shown only where the provider says how long itself, and only after a reply used a cache: Anthropic's own cache report, and the lifetime its cache write used (
prompt_cache_ttl, 5 minutes or 1 hour, counted from the start of the request), and a local Ollama's own unload time for the loaded model (ollama_keep_alive). OpenAI, DeepSeek, Ollama Cloud and subscription CLIs don't say, though their caches still work. The tooltip names the provider: "Ollama Cloud may cache your prompt, but it doesn't say for how long, so DGC can't show a timer." On Anthropic or a local Ollama it means nothing is cached yet: "No timer yet: Anthropic says how long its cache lasts after a reply."
Click the clock to open the context meter's details: they show the tokens the provider reported as cached. Reopening a chat whose cache has gone adds one line to it: "Idle 2h 5m. The prompt cache has likely expired, so your next message will re-cache about 180k tokens." The clock is in Work only, not in ChatDGC or Pips. dgc serve sends it as a cache_clock event.
Privacy
#Everything stays on this machine, in ~/.dgc/usage.sqlite (readable only by you). No prompt or reply text is stored, and an endpoint is recorded by host and port only, never its full address, path or any credential. Rows older than 400 days are removed automatically. To start over, quit DGC and your editor first (a running DGC keeps the file open and would go on counting into the deleted copy), then delete usage.sqlite together with its usage.sqlite-wal and usage.sqlite-shm companions; DGC creates a new one the next time it runs.