AI routing
How Forge decides which provider and model handles each job, and what happens when one is down.
Routing is config-driven. A single shared function reads forge.config.yml and
maps issue labels to a provider and a workflow. No provider, model, or label is
hard-coded into the pipeline.
The decision
For each issue, routing considers:
- Complexity —
trivial/easy/medium/complex. - Type hints — e.g. a code-review issue routes to the review lane.
- Explicit overrides — a
model/codexlabel forces a specific vendor.
The chosen provider, model, and rationale are printed into every run’s step summary.
Fallback ladders
Implementation: Claude → OpenAI → Gemini.
Review: OpenAI → Gemini → GitHub Models → OpenRouter → defer.
If every configured vendor for a stage is unavailable, the issue is deferred with a label rather than failed, so it’s picked up on the next run.
Why review uses a different vendor
A reviewer that shares weights with the author shares blind spots. Forge routes review to a different vendor than implementation so no model grades its own work.