Gemini Routing Bug Shows BYOK Agent Stacks Fail at the Boring Boundary: Transport Selection

BYOK sounds like a billing feature until the router sends your key to the wrong API.

That is the uncomfortable lesson in OpenClaw issue #88480, a fresh report that configured google/* chat models can fall through to the generic openai-responses transport instead of using Google’s Gemini API path. The visible failure is clean enough: OpenClaw sends a Google AI Studio key to OpenAI’s /responses endpoint as a bearer token, OpenAI rejects it with a 401, and the user gets no answer. The architectural failure is less clean: a model row that still says provider=google can apparently be paired with api=openai-responses.

That pairing should make every multi-provider agent operator twitch. In a mature runtime, provider identity, auth profile, base URL, wire protocol, and model ID are not vibes. They are invariants.

The bug is loud, but the boundary is the story

The report is useful because it is not a hand-wavy “Gemini does not work” complaint. The reporter reproduced the failure on OpenClaw 2026.5.28 commit e932160 and 2026.5.27 commit 27ae826, running Linux x64 with Node v22.22.2 and the stock @openclaw/google-provider plugin enabled. The affected credential is a newer Google AI Studio key in the AQ. format, not an older AIza… key, which might have made this look like a key-shape bug at first glance.

But the reporter did the right negative control: they called Google directly. The same key worked against https://generativelanguage.googleapis.com/v1beta/models/gemini-2.5-flash-lite:generateContent?key=*** and returned HTTP 200 with an OK candidate. They also tried the usual configuration escape hatches: GEMINI_API_KEY, GOOGLE_API_KEY, auth.profiles."google:default", inline auth-profile credentials, canonical model registration, alias removal, and full Gateway restarts.

The smoking gun is in the OpenClaw log line: [openai-transport] [responses] error provider=google api=openai-responses model=flash-lite, followed by 401 Incorrect API key provided: AQ.... The fallback then reports requested=google/gemini-2.5-flash-lite, candidate=google/flash-lite, reason=auth, next=none. That is a system blaming authentication after it appears to have chosen the wrong transport.

ClawSweeper’s triage is appropriately narrow. It labels the issue P1 with impact:auth-provider, clawsweeper:source-repro, clawsweeper:fix-shape-clear, and a diamond-lobster rating. More importantly, it argues against the tempting bad fix: do not special-case the new Google key prefix and call it done. The proposed fix shape is provider-owned defaulting. A Google model row without an explicit API should resolve to google-generative-ai; explicit user-selected APIs and generic custom-provider defaults should remain respected.

Bring-your-own-key needs bring-your-own-proof

For developers choosing agent platforms, BYOK is usually sold as a control plane feature. Bring your own OpenAI key. Bring your own Anthropic key. Bring your own Gemini key. Maybe route some workloads to local Ollama, some to Qwen, some to Copilot, and keep the enterprise account separate from the hobby account. The marketing page makes that sound like credentials plus a dropdown.

In production, it is a routing problem. A key only means what the runtime does with it. A Google key is safe only if the resolver can prove the selected model belongs to Google, the selected auth profile belongs to Google, the selected base URL is Google’s, and the selected transport speaks Google’s API. If any one of those can silently drift, the operator does not have BYOK. They have BYOC: bring your own confusion.

This particular failure is mercifully noisy. OpenAI rejects the foreign key, so the user sees a 401. But loud failure should not make the design smell smaller. A different provider pair might fail less clearly. An OpenAI-compatible endpoint might accept a request with the wrong semantics. A fallback chain might move a user onto a more expensive provider without making the cost boundary obvious. A custom gateway might log the wrong credential metadata. The point is not that OpenClaw leaked a usable secret to OpenAI; the point is that a multi-provider agent stack must make misrouting structurally difficult and operationally obvious.

The subtle clue is that OpenClaw still knows provider=google while selecting api=openai-responses. That split is exactly where observability should become sharper. Logs should emit the resolved tuple together: provider, model ID, auth-profile owner, transport, base URL class, fallback rank, and the reason each fallback was selected or rejected. Redacted, obviously. But joinable. An operator should not have to infer from an OpenAI error message that a Gemini request used an OpenAI-shaped route.

The regression test should be about the resolver, not the key

The engineering action item is straightforward: test model routing as a contract. Not just “can I load a credential?” and not just “does a happy-path Gemini call work?” Test configured Google model rows with no explicit API. Test explicit API overrides. Test missing or bypassed dynamic discovery. Test alias normalization from google/gemini-2.5-flash-lite to google/flash-lite. Test both AQ. and AIza key formats, but do not let key format drive transport selection. Test fallback exhaustion and verify that a provider-specific model fails closed instead of wandering into an OpenAI-compatible default because that path happens to exist.

There is also a UX fix hiding here. /status, model listing, and failed-turn diagnostics should show the chosen transport, not just the model label. If the user asks for google/gemini-2.5-flash-lite, the status output should say which adapter owns it. If OpenClaw cannot select a native Google transport, it should say: “Google model configured, no Google transport selected,” not “incorrect API key.” Authentication is downstream of routing; reporting it as the root cause wastes operator time.

The broader market lesson is that provider diversity has become part of agent cost governance. Teams reach for Gemini, local models, OpenRouter alternatives, Qwen, Copilot accounts, or custom OpenAI-compatible gateways because they are managing latency, price, data boundaries, vendor concentration, or procurement constraints. Those controls only exist if routing is inspectable. If the runtime can silently reinterpret a provider-specific model as a generic transport candidate, the cost story becomes theater.

OpenClaw is hardly alone here. Every agent platform racing to support “all the models” is building a resolver that will eventually become as important as the model picker itself. The boring boundary — provider to transport — is where the real policy lives.

The right editorial take is simple: BYOK is only as real as the router underneath it. OpenClaw does not need a prettier Gemini error. It needs provider, auth, transport, and model identity to be a single enforceable contract.

Sources: GitHub issue #88480, Google Gemini generateContent API docs, OpenClaw v2026.5.28 release