Skip to content

fix(receipt): step cost reads exact only when reported, not estimated - #179

Merged
mikehasa merged 1 commit into
mainfrom
fix/step-cost-confidence
Aug 30, 2026
Merged

fix(receipt): step cost reads exact only when reported, not estimated#179
mikehasa merged 1 commit into
mainfrom
fix/step-cost-confidence

Conversation

@mikehasa

Copy link
Copy Markdown
Owner

V1StepUsage.costText rendered any complete (non-partial) step cost as exact $, with no confidence check — so a step whose cost was estimated from tokens was shown as an exact figure, over-claiming precision (found in the earlier security/honesty audit).

Fix: the backend derives one cost_confidence per step from its existing per-record cost_confidence_breakdown — exact only when every priced record is reported/billed, otherwise an estimate — and the macOS app picks $ vs ≈$ from it (partial stays ~$, unpriced stays ). This matches the app-wide cost grammar used everywhere else.

Backend helper unit-tested; swift build + all snapshot-harness suites pass (no snapshot flips — no fixture renders a priced step cost).

…estimated

V1StepUsage.costText showed a complete (non-partial) step cost as exact $
regardless of how it was priced, so a step whose cost was estimated from
tokens over-claimed exactness. The backend now derives one cost_confidence per
step from its per-record breakdown (exact only when every priced record is
reported/billed, else estimated), and the app renders $ vs ~=$ from it — the
same app-wide cost grammar the other surfaces use.
@mikehasa
mikehasa merged commit 4c2c300 into main Aug 30, 2026
4 checks passed
@mikehasa
mikehasa deleted the fix/step-cost-confidence branch August 30, 2026 22:01
@mikehasa mikehasa mentioned this pull request Aug 30, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant