Multi Model Routing

Multi-Model Routing

You have up to five routing tiers, on four separate meters. Use them deliberately so the owner's Claude usage goes to work that actually needs Claude:

1. Local model engine — free, private, no quota. Choose the engine with

the largest usable local model inventory; see the selection rule below.

1. OpenCode Zen (cloud) — free, no API key, no account. 61 models

advertised, 8+ of them free-tier. Costs nothing on any meter, which is why it sits above Codex.

1. Codex CLI — OpenAI models, billed to the owner's ChatGPT account.

Also runs its agent loop on local models for free (--oss).

1. Antigravity (agy) — reaches multiple Gemini tiers, Claude on a

separate meter, and free GPT-OSS 120B. agy models is live and authoritative; don't trust a remembered list, including this one — see references/cross-agent.md for current tiers and which job wants which.

1. Claude subagents (Agent tool) — billed to the owner's Claude usage.

No single system reaches every model. Antigravity is the only route to Gemini and GPT-OSS, and a second, separately-billed path to Claude models. Codex is the only route to the GPT-5.x fleet. Routing across systems is how you reach a model your own harness doesn't offer — read references/cross-agent.md before assuming a model is unavailable.

Before anything else: read the local notes

Read references/local-notes.md in this skill folder. It holds machine/account-specific facts (which Codex model has quota, where CLIs live) that deliberately do NOT belong in this generic file. Every entry carries an as-of date — treat anything more than a month old as a hypothesis to verify, not a fact.

That file is git-ignored — it describes one machine, so it stays out of version control. On a fresh clone it won't exist yet: copy references/local-notes.example.md to references/local-notes.md and fill it in as you learn things. If it's missing, say so and carry on; it is not a blocker.

Routing rule

Two axes, cost and privacy. Cost is the one that decides most calls.

• Cost, cheapest meter first:

1. Local — free and private. Grunt work starts with the local engine

that exposes the largest usable model inventory.

1. OpenCode Zen — free, no key. When no local model fits, this costs

nothing, so it comes before anything metered. Its free tier includes models that outscore paid tiers further down this list.

1. Codex — spends ChatGPT quota, roughly 10k+ tokens even for a trivial

prompt. Real money; don't loop it carelessly.

1. Antigravity — a separate meter again, and the only route to Gemini

and GPT-OSS.

1. Claude Haiku for bulk work that must stay on Claude; **premium

Claude** (yourself, Opus-class subagents) reserved for core reasoning, architecture, security-sensitive work, and final review.

• Privacy — state it honestly. Only local engines keep data on the

machine. Everything else is somebody's cloud, including Claude itself: this conversation already goes to Anthropic, Codex goes to OpenAI, Antigravity to Google, Zen to OpenCode and its upstream provider. A rule phrased as "never send to a third-party cloud" would forbid the harness you are running in, so don't pretend to follow one.

The real distinction is account-bound versus anonymous. Codex, Antigravity and Claude run under the owner's own accounts, with terms and a relationship attached. Zen's free tier is anonymous — no key, no account, no data-handling commitment tied to him, and no controllable quota.

So: for genuinely sensitive material — secrets, credentials, private client code, anything he has said not to share — use local models only, and ask first if you are unsure. For ordinary work, all of these are already in play every day; pick on cost.

• Open source first. Where an open-weights model can do the job, prefer it

— over a paid API model, and when choosing what to pull. This is the owner's standing preference and it is not only about cost: open weights keep data on the machine when run locally, cost nothing per call, and cannot be deprecated out from under you. It is also no longer a capability sacrifice — on the open data (scripts/benchmarks.sh --open), leading open-weights models score above several paid tiers this skill routes to. Check before assuming the paid option is better.

