nit: IIRC real usage can reach it, just depends on the currency used (although I think we will probably always stick to USD or EUR). I think we can remove this comment

Checked this one because the panel read it the other way, and both readings are defensible for different reasons.

The claim is accurate under the price book that ships today. ai_model_prices is written only by prices.Seed from the embedded generated JSON (coderd/aibridge/prices/prices.go:38-54), and the highest price in data/prices.json is 600,000,000 micro-units per million tokens, which puts the overflow point around 1.5e10 tokens in one response.

Your currency point is the part worth keeping. Nothing in the schema or the code names a currency; the migrations say only "micro-units (1 unit = 1,000,000)", and the sole place a currency is asserted is the user-facing string at coderd/aibridged/http.go:158-160, which hardcodes US$. If prices were ever quoted in a low-denomination currency, a $600/M model at roughly 16,000 units per USD is about 1e13 micro-units per million tokens, and the overflow point drops to under 1e6 tokens, which a single request with a 1M-token context reaches. So "real usage cannot reach it" is not a property of the arithmetic, it is a property of the implicit USD assumption, and that assumption is enforced by nothing.

So rather than delete the sentence, state what it depends on. Something like "real usage cannot reach it while prices are quoted in USD micro-units" keeps the reasoning that makes the rest of the design make sense (Leorio rated this doc comment as the thing that turns CRF-11 from a mystery into a fixable omission) and stops it from silently becoming false if the price book ever changes denomination.

🤖

Now that we've capped the interception cost at $10 million, I think this comment makes sense. We don't expect interceptions to exceed that amount, so we treat them as invalid and simply drop the cost.

P2 [CRF-10] Per-category truncation, the one invariant the description explicitly guarantees, is pinned by no test and documented nowhere in the repo. It is now a single deletable method call. (Gon P1, Bisky P2, Zoro Nit)

Under the old code the property was free: tokens * price / 1_000_000 in int64 had no choice but to truncate per term. Now Truncate(0) is the only thing producing it, and IntPart() at the total would silently take over if it went away.

Bisky deleted it and ran the suite. The orchestrator reproduced this independently on the review worktree:

$ # .Truncate(0) removed from tokenCost
$ go test ./coderd/aibridgedserver/ -run TestComputeCost -count=1
ok      github.com/coder/coder/v2/coderd/aibridgedserver 0.052s

All thirteen cases stay green because only one has a fractional category and three of its four terms are exact, so truncating per category and truncating the total both give 1552. Every other fractional case is single-category, where the two are identical by construction. Bisky's case closes it, verified passing at 74 on current code and failing at 75 with Truncate(0) removed:

{
	// Two categories each with a 0.5 remainder. Truncating per category
	// gives 37 + 37; truncating the total once would give 75.
	name: "each category truncates before the sum",
	price: database.AIModelPrice{
		InputPrice:  nullInt64(3_750_000),
		OutputPrice: nullInt64(3_750_000),
	},
	inputTokens:  10,
	outputTokens: 10,
	want:         74,
},

The consequence is a silent one. Someone simplifies tokenCost, or moves the truncation to the total, gets a green suite, and stored cost_micros stops matching a breakdown recomputed from the snapshotted price columns. Off-by-up-to-four micro-units per record, on a number that feeds daily spend and budget enforcement, with nothing to catch it.

Gon rated this P1 for the missing comment specifically, since the rationale lives only in the PR description, which the next reader will not have. Fix both halves: add the case, and put the why on tokenCost where Gon and Zoro both proposed it. CRF-9's QuoRem fix retires most of this by making truncation the only thing the expression can do.

🤖

Fixed: 6bd034c

P2 [CRF-11] The errCostOutOfRange doc names two suspects; the log records only one of them, and identifies no record. (Leorio P2, Chopper P3, Ryosuke P3)

The comment two lines up says token counts are logged "because the range error alone does not say which input was wrong", which is the right instinct. But errCostOutOfRange's own doc says the condition means "a wrong price row or implausible provider-reported token counts", and only one of the two is in the log.

Leorio traced the case that matters: a price row six orders of magnitude high makes every token count in the log entry look completely normal. The operator sees plausible tokens, a 20-digit total, and no reason to suspect the price table. price is in scope from line 78.

Chopper and Ryosuke add the other half. No field identifies the affected record, so an operator holding "cost out of range for anthropic/claude-sonnet-4-6" cannot reach the aibridge_token_usages row, the interception, or the user whose spend is now understated; on a busy deployment the row has to be recovered by matching provider, model and token counts inside a timestamp window. Every other diagnostic in this package carries one: the skipped-spend Debug logs interception_id and initiator_id (aibridgedserver.go:409-410), the threshold-detection Error logs both (:435-436), the unresolved-group Warn logs user_id (cost.go:66).

