Token Counting
See metered usage where supported, with estimates labeled.
Availability
Partially implemented in stable. Read the limits below before relying on this workflow.
Reviewed against stable v0.5.1. Rust candidate additions are labeled separately. Release status.
The pain this solves
- Captured API usage is difficult to compare without structured token fields.
- Missing provider usage must not be presented as exact tokenizer output.
What ships with it
- Usage may be provider-reported or estimated from body byte lengths for some successful billable endpoints; streaming responses receive a heuristic adjustment.
- Some billable HTTP routes estimate request and response token counts from body bytes when usage is missing.
- Direct calls, unsupported routes, and tunneled WebSocket contents may not produce parsed metrics.
Questions this answers
- How many tokens does my AI coding agent use per request?
- Track LLM API token usage per session
- Provider-specific token counting for AI agents
- How to measure input vs output tokens for Claude Code?
How it works
For supported HTTP calls routed through the local API proxy, Chau7 extracts usage fields present in the provider response, including input and output and, where returned, cache or reasoning counts.
On some successful billable HTTP endpoints, when response usage is missing, the proxy estimates input and output token counts from request and response body byte lengths (roughly four bytes per token); streaming responses use an additional reduction for framing. This is a heuristic, not a provider tokenizer or billing-grade count.
Calls outside the configured proxy path, unrecognized endpoints, and WSS-tunneled content may not yield parsed token metrics. The stable implementation does not promise exact counts for every CLI, provider, or model.
Why it matters
Usage fields make captured calls easier to review, and clearly marked estimates can fill some gaps. Keeping measured and estimated values distinct prevents a rough fallback from being mistaken for an exact provider bill.
In the Rust/GPUI candidate
The unreleased Rust/GPUI candidate correlates supported telemetry sources with tabs and provider sessions and records measurement provenance. Coverage depends on the provider and source; universal tokens-per-second measurement across every CLI is not promised.
Candidate features and migration plan. Download links continue to serve the latest stable release.
Frequently asked questions
Are token counts always exact?
No. The proxy prefers provider-reported usage on supported responses. For some billable HTTP endpoints it estimates input/output tokens from body byte length, with an adjustment for streaming; that estimate is approximate.
Are all providers and terminal agents counted?
No. Counting depends on supported HTTP routes and clients being configured through the proxy. WSS tunnels and direct calls may not provide parsed usage.
Does Chau7 use each model’s tokenizer?
No. When usage is absent on some billable routes, the stable fallback estimates from request and response body byte lengths. It is not a model-specific tokenizer.