Multi-vendor AI routing, and why your backlog never stalls

The first version of Forge had a single point of failure with a logo. When the model we used to implement issues was rate-limited, the entire pipeline stopped. Issues piled up. The whole promise — describe it and it ships — quietly broke.

So we made routing a configuration decision, not a hard-coded one.

One file decides who does what

Every routing decision — which provider, which model, and why — comes from a single config file and a shared routing function. No provider or model is baked into the pipeline.

models:
  default: "claude-opus-4-7"
  claude_tiers:
    opus: "claude-opus-4-7"
    sonnet: "claude-sonnet-4-6"
    haiku: "claude-haiku-4-5"
  codex: "gpt-5.5"
routing:
  claude_workflow: "claude"
  codex_workflow: "codex-review"

The fallback ladder

When the primary vendor is unavailable, the loop walks a ladder instead of giving up:

1. Claude implements the issue on a branch.
2. If Claude is down, OpenAI picks up the same task.
3. If that’s unavailable, Gemini takes it.
4. Review runs on a different vendor than the implementation, so no model grades its own homework.

The result: the week one vendor had an outage, our customers’ backlogs didn’t notice. Routing decisions are printed into every run’s summary, so you can always see which model did which job and why.

Why a second vendor reviews

A reviewer that shares weights with the author shares blind spots. Routing the PR review to a different vendor catches a category of bugs the implementer is structurally bad at seeing — and it blocks auto-merge on any blocker or major finding.