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

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.

🤖

P3 [CRF-2] The ERROR log is the only operator-facing output of the new behavior, and no test asserts it exists. (Netero)

expectErrorLog swaps in slogtest.Make(t, &slogtest.Options{IgnoreErrors: true}), which suppresses the failure slogtest would otherwise raise. It does not assert. Delete the entire s.logger.Error(...) block at cost.go:107-113 and the new case at line 1905 still passes: it checks CostMicros.Valid == false, that prices are populated, and that IncrementUserAIDailySpend is not called. Nothing observes the log. The token-count fields, which cost.go:105-106 names as the point of logging, are entirely untested.

This file already has the pattern: slog.Make(slogjson.Sink(buf)) plus parseLogLines and getLogLinesWithMessage at lines 3626 to 3663. Route the out-of-range case through a buffer sink and assert the message and the fields.

On the blanket IgnoreErrors: true substitution itself, Mafu-san and Zoro both checked before flagging it and did not: it appears in roughly forty test files across cli/, provisionersdk/ and scaletest/, twice already in this file, so it is the established pattern rather than a divergence. The cost is that it also drops the targeted flaky-error suppression testutil.Logger provides.

🤖

I think it's minor.

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.

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.)

🤖

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-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.

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

Note [CRF-19] This subsystem and chatd now agree on the arithmetic and disagree on the rounding. (Zoro)

Not CRF-3, which is the missing overflow guard in chatd. This is the rounding policy. chatcost.CalculateTotalCostMicros:63 computes the same four-category sum and applies Ceil() once to the total; computeCost truncates each category. Identical token counts at identical prices therefore produce different *_cost_micros values depending on which product recorded them, by up to four micro-units.

Both are defensible in isolation. Worth knowing before anyone reconciles AI Gateway spend against chat spend, or unifies the two functions on the assumption that they are the same computation.

🤖

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.

🤖