[BUG] UI Bug: Output tokens display only shows last API call instead of cumulative total

[goran-vidas]

Problem Description

There is an inconsistency/bug in how tokens are displayed in the UI when a task involves multiple API calls (e.g., using tools like read_file).

• Input tokens (↑): Displays the cumulative sum of all API calls within the task (Correct).
• Output tokens (↓): Overwrites the value and displays ONLY the output tokens from the last API response, instead of the cumulative total.

Steps to Reproduce

1. Run a task in Architect or Code mode that requires a tool execution (e.g., asking to read a file).
2. Observe the first API call (e.g., tool call generated ~270 output tokens).
3. Approve the tool call and wait for the second API call (e.g., summary response ~270 output tokens).
4. Check the UI status bar vs. Google Gemini Dashboard / Provider logs.

Expected Behavior

Output tokens should show the cumulative total of generated tokens for the entire task (e.g., ~540 tokens), matching the provider's billing metrics, just like Input tokens does.

Actual Behavior

The UI displays only the last call's output tokens (e.g., 270), misleading the user about the actual total output token count used during the session.

[PierrunoYT]

Working on it!

[PierrunoYT]

I checked the current local code and could not confirm the reported last-call-only overwrite.

• The token aggregation function adds tokensOut from every api_req_started record, just as it does for input tokens.
• The task header receives apiMetrics.totalTokensOut, rather than the latest response’s output count.
• Direct execution of the aggregation functions with two requests producing 270 and 190 output tokens, separated by a tool message, returned the expected cumulative total of 460. This passed for both current and legacy message formats.

There is a separate Gemini accounting discrepancy worth investigating: the provider reports candidate output tokens and reasoning tokens separately. The task’s output counter adds only outputTokens, while Gemini’s cost calculation includes reasoning tokens. That could explain a difference from provider billing totals, but it does not establish the reported last-call-only behavior.

Verification limits: I have not reproduced this with a live Gemini task. The targeted Vitest suites could not start because the local environment is missing @rolldown/binding-linux-x64-gnu; the direct aggregation checks above did run successfully.

Could you share the Zoo Code version, exact model and provider configuration, and the affected task’s saved api_req_started usage records (particularly tokensIn and tokensOut for each call)? Please redact API keys, prompts, file contents, and other sensitive information. A screenshot identifying the counter you are checking would also help distinguish the task total from per-request usage.