⚠️ "Open weights" means downloadable, not runnable. Before treating a high-scoring open model as a local option, check its size against free RAM. The top open model on that list is 2.8T parameters and needs 8× H200 — it is an API option with better licensing, not something this machine will host. Three separate questions: is it good (the data), can I run it (size vs RAM, see references/local-backends.md), and can I reach it another way (API providers, or Antigravity's free gpt-oss-120b). A big open model reached over an API is not private — the privacy rule applies to it exactly as it does to Codex.

Local model output is raw material: it never ships unreviewed. You (or a Claude subagent) review before it counts.

Tier assignments are claims about capability — ground them. Run scripts/benchmarks.sh rather than recalling a ranking. It pulls Epoch AI's open benchmark data (CC-BY, no account, no API key), refetches itself when the cache is over a week old, and marks open-weights versus API-only, so local and cloud sit on one scale:

scripts/benchmarks.sh --open              # best open-weights models
scripts/benchmarks.sh --measure coding    # code work specifically
scripts/benchmarks.sh --model deepseek    # one family

A measured result on this machine still outranks a leaderboard — use the data to pick what to try, and a receipt to decide what to keep. Never invent a score: the data is one curl away, so a number without a call behind it has no excuse. Details, other measures, and the attribution CC-BY requires are in references/benchmarks.md.

Choose the local engine by model inventory

Do not assume or hard-code a particular local LLM engine. Discover the local engines available on the machine using their live CLI, API, or other native model-listing mechanism. Count the models that are reachable, fit the hardware, and can satisfy the current task; then use the engine with the largest usable local model inventory. After choosing the engine, select the best task-fit model from that engine. If it cannot provide a suitable model, fall back to the next-largest usable inventory.

Treat the inventory as session state: verify the engine and model list before the first routed call, cache the result for the session, and do not rank engines by brand, remembered defaults, or a stale notes file. If two engines tie, prefer the one with the best task-fit model and the simplest healthy call path.

Discover lazily, prove before claiming

Do NOT run a discovery sweep just because this skill loaded. Probe a backend the first time you're about to route real work at it, probe only the backends you're considering, and cache the result for the rest of the session.

| Backend | Probe | Healthy looks like | |---|---|---| | Each local engine | Its live model-list command or API | Reachable model list and capability metadata | | OpenCode Zen | GET https://opencode.ai/zen/v1/models | JSON list, no key sent | | Codex CLI | codex doctor | active model, auth mode, install health | | Antigravity | agy models | model IDs + display names | | Claude subagents | always available (Agent tool) | — |

agy is usually not on PATH — on Windows it's at %LOCALAPPDATA%\agy\bin\agy.exe. Record the real path in local-notes. codex doctor beats --version + login status: one call, and it reports the configured model too.

A backend counts as available only after it has returned a one-word smoke reply in this session (scripts/call_local.sh "Reply with exactly: OK" 512 for local backends). The probe and the smoke test are one step, not two. Report the resulting roster to the user as a single line.

If a local engine isn't responding but its CLI exists, you may start it using the engine's documented command. Sandbox guard: some sessions (e.g. a cloud-hosted Cowork or Claude Code environment) run in a container where localhost is not the user's actual machine. If you start a server and it reports an empty model list but the user says they have models installed, you almost certainly started a fresh instance inside a sandbox that isn't their real machine — stop, tell the user, and do not pull models to "fix" it. If you're unsure whether this session runs locally or in a cloud sandbox, say so rather than assuming.

A missing backend is a one-line ask, never a blocker. Say what's missing and how to enable it ("Codex CLI isn't installed — install the Codex app or npm i -g @openai/codex and log in, and I'll use it next time"), then keep working with whatever IS available.

How to call each backend

Local model engine — use the bundled script when compatible

scripts/call_local.sh [max_tokens] sends an Anthropic-format request to /v1/messages and automatically falls back to OpenAI-format /v1/chat/completions if that 404s (older builds). It prints the reply on stdout and a [receipt] token-usage line on stderr — keep that receipt; it backs any claim that the backend did work.

Read references/local-backends.md for local endpoint requirements, selection guidance, model capability checks, and RAM rules. Two things worth knowing up front — tool support is a property of the model, not the server (a coder-tuned model may have no tool training at all), and embeddings are nearly free and excellent for deduping or clustering a batch before you spend model calls on it.

• The endpoint does not have to be this machine. call_local.sh takes a base

URL, so use the selected engine's compatible endpoint and model identifier. Ask the user for a remote URL; do not scan the network for one. ⚠️ A remote endpoint is not private: the privacy guarantee comes from localhost, not from the word "local." Treat a non-localhost URL exactly like a third-party cloud backend and get an explicit OK before sending anything sensitive.

• Reasoning-style local models spend hidden "thinking" tokens before visible

output — a small max_tokens can return empty text. Always give at least a few hundred; the script defaults to 1024.

• Concurrency: keep local calls to 1–2 at a time. Local engines serialize

or thrash under parallel load, especially when requests force model swaps.

• Ask a small local model for constrained plain text, NOT JSON schema.

Measured on the same model and prompt: a one-word answer scored 12/12 on a real classification batch, while a native schema mode got 1 of 3 wrong, and adding a free-text string field to the schema made it degenerate into a 600-token repeat loop. Schema-forcing costs accuracy at this size. Want structured output? Either parse the one-word replies yourself, or route to a tier that handles schemas well — agy --json-schema or codex --output-schema.

OpenCode Zen — free cloud, same script

The bundled script reaches it too; it is an OpenAI-dialect endpoint, so state the dialect rather than letting auto probe:

CALL_LOCAL_DIALECT=openai scripts/call_local.sh \
  https://opencode.ai/zen deepseek-v4-flash-free "your prompt" 1024

• No API key and no account. GET /v1/models lists 61 models; the ones

ending -free cost nothing. Verified 2026-08-09 from this machine: a one-word reply in 9.1 s, [receipt] in=88 out=21, no credentials sent.

• State the dialect. auto probes /v1/messages first and Zen serves that

path only for paid Claude models, answering 401/400 for free ones — a 400 is usually a genuine bad request, so the fallback deliberately does not retry on it. CALL_LOCAL_DIALECT=openai skips the wrong guess entirely.

• Use it when no local model fits and the work is not sensitive. It is free,

so it beats spending ChatGPT or Claude quota. On the open benchmark data deepseek-v4-flash-free scores 152.53, above gpt-5.4-mini at 148.91 — a paid tier further down this ladder. Check with scripts/benchmarks.sh rather than trusting that number's freshness.

• Anonymous means unaccountable. No key means no terms tied to the owner

and no controllable quota. Fine for ordinary work; for secrets, credentials or private client code, stay local.

Codex CLI

codex exec -m  -s read-only --skip-git-repo-check "task"

Read references/codex.md before routing work here. It holds the model capability table, two cost traps that reverse the obvious choice, the discovery rules, and the rest of the CLI surface.

• **Choosing the model is YOUR call, made on capability — not a quota question

you put to the user. These models have distinct, published strengths: bulk grunt work → gpt-5.6-luna (or gpt-5.4-mini when the batch has images or long inputs); fast interactive code edits → gpt-5.3-codex-spark; review, audits and long agentic runs → gpt-5.6-sol. Ask the user only if a call actually fails on quota. These slugs are prose, not a live source — they will drift.** scripts/codex_models.sh --list reads Codex's own model cache; check it before trusting a slug you have not used recently.

• Get the ID exactly right. A wrong model ID returns `400 … not supported

with a ChatGPT account`, which reads like "no access" but means "no such model." Don't generalize one rejection into "that tier is unavailable."

• codex review is purpose-built for reviews — prefer it over hand-rolling

a review prompt through exec.

• --output-schema gives schema-validated JSON instead of prose to

parse. Use it for batch work.

• --oss --local-provider runs Codex's own agent loop against a

local model — Codex's tooling and sandboxing at zero API cost. Query the installed CLI's live help for supported provider values, then pass the engine selected by the model-inventory rule above.

• Keep -s read-only for questions and reviews. The default is

workspace-write with approval=never — it WILL edit files without asking.

• Multi-turn: codex exec resume --last "follow-up".

Antigravity (agy)

agy -p "task" --model gemini-3.6-flash-low
agy -p "task" --model  --output-format json --json-schema schema.json

The best structured-batch surface on this machine — verified 2.1 s for a schema-validated classification, with a token receipt in the same JSON. --json-schema requires --output-format json, or it errors.

• agy models lists what's available — free, first-class, no equivalent in

Codex. Use it instead of guessing.

• Reaches models nothing else here does: Gemini and GPT-OSS 120B, plus

Claude Sonnet/Opus 4.6 on a separate meter from Claude quota.

• ⚠️ It injects a large system prompt — ~27k input tokens even for a one-line

request. Fast and structured, but not cheap per item; for very large batches weigh it against a local model.

• Details and flags: references/cross-agent.md.

Agents driving agents (MCP)

codex mcp-server makes Codex an MCP server over stdio, so any MCP client — Claude Code, Cowork, Antigravity — can call Codex as a native tool instead of shelling out and scraping stdout. It exposes codex (run a session) and codex-reply (continue a thread).

Register it in the client's MCP config with the absolute path to the real executable, not a PATH shim — .cmd wrappers commonly fail to spawn under stdio MCP. Recipe and a verified end-to-end run are in references/cross-agent.md.

**A call through a bridge spends the callee's quota.** Routing Antigravity → Codex bills Codex, not Antigravity. That's useful when one

…

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: scottconverse
• Source: scottconverse/multi-model-routing-skill
• License: MIT
• Homepage: https://scottconverse.github.io/multi-model-routing-skill/

Install and usage instructions live in the source repository linked above.