You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
ACP never forwards token usage, so no ACP client can show tokens or cost #929
ZeroApp's status bar is meant to show tokens and cost (it's a Module A line item), and it can't — not because it isn't wired up on our side, but because the number never crosses the wire.
The good news is that this looks small, because Zero already tracks it and already has the hook. Nothing needs inventing.
What exists
internal/zeroruntime/types.go has the real data — TokenUsage and Usage with InputTokens, OutputTokens, CachedInputTokens, CacheWriteTokens, ReasoningTokens, and the runtime emits StreamEventUsage / AgentEventUsage as a turn runs.
internal/agent/types.go:379 already exposes the subscription:
OnUsagefunc(Usage)
What's missing
internal/acp never sets it. agent.go:262-271 wires OnText, OnReasoning, OnToolCall, OnToolResult and OnPermissionRequest onto the notifier — and stops there. A grep for usage across internal/acp/*.go returns nothing.
So the ACP layer is the only place the number is dropped. Every ACP client — ZeroApp, Zed, JetBrains, Neovim — is blind to it, while the TUI has it.
The ask
Wire OnUsage to a session/update notification the way the others are, so clients can render it. Whatever shape you think is right; from the desktop side I only need enough to display a running total and to compute cost, so input/output/cached broken out is more useful than one summed number.
Cost specifically needs per-model pricing, which is yours rather than ours — providermodelcatalog looks like where that would live if it exists. If Zero would rather emit tokens and let clients price them, that works too, but then the pricing table has to be reachable somehow or every client reinvents it differently.
Not urgent
Nothing is blocked. ZeroApp's status bar already shows connection, agent, activity, waiting count, uptime and — as of Gitlawb/zero-app#39 — the model, which comes from the configOptions you already send. Tokens and cost are the last two fields and they're the only ones we cannot build ourselves, so I'd rather flag it early than sit on it.
Happy to do the ACP-side wiring myself if you'd prefer — I've been in internal/acp recently for #915 — but it's your module and the shape of the notification is your call, so I'd rather ask than send a PR you have to argue with.
Activity