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 loads the complete LLMGateway model directory — currently
around 250 models across more than twenty provider families — and groups the
picker by provider. The directory is public, so the full 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:
openai/gpt-5-miniThe API rejects identifiers that are not in the current directory with
400 invalid_model.
Models that cannot call tools are listed but labelled, because a routine that relies on approved MCP tools cannot use one.
If the directory is unreachable, the API serves a bundled snapshot of
tool-capable models 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.