Skip to main content
Outrider’s coding runtime speaks whichever model-API family its coding agent speaks, so it can be pointed at any compatible endpoint. That makes the model backend a first-class choice per agent. The loop, guardrails, and refinement chain are identical on every backend; what changes is cost, latency, and the models on offer: An unset provider leaves the caller’s own auth untouched, which is what installs written before the input existed rely on. Which providers a run can reach depends on the coding agent it runs: an agent speaks one model-API family and a provider serves one or more. OpenRouter serves every agent. The higher timeout for Z.ai and Moonshot exists because their flagship models’ thinking modes add per-turn latency; a GLM session routinely takes 15–20 minutes. The provider and model inputs are independent: provider names the endpoint, model picks the model from it (e.g. glm-5.3 / glm-5.2 / glm-4.6 on Z.ai; kimi-k3 / kimi-k2.7-code on Moonshot; claude-opus-4-8 / claude-sonnet-4-6 / claude-haiku-4-5 on Anthropic). In the app, the agent and its backend are set in the agent setup wizard and editable later under the agent’s Configuration. Connect each key once under Connectors; Remyx pushes it to the repo as a secret at provisioning time.

​
The provider input

In workflow YAML, one input wires the whole backend — auth env var, base URL, and mutual exclusion between the two auth styles:
Pass every backend’s secret in the step’s env: block — the action reads only the one matching provider, so a single workflow can switch backends per dispatch. This input replaced the fork-side “Configure provider auth” case-switch step older workflows carried; an empty provider preserves the old behavior exactly, so existing installs need no migration. The action fails clean with a specific error if the selected provider’s secret is missing (e.g. provider=zai requires ZAI_API_KEY in the caller's env block).
Don’t set both ANTHROPIC_API_KEY and ANTHROPIC_AUTH_TOKEN yourself: with both set the runtime sends both headers, so an unrelated Anthropic key travels to whichever gateway the run is pointed at. Naming a provider is what prevents it, and is most of why the input exists. The action builds the agent’s launch environment explicitly and puts exactly one credential in it, the one that provider needs; nothing in a caller’s workflow can add the other back.
Use model-base-url directly (instead of provider) only for custom or on-prem endpoints: Bedrock, Vertex, or a proxy of your own. Set alongside a named provider it still wins, since a gateway in front of that vendor is the usual reason to pass both. The run warns that it has overridden the registry endpoint and that the provider’s credential is going there.

​
The agent input

provider picks the model; agent picks the coding-agent CLI that drives the implementation. The two are independent axes. Each agent speaks one model-API family, so which providers it can reach follows from that: Set the agent in the setup wizard, in the workflow file, from the CLI (--agent), or per dispatch. An unset agent resolves to claude, so workflows written before the input existed keep running unchanged.

​
Which pairs work

Every pair above except custom has been verified end-to-end against the vendor. A pair whose two halves don’t share an API family is refused before any work starts, naming the agent that does serve that provider:
The pairs come from the action’s own registry, published as agent-matrix.json. The CLI and the engine read that contract instead of keeping their own copies, so the three stay in step.
OpenRouter reserves the requested max_tokens against your balance before calling the model, and both CLIs request a lot by default (Codex’s is 131,072), so a thin balance answers HTTP 402 before the model is reached.

​
What each agent can report

An agent can be partially capable and still usable: the affected telemetry degrades, the run doesn’t fail. What a missing capability costs:

​
Models, per agent

All three agents take the same model input; the action sets that agent’s own model variable (ANTHROPIC_MODEL, CODEX_MODEL, BACKBOARD_MODEL). Backboard addresses models as <provider>/<model> and has no default of its own, so name a model with it. The action composes provider: openai plus model: gpt-5.4-mini into openai/gpt-5.4-mini, and leaves an already-qualified id alone. Routing Codex off OpenAI’s own endpoint pins two request fields for you, because Codex fills them from its own model catalog and an unrecognized model leaves them in a shape strict gateways reject: web_search="disabled" (the server-side tool is OpenAI’s, not part of the protocol) and model_reasoning_effort="medium" (OpenRouter answers Reasoning is mandatory for this endpoint without it). Neither is applied on OpenAI, where Codex’s per-model defaults win. A Chat-Completions-only provider needs a translating gateway in front of it, since codex exec requires a Responses endpoint. Z.ai is the case people hit first: it serves Anthropic Messages, and its OpenAI-compatible surface is Chat Completions (/v4/responses answers 404), so agent: codex with provider: zai is refused rather than failing mid-run. GLM under Codex goes through a router that speaks Responses, provider: openrouter with model: z-ai/glm-5.3, or through your own gateway on provider: custom.

​
Verify a pairing before you spend a run

mode: smoke resolves the routing, runs the agent’s preflight, and makes one trivial call in about 30 seconds, without cloning the repo or opening anything. It reaches the vendor for real, so it catches a wrong secret, a bad endpoint, a model id from another vendor’s vocabulary, or an exhausted quota. The run reports smoke_ok or smoke_failed:
Run it after changing agent, provider, model, or a secret, instead of waiting on a full dispatch to find out. A setup-local workflow declares mode, agent, provider, and model as dispatch inputs, so the same check runs from the Actions tab or gh workflow run. Every key above can be connected once under Connectors, and Remyx pushes it to the repo at provisioning time. A setup-local install skips that path and sets the secret itself:

​
The two-tier drafter-refiner pattern

The recommended default for a repo you want worked continuously. It splits exploration and commitment into two workflows: Workflow 1: Drafter — daily, budget tier, publish: branch
  • Pushes draft branches only: no PRs, zero maintainer-facing noise. ~$0.20–0.40/run.
  • Each run accumulates repo intel — landing zones that worked, mechanism shapes that got rejected.
Workflow 2: Refiner — weekly, strong tier, publish: pr
  • Picks the best drafter branch and generates a mechanism-level gap analysis against its source paper.
  • Re-runs from that branch (start-from-ref) with the gap analysis as its brief (lead-content), through the full refinement chain, to a draft PR. ~$5–10/week including the gap generation.
Why the split works: the drafter’s branch anchors an extension point and test scaffolding, so the refiner commits to PR-shape on borderline cases; a budget tier makes daily exploration of the arXiv frontier (~200 ML papers/day) rational; even failed branches contribute negative-space signal to the next pick. Set it up from the wizard’s Advanced — models per phase → Two-tier option (writes three workflows: the dispatch-capable main one, the drafter, the refiner), or from the CLI. Tier pairings are cross-provider and switchable — the app defaults to a GLM drafter with an Opus refiner:
Runs report their tier (main / drafter / refiner) in fleet telemetry, so Reports → Costs prices each tier separately.

​
Cost telemetry

Every run reports cost_usd, input_tokens, and output_tokens as action outputs and into fleet telemetry. How the dollar figure is computed depends on the backend:
  • Anthropic: the runtime’s own total_cost_usd figure is authoritative.
  • Z.ai / Moonshot: cost is computed from a per-model rate table keyed by the model actually used (glm-5.2, glm-4.6, kimi-k3, kimi-k2.7-code, kimi-k2.7-code-highspeed, …), overriding the CLI’s Anthropic-rate estimate. An unknown model on a known host is priced at that host’s flagship rate and reported as approximated, which can be a 3–4× error across tier pairs, so set model explicitly. glm-5.3 sits there today: it’s the zai default and has no rate row yet.
  • Custom endpoints: the reported figure is an estimate.
  • Agents differ in what they report. One that reports its own dollar figure is used directly; one that reports none resolves through the rate table, and reports unavailable when the host has no rate row. Token counts stay exact in every case. The capability table says which is which.
Each run’s step summary names the pair it ran, such as Agent: Codex → OpenRouter, alongside the cost basis it used. The Costs report turns this into unit economics: runs per day by backend against $ per code artifact.

​
Choosing a backend

There’s no house pick. Every backend runs the same loop behind the same guardrails; the practical variables are per-run cost, session latency, and the draft quality you observe on your repo:
  • Anthropic (Claude) — Claude tiers over x-api-key auth; a full PR run with the refinement chain is roughly $5–6.
  • Z.ai (GLM) — GLM tiers at roughly 20× lower per-run cost; budget the longer timeout for thinking-mode latency.
  • Moonshot (Kimi) — Kimi tiers, same Bearer-auth pattern and timeout guidance as Z.ai.
  • Custom / on-prem — anything that speaks the API family your agent speaks, via model-base-url.
The cheap way to decide is evidence, not defaults: per-dispatch routing (remyxai outrider trigger --provider … --model …) makes A/B-ing providers on the same paper nearly free, and Reports → Costs shows each backend’s cost per code artifact against what its runs actually produced. The two-tier pattern sidesteps the choice entirely: explore on a budget tier daily, promote on the tier your merges say you trust.

Actions

All configuration inputs, guardrails, and run outcomes

Connectors

Connect Anthropic, Z.ai, and Moonshot keys

CLI: provider routing

Per-dispatch provider/model overrides

Backends guide (repo)

The action’s own backends reference