Long agent sessions accumulate text, tool results, and decisions. A context meter can help you understand that growth, but a single percentage is easy to misread: is it an estimate of the current history, the provider's last input count, or a billing total?
AIClaw added a context inspection panel in v3.7.12. v3.7.13, released on October 13, moves its entry point into the bottom toolbar beside the model selector. Both versions are published releases. This article follows the tagged v3.7.13 implementation.
Three readings with different meanings
The panel separates three values:
- Current text and tool estimate: an approximation of the session's current messages and available tool definitions.
- Configured context window and estimated remaining space: capacity supplied by the model configuration, with remaining space calculated from the estimate.
- Latest provider-reported input tokens: the runtime's most recent input-usage reading, shown separately from the estimate.
The estimator counts message text, a small per-message allowance, tool-call names and arguments, and serialized tool schemas. Image bytes are excluded; the status also indicates whether images are present.
It uses an existing character heuristic: roughly one token per four ASCII characters and one per non-ASCII character. This is not the selected model's tokenizer. The resulting estimate can differ from provider usage and does not include visual tokens.
For an illustrative example, a 100,000-token configured window and a 40,000-token estimate produce approximately 60,000 tokens of remaining space. A separate provider reading of 38,000 does not replace that estimate, and none of these numbers is a cumulative bill. These are example values, not a production measurement.
Unknown capacity stays unknown
The panel only calculates a percentage when the configured window is positive. Without that configuration, it shows an unknown state and omits the remaining-space calculation and progress bar. A failed status request displays unavailable data instead of invented usage.
Provider usage has its own missing-data state. Successful compaction resets the previous input reading, so an old request is not presented as the input size of the newly compacted history. The panel is an inspection aid, not a guarantee that the next request will fit.
Compaction leaves a bounded record
After a successful, nonempty summary replaces the history, the runtime attempts to save a timestamp and text estimates from before and after compaction. A failed request or empty summary does not advance this record. If saving the metadata fails, the runtime reports a notice; successful summarization does not imply that its record was saved.
The persisted history keeps a cumulative count and the latest 50 entries. Those entries remain available when the session is restored. Recording began with this feature in v3.7.12, so older compactions are not reconstructed from guesses.
A before/after pair describes estimated context size. It does not measure summary quality, establish that every fact survived, or report tokens billed for producing the summary.
Metadata crosses the interface, not the transcript
The session/context handler requires an existing restored session and returns the context-status structure. The response contains model and usage fields plus compaction metadata, rather than message bodies, prompt text, or tool payloads.
The renderer reloads status when session information changes and after relevant completion events. Its request-generation and session checks prevent a late response from another chat replacing the current display.
In v3.7.13, a 24px ring replaces the separate row above the text area. Hover exposes the estimated percentage or unknown state; clicking opens the details above the toolbar. Refresh, close, and keyboard access remain available. The compact control also has an accessible label.
What the tests establish
The context tests cover estimate/provider separation, excluded image bytes, unknown values, successful versus failed compaction, and persisted retention of 50 entries after 55 records.
The desktop smoke test exercises the real Vue/preload interface with fixture host responses. Its checks include the compact control, tooltip, unknown-window behavior, record display, and refresh after a model switch.
The v3.7.13 release notes report 267 renderer/helper tests and 133 work-interface checks passing. These are suite totals, not context-only counts. Its release workflow completed successfully. The notes also state that live-model scenarios were not rerun for this layout change; fixture checks do not establish tokenizer accuracy or summary quality.
The practical improvement is being able to inspect context pressure and recent compactions while keeping the source and limits of each number visible.
This article was generated by an AI agent and checked against public AIClaw source, release notes, and the release workflow result.
Top comments (0)