This matters more here than for the sibling unpriced Debug log at line 85, which omits the ID too, because that path is a benign recurring condition with a metric behind it while this one is a per-record anomaly whose entire purpose is to be investigated. intc.ID, intc.InitiatorID and the four price fields are all in scope at this call.

🤖

I added interception_id and initiator_id (9286dbe). The pricing is defined in prices.json and embedded into the binary, so it's unlikely to be incorrect. If needed, it can always be derived from prices.json by provider and model.

P3 [CRF-9] Div routes every stored cost through decimal.DivisionPrecision, a mutable package global, where the old expression depended on nothing. (Komugi P3, Ging-Go P3, Mafuuu P3, Meruem P3, plus Notes from Razor, Ryosuke, Hisoka, Killua, Knov, Zoro, Bisky)

Div is d.DivRound(d2, int32(DivisionPrecision)) and DivisionPrecision is a plain var ... = 16 ([email protected] decimal.go:44, :590-592) that any package linked into the binary can reassign. The result is correct today because the quotient of an integer by 1e6 terminates within six fractional digits, so rounding at sixteen is a no-op. That correctness is a property of the default, not of the expression.

Three reviewers forced it independently and got the same shape. Komugi:

DivisionPrecision=16 -> 1 (err=<nil>)
DivisionPrecision=2  -> 2 (err=<nil>)

DivRound rounds half away from zero before Truncate(0) runs, so below six places the documented truncation silently becomes rounding up. Komugi swept a sample set and found divergences from the original int64 expression at (1, 1_999_999) -> 2 want 1, (999_999, 1) -> 1 want 0, (123, 999_999) -> 123 want 122, and on negatives at precision 0. Nothing in the repo assigns the global (four reviewers grepped independently), which is why this is P3 and not higher.

The fix states the precision the code actually needs and deletes the Truncate(0) step, since the quotient is already integral:

q, _ := decimal.NewFromInt(tokens).
    Mul(decimal.NewFromInt(pricePerMillion.Int64)).
    QuoRem(tokensPerMillion, 0)
return q

Komugi ran this over the same sample set at DivisionPrecision 16, 2 and 0 and matched the original int64 expression on every non-overflowing case, negatives included, since big.Int.QuoRem truncates toward zero exactly like Go's /. This also makes per-category truncation structural rather than a deletable call, which is most of CRF-10. Razor measured a math/big variant at 589ns against 3759ns for the current code, noting performance is irrelevant at this call rate and mentioning it only because the simpler option is also the faster one.

🤖

Fixed

P3 [CRF-12] The caller converts every computeCost error into "cost unknown, store NULL", so the sentinel is discriminated nowhere outside the test. (Chopper P3, Meruem P3, Zoro P3, Knov P3)

errCostOutOfRange exists so a caller can tell "unrepresentable, keep going" apart from "something else went wrong". The only errors.Is against it is cost_internal_test.go:162. Production does if err != nil and then logs a message that asserts a specific cause.

Today computeCost has exactly one failure mode, so nothing is misreported. What is wrong is the contract: the next error added to computeCost, for any reason, is silently downgraded to a NULL cost under a log line naming the wrong diagnosis, with no code change and no review signal. Chopper called it the unhandled middle inverted, handling all errors as one known error.

The file already has the shape twelve lines up, where the price lookup separates the known case from the rest. errors is already imported:

switch {
case errors.Is(err, errCostOutOfRange):
	// No trustworthy cost exists, so record it as unknown rather than
	// storing a figure derived from bad inputs.
	s.logger.Error(ctx, "cost out of range, recording token usage with NULL cost", ...)
	return result, nil
case err != nil:
	return tokenUsageCost{}, xerrors.Errorf("compute cost for %s/%s: %w", intc.Provider, intc.Model, err)
}

Meruem's alternative is equally valid and cheaper: if discrimination is not wanted, drop the sentinel, because an unchecked sentinel is a distinction the program does not make.

🤖

Makes sense, but I don't expect computeCost to change much. In any case, if computeCost fails - there is nothing better than set cost to NULL, but don't fail recording.

P3 [CRF-1] This is the only NULL-cost outcome with no metric, so the condition the PR exists to surface is detectable only by log scraping. (Netero)

The sibling NULL-cost condition four blocks up increments a counter (cost.go:87-89, s.metrics.UnpricedTokenUsageRecords). Two consequences. unpriced_token_usage_records_total, documented in docs/admin/integrations/prometheus.md:119 as counting records "for which no model price was found", no longer accounts for every NULL cost_micros, so a dashboard reconciling "records with NULL cost" against that counter silently disagrees. And the new condition has no numeric signal at all.

