What CodeLynq does with coding agents
A development run is dispatched to one of three headless coding agents: Claude Code, Grok, or the OpenAI Codex CLI. It is an organisation setting, not a per-task one, and it defaults to Claude Code.
What surrounds the agent is identical either way. The same technical spec goes in. The same verify command runs afterwards, the same self-review pass reads the diff, the same security scan looks for secrets, and the same pull request comes out with the same unresolved findings written into its body. The agent is a component, deliberately — everything that makes the output reviewable sits outside it.
Setting it up
- Install the CLI you want on whatever executes your runs — our workers if you use the hosted platform, your own machine if you run a self-hosted runner.
- In organisation settings, choose the agent under Development Model.
- For Claude Code, optionally pin a model. Grok and Codex use their own configured model instead.
- Start a run. The provider is recorded against it, so you can compare outcomes later.
Worth knowing
The CLI has to be present where the run executes. If it is missing the run fails and says so, naming the agent and the setting to change — rather than silently falling back to a different one, which would make a provider comparison meaningless without you ever noticing.
Credentials stay separated. A key you bring for one provider is never forwarded to another’s CLI, and neither is a model name: a Claude model left in your settings is not handed to Grok or Codex, because that would fail in a way that looks like a provider problem rather than a configuration one.
Model routing — picking a cheaper or stronger model per task — currently applies to Claude Code runs. Grok and Codex use the single model you configure for them.