Skip to content

feat(widget): context-usage meter backed by the agent manager - #58

Open
AmitAvital1 wants to merge 1 commit into
feat/widget-fluent-uifrom
feat/widget-context-usage
Open

feat(widget): context-usage meter backed by the agent manager#58
AmitAvital1 wants to merge 1 commit into
feat/widget-fluent-uifrom
feat/widget-context-usage

Conversation

@AmitAvital1

Copy link
Copy Markdown
Collaborator

Stack 2/4 · base: feat/widget-fluent-ui (#57)

Adds a context-usage meter (assistant-ui ContextDisplay) to the widget. All computation is on the backend — the agent manager exposes GET /conversations/{id}/usage returning used/max tokens, percent, and a ContextSeverity (normal/warning/critical) as the single source of truth. The FE only renders; it does no token math. Severity is a StrEnum reused across domain + schema so thresholds live in one place.

Verified: make check (Python) + widget typecheck/e2e green.

🤖 Generated with Claude Code

Surface per-conversation token usage against the configured
context_max_tokens budget so users see how full the context is before
they hit the 429 wall.

Backend (source of truth):
- ContextUsage domain value object with a ContextSeverity StrEnum and a
  from_totals factory that owns the warning/critical thresholds
- GET /conversations/{id}/usage returns used_tokens, max_tokens, percent
  and severity; ConversationService.usage sums stored token counts
- schema reuses the domain ContextSeverity enum (no duplicated literals)

Widget (stateless renderer):
- AgentChatClient.getUsage + useConversation.loadUsage fetch usage on
  open and after each turn; no client-side token math or thresholds
- ContextMeter ring (severity-coloured, hover popover) shown only when a
  budget is set; hidden and non-breaking against backends without /usage

Also: neutral demo copy and a documented CONTEXT_MAX_TOKENS in the
starter example.

Tests: usage endpoint, severity thresholds, and two widget e2e cases.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
@Asaf-prog

Copy link
Copy Markdown
Collaborator

PR #58

The implementation is clean, but I think the current naming is misleading.

The backend calculates usage by summing input_tokens + output_tokens across the entire conversation. That represents cumulative token consumption, not the size of the context currently being sent to the model. Since previous messages may be included again in later inputs, the same content can effectively be counted multiple times.

We should either:

  1. Rename this to something like Conversation token budget, or
  2. Calculate the tokens in the current bounded context and compare them against the model’s context-window limit.

I would prefer resolving this before merging, because the UI currently presents the value as Context usage, which gives the user a different meaning from what is actually calculated.

Also, should the critical threshold use >= 85 rather than > 85?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

ui enhancement User-facing UI improvement

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants