Summary
A user suggested that AgentBar would be more useful if it showed estimated cost per session, not only token counts.
most useful addition IMO would be cost tracking per session not just token counts. knowing I've spent $2.40 on a single Claude Code session hits different than seeing raw numbers.
Problem
Right now AgentBar shows token usage and model breakdown, but it does not translate that into session-level cost. Raw token numbers are useful, but cost is easier to interpret at a glance.
Proposed direction
Add estimated cost tracking per session, starting with providers where local usage data already includes enough token detail.
Possible scope:
- Estimate cost per session for Codex sessions
- Estimate cost per session for Claude local sessions
- Show both token totals and estimated USD cost
- Make it clear that costs are estimated and depend on pricing assumptions
- Keep model-aware pricing, so GPT-5.4, Claude Sonnet, Opus, etc. can be priced separately
Implementation notes
- Reuse the existing local session parsing logic
- Map token usage to provider/model pricing tables
- Separate input, output, cache, and reasoning tokens where pricing differs
- Decide whether pricing should be hardcoded, configurable, or fetched from a maintained source
- Consider whether the UI should show:
- current session cost
- cycle total cost
- per-model cost breakdown
Acceptance criteria
- AgentBar can estimate cost for at least one Codex session and one Claude local session
- The UI shows cost in a way that complements token counts instead of replacing them
- Pricing assumptions are visible or documented
- The feature degrades safely when pricing data is missing
Open questions
- Should session cost be shown in the main popover, dashboard only, or both?
- Should pricing be manually maintained in the repo or user-configurable?
- Should this be strictly local, or eventually include web/API billing data when available?
Related feedback
The same user also asked about the Claude reconnect flow for web limits. That may be worth tracking separately as a UX/documentation issue.
Summary
A user suggested that AgentBar would be more useful if it showed estimated cost per session, not only token counts.
Problem
Right now AgentBar shows token usage and model breakdown, but it does not translate that into session-level cost. Raw token numbers are useful, but cost is easier to interpret at a glance.
Proposed direction
Add estimated cost tracking per session, starting with providers where local usage data already includes enough token detail.
Possible scope:
Implementation notes
Acceptance criteria
Open questions
Related feedback
The same user also asked about the Claude reconnect flow for web limits. That may be worth tracking separately as a UX/documentation issue.