fix(tui): compact statusline token chip

[axobase001]

Summary

• compact the tokens statusline chip to a single cumulative token count like tok 1.4M
• stop duplicating cache-hit details in the tokens chip because the footer already has a dedicated cache chip
• add a regression test that locks the compact output and ensures cch/out details stay out of the token chip

Partially addresses #2309

Validation

• cargo test -p codewhale-tui --bin codewhale-tui footer_session_tokens_chip_uses_single_compact_total --locked
• cargo check -p codewhale-tui --locked
• git diff --check

Greptile Summary

This PR compacts the footer token chip from a verbose in · cch · out breakdown down to a single tok 1.4M cumulative figure, delegating cache detail to the dedicated cache chip. A regression test locks the new format and asserts the old cch/out substrings no longer appear.

• footer_session_tokens_spans now sums total_input_tokens + total_output_tokens via saturating_add and formats the result with the existing format_token_count_compact helper, removing all cache-specific branches.
• The new test footer_session_tokens_chip_uses_single_compact_total verifies the exact output string and negatively asserts against the legacy format tokens.

Confidence Score: 4/5

Safe to merge; the implementation correctly sums input and output tokens (cache tokens are already a subset of input, not additive), and the format change is purely cosmetic.

The core logic is sound and the refactor is narrow. The only observation is that the new regression test uses token values that happen to collapse to the same display string whether or not output tokens are included, so it doesn't fully lock the input + output contract it was written to guard.

crates/tui/src/tui/ui/tests.rs — the new test's input values could be improved to actually verify the output-token contribution.

Important Files Changed

Filename	Overview
crates/tui/src/tui/footer_ui.rs	Token chip simplified to input+output sum; logic is correct since cache tokens are a subset of input tokens, not additive.
crates/tui/src/tui/ui/tests.rs	New regression test locks the compact format and asserts absence of legacy cache substrings; chosen values make it impossible to detect if output tokens were accidentally dropped from the sum.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A["footer_session_tokens_spans(app)"] --> B{"input == 0 AND output == 0?"}
    B -- yes --> C["return Vec::new() (chip hidden)"]
    B -- no --> D["total = total_input_tokens.saturating_add(total_output_tokens)"]
    D --> E["format_token_count_compact(total)"]
    E --> F{{"total >= 1_000_000?"}}
    F -- yes --> G["format: '{:.1}M'"]
    F -- no --> H{{"total >= 1_000?"}}
    H -- yes --> I["format: '{:.1}k'"]
    H -- no --> J["format: raw number"]
    G & I & J --> K["Span::styled('tok {result}', TEXT_MUTED)"]
    K --> L["render in footer Tokens chip slot"]

Loading

_{Reviews (1): Last reviewed commit: "fix(tui): compact statusline token chip" | Re-trigger Greptile}

Greptile also left 1 inline comment on this PR.

[gemini-code-assist]

Code Review

This pull request simplifies the session token-usage chip in the TUI footer by displaying a single, compact total of input and output tokens instead of a detailed breakdown of input, cache-hit, and output tokens. A corresponding unit test has been added to verify this new behavior. There are no review comments, and I have no feedback to provide.

[greptile-apps]

Test values don't distinguish input-only from input+output sum

The chosen values (total_input_tokens = 1_400_000, total_output_tokens = 7_600) both round to "1.4M" at one decimal place, so this assertion would still pass even if total_output_tokens were silently dropped from the sum in footer_session_tokens_spans. A value pair where output tokens shift the display unit—e.g. total_input_tokens = 900_000 + total_output_tokens = 600_000 expecting "1.5M"—would make the test fail if only input is summed, actually locking the full input + output contract the PR intends.

Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!

[Hmbown]

Thanks @axobase001 — this is a tiny, clean UI polish slice and the full visible CI matrix is green.

I’m leaving it unmerged only because it is still marked draft. If it’s ready, please flip it to ready for review and I’ll treat it as harvestable.

[github-actions]

Thanks @axobase001 — your contribution landed in f38864d801ea on main:

fix(tui): compact statusline token chip (#2411)

Closing this PR now that the code is on main. Credit lives in the commit message and (where applicable) the CHANGELOG.md entry for the next release. Apologies for not closing this at the time of the merge — the auto-close workflow is new in v0.8.31.

If you want to land more work and would prefer your future PRs merge cleanly without a harvest step, the CONTRIBUTING.md doc has a short note on what makes a contribution mergeable as-is.

[Hmbown]

Thanks again @axobase001. I landed the compact statusline token chip via #2411 as f38864d8, keeping your tok 1.5M direction and the stronger regression coverage.

I’m going to close this draft as superseded so the queue reflects what still needs attention. #2309 stays open because the broader picker-discovery behavior still has more work beyond this compact chip slice.