Enhance model capability
Every model has capability gaps: some don't recognize images, some aren't cost-effective during the execution phase, and some miss mistakes when reviewing code from a single perspective. When a gap is triggered, the upstream often rejects with 400 outright and the client's whole conversation freezes; or the default model is both expensive and not strong enough, and a single model's output has limited trustworthiness. Without changing the client or the model name it calls, the gateway can use Request Payload Rules, transform scripts, and multi-model orchestration to redirect traffic to more suitable models (combinations) and "patch" those gaps.
Scenarios and countermeasures
| Scenario | Symptom / goal | Countermeasure |
|---|---|---|
| Model can't recognize images | Image-bearing requests are rejected with 400 by the upstream | A switch-route rule detects images and redirects to a multimodal model (Scenario 1) |
| Only want to eliminate the error, don't care about image content | Same as above | filter-content-types strips image blocks and the original model serves as usual. See "Alternative approach" in Route image-bearing requests to a vision model |
| Claude Code execution model needs to be stronger / cheaper | opusplan's execution phase defaults to sonnet; or running opus end-to-end is costly | A before-slot script detects the plan-mode marker and switches the execution phase via useModel to zenlayer/qwen3.8-max / kimi-k3 (Scenario 2) |
| PR code review needs higher accuracy | A single model has blind spots, and false positives/negatives are hard to eliminate | GitHub Actions multi-model parallel review + consensus aggregation, all routed through the gateway (Scenario 3) |
Scenario 1: models that can't recognize images — route image-bearing requests to a multimodal model
Symptom: a text model (e.g. glm-5.2) receives an image-bearing request and is rejected with 400 by the upstream; when a coding agent replays the whole history, once an image has appeared, every subsequent turn errors out.
Solution: attach a switch-route request payload rule to the original text model. Before protocol translation it detects images by the client's shape; on a match it redirects to a multimodal model (e.g. zenlayer/qwen3.8-max); requests without images continue to the original model. The check only does structural inspection and does not read image bytes, so large request bodies don't enter memory whole.
Key pitfall: the position of images differs across client protocols — an Anthropic client may place them at two depths (the message top-level content block and the nested tool_result content block, both required), while OpenAI and DashScope (input.messages.*.content.*.image) have their own paths. Miss any client shape and image-bearing requests still hit the text model and keep returning 400.
The complete condition-path table (with Console screenshots), JSON shapes, where to attach the rule in an LB scenario, and verification steps — see Route image-bearing requests to a vision model. To only eliminate the error without caring about image content, use that page's "Alternative approach" filter-content-types to strip images.
Scenario 2: replace Claude Code's execution model (agent mode)
Symptom / goal: Claude Code's opusplan mode uses a strong model in the plan phase and defaults to sonnet in the agent (execution) phase. The execution phase is where most tokens go — you want the execution phase stronger or cheaper (switch to zenlayer/qwen3.8-max / kimi-k3), or running opus end-to-end is too costly.
Solution: Claude Code injects plan-mode markers into the conversation (entering Plan mode is active, exiting Exited Plan Mode, both inside <system-reminder>). Attach a transform script to the entry model's before slot that scans from the last message backward and uses the last occurrence of the marker to determine state: in plan mode, stay on the original model; not in plan mode, switch context.useModel to the execution model. Sessions running opus end-to-end never enter plan mode and have no marker, so the script falls back to switching all requests to the execution model.
Key pitfalls: ① The determination must be "take the last marker" rather than "does it contain the marker" — the entering marker stays in the history forever, so a contains-check would permanently misjudge as plan mode. ② Must attach to the before slot (the after slot can't read the client-injected marker position, and useModel only works within the same protocol). ③ EXEC_MODEL must be a model name that actually exists in the gateway (use the full name, possibly with an upstream prefix), otherwise it switches to a 404 model_not_found. ④ A script OOM falls back silently per log-and-continue, appearing as "no switch happened".
The complete script, marker-determination rationale, why it must attach to the before slot (with Console screenshots), OOM and SCRIPT_MEMORY_LIMIT_MB, and troubleshooting FAQ — see Switch models by Claude Code plan mode with a script.
Scenario 3: multi-model consensus PR auto code review
Symptom / goal: single-model review has perspective blind spots, and false positives/negatives are hard to eliminate. Have 2–3 models review the same PR independently in parallel, then merge, deduplicate, and annotate consensus confidence for clearly higher accuracy.
Solution: GitHub Actions triggers a review job that calls the review models through the gateway — ANTHROPIC_BASE_URL points to the gateway, which does the protocol interop. GitHub's claude-code-action only speaks the Anthropic protocol; relying on the gateway's interop lets non-Anthropic models like qwen3.8-max and kimi-k3 enter the review queue too. After multi-model parallel review, it aggregates, deduplicates, annotates consensus, and publishes a single PR comment. A single gateway access key carries all review traffic — credentials are centralized and cost is measurable.
Why go through the gateway (rather than direct to upstream): one key opens many doors — protocol interop is the precondition for multi-model consensus, and direct connection can only review Anthropic-family models; all review traffic flows through the gateway, so cost is measurable; a dedicated key rate-limits and stops on revocation without affecting business traffic when things go wrong.
The complete 5-step configuration (configure review models in the gateway, issue a dedicated key for CI [with Console screenshots], GitHub Secrets/Variables, single-model and multi-model workflow connection approaches, verification and troubleshooting) — see Multi-model code review with GitHub Actions.
FAQ
Q: Does switch-route slow down requests? No. It makes structural determinations before protocol translation without reading binary content bytes; large request bodies still go to disk spooling and don't consume memory.
Q: Can the rule be attached to a load balancer (LB)? The rule must be attached to the model configuration that the client's request actually hits. When the client's model name is an LB, attach it to the node model behind the LB — the node resolved by the LB carries its own request payload rules and executes them.
Q: How is billing calculated after redirect? It's priced by the target model (Scenario 1 uses the multimodal target model, Scenario 2 uses EXEC_MODEL, Scenario 3 prices each review model separately and the gateway aggregates). Statistics and billing show the target model's usage. See Pricing and billing.
Q: After exiting plan mode in Scenario 2 it didn't switch away / the script seems to have no effect? Most likely the determination was written as "contains the marker" (the entering marker stays in history forever and will always misjudge as plan mode), or the script was attached to the after slot, or the script OOM'd and silently fell back. Check each in the FAQ of Switch models by Claude Code plan mode with a script.
Q: In Scenario 3, if every PR is reviewed, won't comments spam the timeline? No. Before each review round, the action auto-collapses historical Claude comments on that PR to OUTDATED, leaving only the latest round's expanded comment in the PR timeline; oversized PRs (beyond max_lines) are skipped by default. See Multi-model code review with GitHub Actions.
Next: Reduce call cost for cost reduction; Request rewrite and routing: how to choose for selection boundaries; Upstream and model fields for all request_payload modes.