The easy answer: set both keys. Cerebras and Groq serve the same gpt-oss-120b weights over wire-compatible APIs, so OpenCues treats them as a pair, and each automatically becomes the other's failover on rate limits and outages.
Where they differ
- Cerebras is OpenCues' default provider and the one it optimises hardest for. Its automatic prompt prefix caching hits a measured 99.5% cache rate on OpenCues' large static system prompts, saving roughly 300-500ms of time-to-first-token per call; warm calls land around 445ms. On the project's provider bench it also won fluid-blank quality (12 of 12 versus 10 of 12 on the segmenting pass) and long-prompt latency.
- Groq wins short-prompt time-to-first-token, and it's cheaper: at the May 2026 snapshot, $0.15/$0.60 per million tokens in/out versus Cerebras at $0.35/$0.75, roughly half the cost for the same weights (check current pricing pages before deciding on cost).
The recommended split
The project's own recommended routing uses both: Groq as the global default for short-prompt surfaces (word cues), Cerebras for the long-prompt surfaces (fluid blank, agent rewrite) where its quality and long-input speed showed up in the bench. Configuration is a few lines in OPENCUES.md, and per-bucket scalars let you route cues and blanks independently.
The failover is the quiet win
With both keys set, a transient failure (HTTP 429, a 5xx, a network blip, an empty body) triggers an automatic retry against the peer: the runtime rewrites the URL, swaps the auth header, translates the model name between the two providers' formats, and returns the fallback's response transparently. Inline assistance degrades gracefully instead of going quiet during one provider's bad hour.
Related: LLM providers for OpenCues · How OpenCues stays fast · Ollama vs cloud · GitHub repo