The short answer
- Start from the subscription you already have. Larkway injects no API key; the subprocess reuses the local CLI login. A Claude subscription means Claude Code; a ChatGPT subscription means Codex. If you have both, read on.
- With both, mix per bot role. One bridge runs several bots, and each bot names its
backendin its own yaml. The team does not have to pick one engine. - Switching is nearly free. Change one line —
backend: claudeorbackend: codex— and restart the bridge. The L2 memory and the repository's rules work for both.
Five dimensions
| Dimension | Claude Code | Codex |
|---|---|---|
| CLI | claude | codex |
| Auth | local login state (~/.claude/.credentials.json); run claude once to log in | codex login |
| Billing | existing Claude subscription, not per token | existing Codex subscription, not per token |
| Permission model in Larkway | Agent Workspace mode uses --permission-mode acceptEdits; Bash commands pass through an allowlist, extendable via permissions.allowExtra in config.json | --sandbox workspace-write; wider permission modes map to the bypass flag |
| Session resume | thread ↔ session_id, follow-ups use --resume | thread ↔ session via Codex's resume mechanism |
| Rules and skills it reads | CLAUDE.md, .claude/skills, user-level ~/.claude/skills | AGENTS.md, .agents/skills, user-level ~/.agents/skills |
| Model and reasoning effort | yaml model / effort pass through as --model / --effort | yaml model / effort pass through; effort is mapped to Codex's levels |
| Startup preflight | larkway doctor checks the login | larkway doctor also verifies the Codex state directory is writable |
There is no "which model is smarter" row, because that answer changes monthly and depends on the task. Treat them as two usable executors and split by role, as below.
Assign by bot role
Read-only Q&A bots
"Where is this metric computed", "who calls this endpoint". Both engines handle it; pick the one whose subscription has more headroom. These bots are called most often, so cost matters.
Engineering bots that write code and open PRs
What matters is a clear permission boundary. On the Claude Code side Larkway uses acceptEdits plus an allowlist, giving command-level control — good when you want to state exactly "what it may run". On the Codex side the sandbox does the work: workspace-write only writes inside the workspace, a natural fit for "do not touch anything outside the project". Both are safe; it depends on which way of expressing the rule you prefer.
Bots that read a lot of project rules and skills
Look at what your repositories already contain. A team with a pile of CLAUDE.md files and .claude/skills should use Claude Code; one with AGENTS.md and .agents/skills should use Codex. Larkway's L2 memory tells the agent which files to read, but the files must be in a format it recognises.
A low-effort trick: make CLAUDE.md a symlink to AGENTS.md, keep skills in ~/.agents/skills and symlink that to ~/.claude/skills. Both engines then read the same rules.
When you need independent review
An executor has seen its own process; self-review is unreliable. A common setup: the engineering bot works on one engine, and a reviewer bot on the other engine looks only at the artefacts — the diff, the test results, the files written. Switching engine means switching "brain", with fewer shared blind spots.
How to switch
id: dev-helper name: Dev Helper backend: codex # claude | codex model: gpt-5.6 # optional, passed to the CLI effort: medium # low | medium | high | max runtime: agent_workspace # then restart the bridge $ larkway stop && larkway start
Run larkway doctor before switching: it checks, bot by bot, that the matching CLI is logged in and that the Codex state directory is writable.
What both engines share
- Both run on your own machine; code and credentials never pass through a third-party cloud.
- Neither needs a public port; Feishu events arrive over a persistent WebSocket.
- Neither is orchestrated by Larkway. Larkway handles the Feishu connection, card rendering, subprocesses and sessions; how to branch, commit and when to stop and ask lives in your repository's agent guide.