Models
One model directory and one inference path, through LLMGateway.
All model discovery and inference go through LLMGateway. Work on Repeat does not call model vendors directly, and holds no vendor keys of its own.
Model selection
The dashboard offers the flagship slice of the LLMGateway directory — the
most-used, tool-capable model per provider family, mirroring the
LLMGateway rankings — rather than all ~250
directory entries. The picker is a searchable command palette grouped by
provider; entries the directory marks deactivated never appear. The directory
is public, so the list loads whether or not LLM_GATEWAY_API_KEY is set; the
key is required for inference, not for discovery.
A routine stores the selected model identifier, for example:
claude-sonnet-5The API rejects identifiers that are not in the current flagship directory
with 400 invalid_model.
If the directory is unreachable, the API serves a bundled snapshot of the same
flagship set so the picker keeps working, and GET /v1/models returns
502 model_directory_unavailable only when even that path fails. The snapshot
is a fallback, never a substitute for the live directory.
Choosing a model
The right model depends on what the routine actually does, not on which is newest.
| The routine… | Favour |
|---|---|
| Summarises or reformats data it is given | A smaller, faster model. |
| Reasons across many tool results before concluding | A stronger reasoning model. |
| Writes prose someone will publish | A model you have read output from. |
| Calls tools at all | Any tool-capable model — required. |
| Runs frequently on large inputs | Cost per token matters; check usage traces. |
Because the model is routine configuration, changing it is a one-field edit —
but it returns the routine to draft and requires a fresh proof run. That is
intentional: a different model is a different behaviour.
Comparing models honestly
Run the same routine on two models and compare the traces, not the prose. The questions worth asking:
- Did it call the tools it needed, or answer from assumption?
- How many steps did the same work take?
- What did it cost, from the run's recorded usage?
- Would the output survive a week's delay before someone reads it?
Local fixture mode
Local development can explicitly set DEMO_MODE=true to use a deterministic
model fixture. This makes onboarding, scheduling, persistence, and browser
tests reproducible without pretending to perform live inference.
Production rejects both demo mode and a missing LLM_GATEWAY_API_KEY — the
service refuses to start rather than silently degrading. Set the gateway key in
the API service environment and never commit it to source control.