[eric-engberg]

Based on #46 (value colors on the percent widgets), and merges #16 (the shared token count base), #35 (Session Cost Rate) and #37 (Daily Cost Rate), which add or reshape widgets this PR colors. Review the two commits after those merges. It goes upstream after #41, #46 and those three.

What

Value colors come to the widgets that count an amount rather than a percent, with break points in that amount's own unit:

Widget	Key	Green below	Red from	←→ step
Session Cost	v	$5	$20	$1
Session Cost Rate, Daily Cost Rate	v	$5/hr	$15/hr	$1
Tokens Input	v	10k	50k	5k
Tokens Output	v	100k	1M	50k
Tokens Cached, Tokens Total	v	10M	100M	5M
Compaction Counter	l	1	3	1

Each one opens the same editor as the percent widgets, which now shows break points, samples and typed values in the widget's unit: $7.50, 250k or 1.5M, 3.

Why

#46 covered the widgets measured against a whole. The rest of the numbers on a status line, what a session costs, how fast it spends and how many tokens it has used, are just as worth reading at a glance. They have no 100%, though, so their break points need to be amounts.

The token break points come from measuring the 23 sessions on my machine, with each API response counted once:

• Tokens Input had a median of 90 and never passed 14.6k.
• Tokens Output had a median of 17.4k and reached 4.3M.
• Tokens Cached and Total had a median of 3.5M and reached 2.3 billion, because cache reads add up every turn.

A single pair of break points would leave Input always green and Cached always red, so each widget has its own. With these, 15 to 22 of the 23 sessions stay green on each widget, and only the largest reach yellow or red.

Counting each response once is what upstream's open fix for over-counted tokens does (sirmalloc#595, for sirmalloc#549). Today the token widgets count a response once per content block, which on these sessions comes to 2.6 to 3.7 times the real count (medians of 164 for Input and 6.1M for Cached). Until that fix lands, the colors arrive earlier in a session than these numbers suggest; the break points are set for the corrected counts, so they won't need changing when it does.

How

• A scale can name its unit (ValueUnit in value-units.ts): percent (the default, so the existing scales don't change), dollars, dollars per hour, tokens, or a count. The unit sets:

  • how the editor shows a value;
  • how a typed value reads: dollars to the cent with or without $, and tokens in full or with k or M;
  • its step, range and decimal places.

  Break points stay one decimal place apart: 1, or a cent for dollars.

• A scale can set where its gradient ends by default. An amount has no 100%, so every widget here ends its gradient at its high break point.

• Compaction Counter uses l (va(l)ue colors), since v already cycles its value. It colors the count, or the auto, manual or unknown count. Its icon or label, its trigger split and the tokens reclaimed keep the widget color. For that, formatColoredValue takes an optional suffix, drawn like the label. The reclaimed value is tokens, not a count, so it has no value colors.

• Where the code lives:

  • the four token widgets get value colors once, through refactor(widgets): share one base class across the token count widgets #16's shared base, and each sets its own scale;
  • the two cost rates share one scale.

• The editor's lowest sample is now half the mid break point rounded down rather than to the nearest. That keeps a sample of 0 below a count's mid of 1. On a percent scale it can move that sample by one, e.g. 43% to 42%.

• Nothing changes until value colors are turned on. Off, every widget draws exactly the text it did before.

Demo

Piped through the real pipeline at three levels, with made-up amounts: a payload with the session cost and times, and a transcript with the token usage and compactions. Daily Cost Rate sees only this session, so it's shown on clock time, apart from Session Cost Rate on Claude's active time.

Powerline

Plain

The editor walkthrough:

1. Session Cost shows its break points in dollars. Value colors go on, and mid is typed as 7.50.
2. Tokens Cached shows 10M and 100M.
3. Compaction Counter's editor opens on l, in compactions.

At the end the preview shows all three in their colors.

Powerline

Plain

Testing

• Tests, each written first and seen failing:
  • value-units.test.ts (6): each unit's display and typed values, including $2.50, 1.5M and a float product like 1.005k, and the rounding helpers.
  • value-coloring.test.ts (6 new):
    • a dollar, token and count scale's bands, steps and typed values;
    • errors in the unit (Mid has to start below high ($20).);
    • its own gradient end;
    • a suffix kept in the widget color.
  • value-colors-editor.test.ts (3 new): a dollar scale's rows, samples, hint and typed 7.50; its gradient ending at $20; and a count's sample keeping 0 below mid.
  • amount-value-colors.test.ts (42):
    • for all eight widgets: the key, the editor row, the editor and preservesRenderedColors, and unchanged output with value colors off;
    • each widget's bands at its break points;
    • each token widget's own defaults;
    • Compaction Counter's label, suffix, metrics and glyph editor.
  • The existing key tests for Compaction Counter, Session Cost Rate and Daily Cost Rate now include the new key.
• Bun: bun test gives 3155 pass, 0 fail (Bun 1.4.2). bun run lint is clean. A 12-run loop of the editor Ink tests had no failures. The first commit alone also passes lint and tests (3113).
• Node 26 vitest: the 9 touched test files pass (204 tests).
• Built CLI on both runtimes: runtime-check.sh -c amount-value-colors, with the demo's mid level seeded, showed Bun 1.4.2 and Node 26.10.0 agreeing byte for byte in plain and Powerline modes. The TUI opens and exits under both.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
99.5% Coverage on New Code
2.1% Duplication on New Code

See analysis details on SonarQube Cloud