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:
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.
@gnanam1990
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.gohas the real data —TokenUsageandUsagewithInputTokens,OutputTokens,CachedInputTokens,CacheWriteTokens,ReasoningTokens, and the runtime emitsStreamEventUsage/AgentEventUsageas a turn runs.internal/agent/types.go:379already exposes the subscription:What's missing
internal/acpnever sets it.agent.go:262-271wiresOnText,OnReasoning,OnToolCall,OnToolResultandOnPermissionRequestonto the notifier — and stops there. A grep forusageacrossinternal/acp/*.goreturns 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
OnUsageto asession/updatenotification 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 —
providermodelcataloglooks 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
configOptionsyou 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/acprecently 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.@gnanam1990