Skip to content

fix(terminal): table truncates numeric columns when Models column is too wide #946

Description

@cristoslc

Problem

Numeric columns in table output are truncated with ellipsis (e.g., 536,073,…) when the Models column consumes too much width. This is especially visible with non-Claude model names that include provider prefixes (e.g., minimax/minimax-m2.5, qwen/qwen3.5-397b-a17b).

Two related root causes:

  1. formatModelName only shortens Claude models — Third-party model names with provider prefixes (e.g., minimax/minimax-m2.5, moonshotai/kimi-k2.5, google/gemma-4-31b-it) are returned unchanged, making the Models column extremely wide and crowding out numeric columns.

  2. No maximum cap on Models column width — The Models column can consume all available width, compressing numeric columns to their minimum width (10 chars), which truncates formatted numbers like 13,044,466.

Example (opencode weekly with long model names)

│ 2026-W16 │ - cogito-2.1:671b                                                      │ 502,210… │ 1,717,4… │        0 │        0 │ 503,928… │    $2.24 │
│ Total    │                                                                        │ 992,106… │ 3,400,2… │   97,285 │ 51,273,… │ 1,048,0… │   $32.77 │

After proposed fix (strip provider prefixes + cap Models column at 25 chars)

│ 2026-W16 │ - cogito-2.1:671b         │  13,044,466 │    125,061 │      97,285 │  30,366,617 │  43,633,429 │    $7.23 │
│ Total    │                            │   992,106… │  3,400,2… │      97,285 │   51,273,… │   1,048,0… │   $32.77 │

Related issues and PRs

Proposed fix

Three changes in packages/terminal/src/table.ts:

  1. Strip provider prefixes from model names in formatModelName — e.g., minimax/minimax-m2.5 → minimax-m2.5, qwen/qwen3.5-397b-a17b → qwen3.5-397b-a17b
  2. Cap Models column at 25 chars in the content-width calculation to prevent it from stealing width from numeric columns
  3. Increase minimum width for numeric columns from 10 to 13 in the responsive scaling path, ensuring formatted numbers like 13,044,466 (10 chars) have sufficient space

The previous fix (#701) was reverted because it broke compact mode. This approach addresses that concern by capping the Models column width rather than just inflating numeric column minimums.

Activity

  1. yamamuteki commented on May 27, 2026

    @yamamuteki

    Thanks for building and maintaining ccusage, @ryoppippi — it's become a daily-use tool for me, and I really appreciate the careful root-cause analysis already written up in this issue.

    Adding a data point that may broaden this slightly.

    I hit the same Total-row truncation, but with only Claude first-party models (opus-4-7, sonnet-4-6, haiku-4-5). The Models column is short in my case, so a wide Models column isn't the only trigger.

    ccusage daily, v20.0.5, Total row:

    │ Total │ │ │ 63,513 │ 8,064,9… │ 36,137,813 │ 3,019,905,2… │ 3,064,171,4… │ $1929.50 │
    

    The per-day rows render fully; only the Total row is cut. It looks like the numeric column widths are sized from the data rows, but the Total is an order of magnitude larger and overflows. E.g. the Output column's widest daily value is 7 chars (757,749) while the Total is 9 chars (8,064,900).

    I also rendered through a pty at both 80 and 250 columns — the truncation is identical at both widths, so terminal width / responsive scaling isn't the factor here. The Total row's magnitude simply isn't accounted for when the numeric column widths are computed.

    So beyond "strip provider prefixes / cap the Models column", it might also help to include the Total row's values in the numeric column-width calc (or revisit the min-width bump from #701 without the #722 compact-mode regression).

    Env: ccusage 20.0.5, Node 25.8.1, macOS.

  2. github-actions commented on Aug 28, 2026

    @github-actions
    Contributor

    Pullfrog triage: priority:medium

    A maintainer explicitly requested an implementation attempt. This is a valid repository-scoped terminal formatting report with a concrete reproduction and useful follow-up data. It is not spam, invalid, duplicate, or out of scope, but the proposed path targets an older TypeScript layout while the current implementation is Rust and needs maintainer triage.

    Decision: kept open; Pullfrog will attempt a focused implementation PR.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    priority:mediumA normal bug or meaningful improvement.

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions