fix(ai/recipes): declare max_batch_tokens on the google (gemini) recipe

[kkroo]

Why

google is the only shipped embedding recipe with neither max_batch_tokens nor no_batch_cap: true — every other one is capped (voyage, openai, zhipu, azure-openai, dashscope, minimax, openrouter, zeroentropyai) or explicitly opts out (litellm-proxy, llama-server, ollama). So it's the sole recipe tripping the once-per-process warnRecipesMissingBatchTokens guardrail at startup.

gemini-embedding-001 has a real, tight cap — 2048 tokens per text, and it effectively accepts only one text per request (batchEmbedContents batch size = 1; excess errors when AUTO_TRUNCATE=false). That's a genuine cap, not an unbounded endpoint, so max_batch_tokens is the correct declaration (not no_batch_cap).

Change

• google.ts: max_batch_tokens: 2_048 + chars_per_token: 1, safety_factor: 0.5 — the conservative "1 char ≈ 1 token dense content, 0.5 utilization" assumption the voyage recipe uses. Keeps any single request under the per-text limit and arms the gateway's recursive-halving safety net. Commented with the two gemini caveats + sources (ai.google.dev/api/embeddings, langchain-ai/langchainjs#8490).

  • Caveat documented in-code: gbrain batches by token budget, not item count, so this can't enforce gemini's 1-text-per-request rule outright — but it bounds per-request tokens, which is what the guardrail is about.

• adaptive-embed-batch.test.ts: the "startup warning" test used google as its live capless fixture (asserted google warns). With google capped, every shipped recipe now declares a cap or opts out, so the test is reframed to assert that invariant (zero warnings) — a stronger check that fails CI the next time a capless recipe is added.

  • Reviewer note: this drops the "warning fires + names the recipe" mechanism coverage, since no real capless recipe remains to exercise it. If you'd rather keep that, a synthetic capless fixture (mock listRecipes) would restore it — happy to follow up whichever you prefer. If you intentionally kept google capless as the fixture, feel free to close this.

Validation

bun test test/ai/adaptive-embed-batch.test.ts → 25 pass / 0 fail locally.

Context

Surfaced while cleaning up a downstream Blockcast gbrain-code-sync CronJob whose startup logs carried the recipe "google" declares an embedding touchpoint without max_batch_tokens warning (that job embeds via the litellm recipe, so the google warning was just noise there — but it pointed at this genuine gap).

---

Update (2026-07-01): warning-mechanism coverage preserved — earlier trade-off resolved.
The first revision capped google and reframed one warning test to an invariant, which dropped the warning mechanism coverage — and, as CI surfaced, broke a second fixture (the serial #779 test) that also used google as its live capless double. Both are now fixed properly: the per-recipe warn decision is extracted into an exported pure predicate shouldWarnMissingBatchTokens(recipe), and both suites drive the guardrail with a synthetic capless recipe. google stays capped while the mechanism that catches a future recipe forgetting max_batch_tokens stays fully covered — no real recipe left uncapped as a fixture. Local: test/ai/ 317 pass / 0 fail, tsc --noEmit clean.

Note: test (5) (the findTrajectory shard) is red on master independently of this change — verify against the master baseline, not this PR.

[kkroo]

CI update on the latest push (5e1cf742):

• ✅ serial-tests now passes. Capping google had broken a second warning fixture (#779) that also used google as its live capless double; that's fixed by the synthetic-recipe approach in this push (shouldWarnMissingBatchTokens predicate).
• ⚠️ test (5) fails on findTrajectory (7 tests) — this is pre-existing on master, not from this PR. The same 7 find-trajectory tests fail on master's own latest Test run (28211183059); this PR only touches src/core/ai/recipes/google.ts, src/core/ai/gateway.ts, and two test/ai/* files — zero overlap with the claim-trajectory query path. test-status is red only because it aggregates that pre-existing shard.

So every job this change touches is green; the remaining red is the master baseline. Happy to rebase once findTrajectory is fixed on master if you'd like a clean board before merging.

[allyblockcast]

Ally — Consolidated PR Review

Lenses: code-review + test-analyzer + comment-analyzer.

Important Issues (1)

• [test-analyzer] test/ai/adaptive-embed-batch.test.ts:102–143, test/ai/no-batch-cap-suppression.serial.test.ts:231–253 — The "warns once per process / reconfigure doesn't re-warn" behavior is no longer tested. Before this PR, configureGoogle() was called twice to exercise the _warnedRecipes dedup logic on a recipe that actually warns. Now google is silent, so both test files call the real code path at most once with a non-warning recipe, or test only the stateless shouldWarnMissingBatchTokens() predicate. A regression that removes the _warnedRecipes.has(recipe.id) guard from gateway.ts line ~552 would not be caught.
  • Recommendation: Either (a) export _warnedRecipes or a reset/inspection hook and drive warnRecipesMissingBatchTokens() directly twice with a synthetic capless recipe to exercise the dedup Set, or (b) inject a synthetic capless recipe into the registry that listRecipes() walks. The current pure-predicate tests are insufficient because they have no access to process state.

Strengths

• Logic extraction is sound. The new shouldWarnMissingBatchTokens() predicate is a faithful byte-for-byte extraction of the original inline logic—no conditions reordered or altered. The refactor is correct.
• Gemini API facts verified. The 2048-token per-input cap and single-text-per-request limitation of batchEmbedContents are accurate per Google's embeddings docs and langchain-ai/langchainjs#8490. Sources are genuine and relevant.
• Token estimation is defensible. The chars_per_token: 1 and safety_factor: 0.5 mirror the voyage recipe's conservative heuristics—well-documented in the inline comment.
• Invariant correctly proved. The test rewrite properly asserts "every shipped embedding recipe declares a cap or opts out (no warnings)"—a stronger check than the old "google warns" fixture.
• google regression guard in place. Both test files include an explicit assertion that google now stays silent.

Recommended Action

1. Address the Important issue: restore end-to-end coverage of the _warnedRecipes dedup logic by either injecting a synthetic capless recipe into the test-time registry or by exporting a state-inspection hook.
2. Re-run bun test test/ai/ locally to confirm all 317+ tests still pass after the fix.

reviewed head: afed2d0