nitpick: BYOK Code Reviewer still uses hardcoded Gemma 4 (Kilo credits) alongside the configured BYOK model — please use the BYOK model for everything

[baanish]

Nitpick: The amount of Kilo credit at stake is a whopping $0.07 (seven cents) over the past month, so this is about BYOK expectations, not money.

Summary

I have my Code Reviewer set to a BYOK model, Neuralwatt: glm-5.2-short, and it does use GLM 5.2 short for the actual reviews. That part works as expected.

The issue: in addition to GLM 5.2 short, Code Review also uses Google Gemma 4 (google/gemma-4-26b-a4b-it) for an auxiliary step, and that Gemma call goes through Kilo (not my BYOK provider). So even though I'm on BYOK, my Kilo credit balance keeps ticking down and I have to keep topping it up. I'd expect a BYOK setup to use my configured model for everything in the Code Review flow, not fall back to a hardcoded Gemma model that bills Kilo credits.

What I expect

When a BYOK model is configured for Code Reviewer, the whole Code Review flow (including the auxiliary review-thread classification step) should use that configured BYOK model, so BYOK users don't have to keep topping up Kilo credits for review-related calls.

What I saw

• Review Configuration shows the selected BYOK model Neuralwatt: glm-5.2-short.
• The actual review comment from kilo-code-bot is explicitly footed "Reviewed by glm-5.2-short" — good, the configured model is honored for the review itself.
• But the Usage dashboard filtered to Code Reviews ($0.07 / 1,032 requests / 32.9M tokens) shows the model breakdown dominated by google/gemma-4-26b-a4b-it-*, i.e. a second model running alongside GLM 5.2 short and drawing down Kilo credits.

Configured BYOK Code Reviewer model:

Actual review, footed "Reviewed by glm-5.2-short":

Usage dashboard (Past Month, Code Reviews) showing Gemma running alongside the configured model:

Root cause (from the source)

The Gemma usage is not the review model. It comes from a separate, hardcoded Cloudflare Workers AI call used to classify unresolved PR review threads as blocking vs non-blocking for the auto-merge flow.

• areThreadsBlocking() in services/gastown/src/dos/town/town-scm.ts calls:

  // "Use Workers AI to determine if unresolved PR review threads contain
  //  blocking feedback that should prevent auto-merge."
  const response: unknown = await ctx.env.AI.run('@cf/google/gemma-4-26b-a4b-it', {
    messages: [{ role: 'user', content: prompt }],
    max_tokens: 256,
    temperature: 0,
    chat_template_kwargs: { enable_thinking: false },
  });

• The model id is the same GEMMA_4_26B_A4B_IT_ID = 'google/gemma-4-26b-a4b-it' defined in apps/web/src/lib/ai-gateway/providers/google.ts, which matches the google/gemma-4-26b-a4b-it / google/gemma-4-26b-a4b-it-20260403 rows in the Code Reviews model breakdown.
• This call is hardcoded (@cf/google/gemma-4-26b-a4b-it), is independent of the Code Reviewer Review Configuration -> AI Model (agent_configs.config.model_slug) BYOK setting, and there's no UI control or disclosure for it. It's tracked via a workers_ai_review_threads analytics event but rolls up under "Code Reviews" usage and bills Kilo credits.

So the review itself respects my BYOK model; the auxiliary "is this thread blocking?" classifier always uses Gemma 4 26B through Kilo regardless of what I've configured.

Suggested fix

• When a BYOK model is configured for Code Reviewer, route the auxiliary review-thread / auto-merge classification through that configured BYOK model too, instead of the hardcoded @cf/google/gemma-4-26b-a4b-it. That way BYOK covers the whole Code Review flow and I'm not topping up Kilo credits for it.
• At minimum, make the auxiliary model configurable and/or disclose it next to Review Configuration -> AI Model so BYOK users know there's a separate Kilo-billed model in the loop.
• On the Usage dashboard, distinguish the primary review model from auxiliary/internal calls (e.g. tag rows with a sub-step like review_threads) so it doesn't look like the wrong model reviewed the PR.

Repro steps

1. Configure a BYOK Code Reviewer model (e.g. Neuralwatt: glm-5.2-short).
2. Trigger a Code Review on a PR (the bot footer will say "Reviewed by glm-5.2-short").
3. Open Usage, filter to Code Reviews.
4. Observe google/gemma-4-26b-a4b-it running alongside the configured model and drawing down Kilo credits despite BYOK.

Notes

The "Past Month" Usage breakdown is an aggregate, so older runs can be mixed in, but the Gemma rows are explained by the hardcoded areThreadsBlocking() Workers AI call above, not by the review model being ignored.

[baanish]

Small correction: the Gemma call isn't in review generation (that correctly uses my BYOK model). It's the auto-merge path, checkPRFeedback -> areThreadsBlocking, which classifies whether unresolved threads should block auto-merge.

It's also the only actual Gemma AI.run in the repo, so the Gemma rows under Code Reviews have to come from there.