Squeezing the 5h/7d group onto line one was what cost the reset times and
the pace figure at laptop width, and it made the layout jump between one
and two lines as the branch name or the cost changed width. Line two is
now the group's own at every terminal size, so both timestamps and the
burn rate fit; the ladder only starts giving things up below ~80 columns.
The bars also survive down to 35 columns now rather than being dropped
below 68, since a line of their own is all they need. Every rung of the
ladder is fit-checked, the last one included: with the floor that low, a
percentage the API reports in more digits than anyone expects would
otherwise have overflowed the line rather than dropped the group.
The two timestamps still cost ~10 subprocesses to format on a line that
redraws per keystroke, so that is skipped when line two provably cannot
show them -- an under-estimate, so the fit check stays the decider.
With nothing left to squeeze, WRAP_NARROW, the wrap band and the split
tier go: line one is the full tier down to 150, wide to 68, then narrow.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The weekly limit resets every 7 days, but a 5-day week means the sustainable
burn is 20% a day, not the 100/7 the calendar implies. Nothing on the line
said that, so staying inside the limit meant doing the division by hand.
Adds pace and trend to the per-model bar: "Fable 6% 19%/d ✓". pace is what
is left divided by the working days still in the window, so it is the
envelope for today. trend compares usage against today's band - during
working day n of m, anywhere between (n-1)/m and n/m of the budget is on
track - and reports the distance outside it.
A band rather than a point because a point built from completed days expects
0% on the first working day of the window, so any usage at all reads as
overspending: 6% on a Monday morning showed a red arrow. The band is also
all whole-day granularity supports, and the sleep-aware glide in
statusline.burnrate.sh is what it would take to say more.
Working days come from SL_WORK_DAYS (ISO weekdays, default Mon-Fri) and are
counted inside the reset window rather than assumed, so a window that starts
mid-week still divides correctly. The colour thresholds derive from
100/total_workdays instead of the hardcoded 14.3-a-day ones in burnrate.sh,
which would call 13%/d healthy against a 20-a-day budget.
SL_NOW is a test seam for the clock. The cache-age checks deliberately stay
on the real clock: a pinned SL_NOW could otherwise age a fresh fixture past
USAGE_CACHE_SECS and send a test to the network with real credentials.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
