test(pricing): name the consequence of lowering the sonnet-5 row - #144
Conversation
`PRICING_TABLE["claude-sonnet-5"]` carries 30/150 — the standard rate — while Anthropic's published card shows $2/$10 introductory pricing through 2026-08-31. Read cold against that card the row looks 50% high and reads like a stale entry, so "correcting" it downward does not look like a mistake while you are making it. It is not a reporting bug if someone does. These rates size the TigerBeetle hold and the settle debit, so a row that understates lets a capped agent spend past its cap. The golden test already pins the row, but it fails as "pins all four tiers for claude-sonnet-5" — a name that carries no reason, so the natural response to that red is to update the golden and move on. That is the failure this guards against: `promo-window-understatement` fails with the consequence attached, because a guard whose violation looks like a legitimate correction has to say what breaks, not which invariant it encodes. Verified in both directions rather than only observing a pass: the test passes on the shipped row and fails on the exact 20/100 mutation it exists to prevent (`expected 20 to be 30`). An all-pass suite cannot detect an instrument that is disconnected. The comment is written to survive the promo lapsing. Nothing needs doing on 2026-09-01 — the row simply stops differing from the published card — so it states what the row holds rather than issuing an instruction that expires and then invites its own cleanup. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Signed-off-by: Cam <cam@camwhiteus.com>
Gate round r1 — adjudicated record (orchestra2)GATED_HEAD: Gate exited 1 on a completed clean review: verdict "The patch adds a focused regression test and explanatory comments without changing runtime behavior. No correctness issues were found." — one word off the literal marker. Verified: banner L1, positional trailer valid, CODEX_EXIT=0 (now a REQUIRED fast-path condition per #1063), 0 finding lines in 2,152 lines, HEAD == PR head. Assertion-vs-inability read: an ASSERTION, no hedge. c2 note: the review-thread condition ABSTAINS — this PR has never had a connector thread; the zero is a null reading. This merge rests on three conditions (CI at head, record==head, adjudicated-clean), stated here so no reader counts a fourth that never ran. usertrust CI at head: dco/lint/test/typecheck success; contract/site/tb-integration path-skipped (test-only diff). Second reader: orch backup verifies from the capture (codex-gate-144-*). Capture in the stealth-side gate archive; this is a tracked-code PR so the record lives here (the sibling-file convention governs untracked specs). |
1 participant
What
One test and one comment. No behaviour change, no rate change —
git diffagainst master is 29 added lines and zero deletions.PRICING_TABLE["claude-sonnet-5"]carries 30/150, the standard rate effective 2026-09-01. Anthropic's published card currently shows $2/$10 introductory pricing through 2026-08-31. So for the next week, read cold against that card, this row looks 50% high and reads like a stale entry.It isn't. Entering the promo rate would make the meter understate — and these rates size the TigerBeetle hold and the settle debit, so a row that understates does not merely misreport; it lets a capped agent spend past its cap.
Why the existing golden doesn't cover it
PRICING_TABLEalready has a golden that pins all four tiers forclaude-sonnet-5. It would go red if the row were lowered. But it fails as:A name that gives no reason. The natural response to that red — especially from someone who has just checked the vendor's card and believes they are fixing a stale rate — is to update the golden and move on. The guard and the "correction" point the same direction, and the guard loses.
So this adds a second assertion on the same value under a name that carries the consequence:
The general rule, which is the durable part: when a violation looks like a legitimate correction, the failure has to say what breaks, not which invariant it encodes. An invariant-named guard is fine when breaking it looks like a mistake. This one doesn't.
Verified in both directions
An all-pass suite cannot detect an instrument that is disconnected, so the guard was mutation-tested with a positive control rather than merely observed passing:
AssertionError: expected 20 to be 30Run against this branch's base, not a stale one. The mutation was applied by line address after asserting anchor uniqueness — six sites in the file match
inputPer1k: 30,— and the file was restored and confirmed byte-identical by checksum afterwards.The comment is written to survive the promo lapsing
The obvious framing for this comment is an instruction: do not correct this before 2026-09-01. That framing expires. On 2026-09-01 upstream catches up, the row stops differing from the card, and the instruction becomes text telling a reader not to do something that no longer makes sense — which is an invitation to a cleanup edit, i.e. the same class of problem one step later.
So it states what the row holds and why lowering it is unsafe, and notes explicitly that nothing needs doing on 2026-09-01. No date-triggered test: a guard that fires on a calendar is a scheduled flake, and the repo has no such convention to follow.
Relationship to #129
#129's drift monitor covers the same fact from the other side —
EXPECTED_DEVIATIONScarries aclaude-sonnet-5entry and even predicts its own expiry ("EXPECT THIS ENTRY TO GO STALE on 2026-09-01"). These are complementary, not duplicative:Different reader, different failure mode. Neither substitutes for the other.
Provenance
These 25 lines existed as uncommitted work in a stale worktree whose base was 31 commits behind master. Assessed, mutation-tested, rebased onto current master, and the comment reframed to survive expiry. The test body is unchanged from the original.
Gates
vitest packages/core/tests/ledger/pricing.test.ts— 112 passed.biome check .— exit 0, 639 files, 39 warnings (master's normal state).npm run typecheck— exit 0.