The JS test uses writeModelsFixture({ "github-copilot": { models: { "gpt-5.4": { cost: { ... } } } } }) to pin the exact prices it is testing. Doing the same in Go (via os.Setenv("GH_AW_MODELS_JSON_PATH", ...)) would make this test a pure arithmetic regression rather than a combined pricing-plus-arithmetic check.

This also means any future price update to gpt-5.4 in data/models.json will require updating wantAIC here — a non-obvious maintenance burden if the relationship is not documented.

Encode the distinguishing characteristic in the name. For example:

{name: "gpt54_20k_input_1k_output",  inputTokens: 20314, outputTokens: 970,  wantAIC: 6.5335},
{name: "gpt54_24k_input_15k_output", inputTokens: 24162, outputTokens: 1534, wantAIC: 8.3415},
{name: "gpt54_54k_input_4k_output",  inputTokens: 54255, outputTokens: 4411, wantAIC: 20.18025},
{name: "gpt54_66k_input_low_output",  inputTokens: 65750, outputTokens: 224,  wantAIC: 16.7735},

This lets a failing test message immediately surface the input range, making it faster to correlate back to the live artifact.

const samples = [
  { inputTokens: 20314, outputTokens: 970,  wantAIC: 6.5335 },
  { inputTokens: 24162, outputTokens: 1534, wantAIC: 8.3415 },
  { inputTokens: 54255, outputTokens: 4411, wantAIC: 20.18025 },
  { inputTokens: 65750, outputTokens: 224,  wantAIC: 16.7735 },
];

it.each(samples)(
  "gpt-5.4 live: $inputTokens in / $outputTokens out → $wantAIC AIC",
  async ({ inputTokens, outputTokens, wantAIC }) => {
    const { computeInferenceAIC } = await import("./model_costs.cjs");
    const got = computeInferenceAIC({ provider: "copilot", model: "gpt-5.4-2026-03-05",
      inputTokens, outputTokens, cacheReadTokens: 0, cacheWriteTokens: 0 });
    expect(got).toBeCloseTo(wantAIC, 9);
  }
);

Each sample becomes a named subtest, surfacing exactly which input data failed.

Choose one tolerance and use it consistently:

• JS stricter: change Go to assert.InDelta(t, tt.wantAIC, got, 5e-10, ...)
• Go looser: change JS to toBeCloseTo(sample.wantAIC, 8) (which checks within 5e-9)

Since the values are exact floating-point arithmetic with the given prices, 1e-9 or tighter should be achievable on both sides.

Derive a wantAIC that includes cache read tokens (e.g., from the live artifact if a cache hit is present, or synthetically with a known token count):

// synthetic: 10000 cache-read tokens at 0.00000025 = 0.0025 USD = 0.25 AIC
{ inputTokens: 10000, outputTokens: 0, cacheReadTokens: 10000, wantAIC: /* input+cache */ }

Without this, a bug that zeroes out cache-read billing would pass all four existing assertions.

The JS counterpart writes its own fixture with writeModelsFixture, so its expectations are independent of models.json. This Go test does not — it relies on gpt-5.4 pricing in the embedded data/models.json matching the hardcoded expected values exactly.

When gpt-5.4 pricing is updated in models.json (corrected rates, model deprecation, etc.), this test fails with a numeric mismatch that has no obvious connection to the pricing file. The failure message will show something like expected 6.5335 but got 7.2100, leaving the developer wondering why a live-data test broke after an unrelated JSON change.

Consider using an environment-variable override analogous to GH_AW_MODELS_JSON_PATH (the JS side) or temporarily swapping the embedded bytes, e.g.:

// write a temp models.json with the known gpt-5.4 prices
dir := t.TempDir()
modelsPath := filepath.Join(dir, "models.json")
// ... write fixture ...
t.Setenv("GH_AW_MODELS_JSON_PATH", modelsPath)

If the Go implementation has no equivalent override, the test comment should at least say which prices it depends on and point to data/models.json so the coupling is explicit.

The two existing toBeCloseTo calls use precision=6:

• line 56: expect(aic).toBeCloseTo(0.54825, 6)
• line 104: expect(aicViaEmbedded).toBeCloseTo(aicViaProvider, 6)

The new test uses precision=9. The arithmetic here is straightforward (a few multiplications + additions on ~20k–65k token counts), so there is no correctness reason to demand sub-nanosecond precision. Using a tighter-than-needed tolerance:

1. Creates an unexplained inconsistency that will confuse the next person writing a test in this file.
2. Could cause spurious failures if a future refactor introduces a legitimate intermediate rounding step.

precision=6 (or even 4) is sufficient to verify the billing arithmetic is correct.

findModelPricing selects the catalog entry with the longest matching prefix of the normalized model ID. If data/models.json gains a new entry like gpt-5.4-2026 in the github-copilot provider, it becomes the new longest prefix for gpt-5.4-2026-03-05 and silently overrides the pricing. The wantAIC values would then be wrong, but the test would fail for a completely opaque reason.

Minimally, add a comment stating which pricing record is expected (gpt-5.4, input=2.5e-6, output=1.5e-5) and how the wantAIC values were derived. Better yet, this is another reason to add fixture isolation: a test-local models.json with only gpt-5.4 removes the ambiguity entirely.