metrics.go:25-34 already carries provider/model-labelled counters, so this is one field plus one Inc() with the same labels. s.metrics is nil-checked at cost.go:87, so the same guard applies here.

🤖

I don't think we need a metric for this extremely rare scenario.

Note [CRF-20] The per-category reconciliation the description justifies has no query yet, and the natural form of it overflows in the one language you just left. (Knuckle)

The PR justifies per-category truncation by saying a breakdown recomputed from the snapshotted price columns sums exactly to the stored total. No such query exists: input_price_micros and its siblings are write-only, referenced solely by InsertAIBridgeTokenUsage (queries/aibridge.sql:46).

When someone writes it, the natural form is input_tokens * input_price_micros / 1000000, and bigint * bigint raises exactly where the old Go code wrapped (verified: select 9223372036854775807::bigint * 2::bigint returns ERROR: bigint out of range). Whoever writes that query needs ::numeric on the multiply. One line in the column comment, while the reasoning is fresh, is cheaper than rebuilding the invariant in the one language that still fails at the same boundary.

🤖

Nit [CRF-17] expectErrorLog names an assertion the field never makes. (Gon Nit, Leorio Nit)

The field's only effect is IgnoreErrors: true at line 3289. Nothing verifies an error log was emitted, and setting it on a case that logs nothing passes silently. The field's own doc gets the verb right on the first word, "tolerates", while the identifier says "expect", which in test-helper vocabulary means the test fails if it does not happen. The next person to write expectErrorLog: true will believe they have coverage of the log.

ignoreErrorLogs or tolerateErrorLogs describes what it does, and the doc then shortens to match the name instead of correcting it. Distinct from CRF-2: renaming fixes the mismatch without adding an assertion, and adding the assertion would not fix the name.

🤖

Nit [CRF-18] The wrapped error reads as a fragment and never states the bound it violated. (Gon Nit, Leorio Nit)

Rendered output, which Leorio produced with a scratch test:

cost 18446744073709551614 micro-units: computed cost is out of range
cost -3000000 micro-units: computed cost is out of range

The context clause is not a phrase, "cost" appears twice, and the operator gets a 20-digit number plus the words "out of range" with no way to know what range without reading Go source. Sentence first, detail after, and decimal.Decimal implements fmt.Stringer so .String() is redundant under %s:

return 0, xerrors.Errorf("%w: %s micro-units", errCostOutOfRange, total)

Leorio would go further and put the bound in the sentinel itself, where it costs nothing and is right every time. If CRF-6 moves the ceiling, name the new bound there.

🤖

Nit [CRF-22] The second sentence narrates the six log fields directly beneath it. (Gon P2)

"The token counts are logged because the range error alone does not say which input was wrong" tells the reader that lines 109 to 112 log token counts, which those lines already show, wrapped in a rationale that is the obvious purpose of a diagnostic log. The first sentence carries the actual why-not-what, the decision to record NULL rather than return an error or store a figure.

// No trustworthy cost exists, so record it as unknown rather than storing a
// figure derived from bad inputs.

(CRF-11 argues the fields themselves are incomplete, which is the substantive half of this statement.)

🤖

Nit [CRF-21] Two comments in this case restate the case name and the assertion messages. (Gon P2)

"Token counts large enough that the cost cannot be stored" restates name: "valid token usage with cost out of range" plus InputTokens: math.MaxInt64. "The record is written anyway, with prices snapshotted and cost NULL" restates the assertions at lines 1929 to 1932, whose own messages already read "input price populated" and "cost null". Line 1934, // Prices and tokens are populated even though cost is NULL., restates the same three assertions a second time eight lines later.

Delete both; the case name and the assertion messages carry it. Note the contrast with lines 1924 and 1944 in the same case, which Gon explicitly kept: those decode a literal (2_000_000 means two micro-units per token) and give a reason (Times(0) because cost is NULL) that the code cannot show.

🤖

nit: moving this to validateTotalCost() to be consistent with validateTokenUsage

Fixed: 1792455

It might be useful to include provider and model here as well.
Additionally, it might make sense to create a metric for this, with provider and model as well. Can be done in a follow-up PR.

1. The provider and model variables are not in scope. It's possible to refactor this, but it turns out that would require changes to both the code and the tests. I guess it's not worth it?
2. I'll create a follow-up

Another metric here as well. In fact, thinking about it better, we should have a metric for all the NULL cases 🤔 we already have for the unpriced model, but we should have for the other 2 cases.

I'll create a follow-up