Compare
Bernstein vs every CLI coding agent
Bernstein is the open-source governance layer for AI agents: it wraps 40+ CLI coding agents and runs them in parallel git worktrees under a deterministic scheduler. Pick the agent you already know.
Claude family (Anthropic)
- Claude Code vs Bernstein - Claude Code is Anthropic's official terminal-native coding agent.
- Cursor Agent vs Bernstein - Cursor publicly launched a real terminal CLI on 2026-01-16 and shipped a v3 agent-first UX in April plus the Cursor SDK in May 2026, all sharing the same `cursor-agent` binary surface.
CLI adapters
OpenAI family
FAQ
Five operator-written Q&A blocks covering the most common decision points when picking an orchestrator.
Does Bernstein replace my existing CLI coding agent in 2026?
No. Bernstein wraps your existing agent as one of forty-plus adapters and adds the governance layer on top: parallel git worktrees, quality gates between merges, an HMAC-chained audit log. The agent itself (Claude Code, Codex, Cursor, Aider, Gemini, and the rest) still does the editing. If your task is a single interactive session with one model on one repo, running the agent directly is the right answer; adding an orchestrator on top is overhead.
How is Bernstein different from a TUI wrapper?
Two things. First, Bernstein is a deterministic Python scheduler; it does not call an LLM to decide which agent gets which task. Second, every task lands in its own git worktree and only reaches the working branch after a gate set (lint, types, tests, plus optional security scan and cross-model review) passes. A TUI wrapper is an ergonomics layer on top of one session; Bernstein is a state machine on top of many.
Can I run Claude Code and Codex in the same plan?
Yes. A plan YAML is a list of stages, each holding steps; a step names its adapter with cli:. A common shape is Claude on architect roles, Codex on test-writing, Cursor on quick edits, Aider on refactor jobs. Bernstein routes each task to the configured adapter, spawns it in its own worktree, and merges what passes. There is no shared session state across adapters; each one runs its own process.
What does the audit chain protect against?
After-the-fact log editing. Each line in .sdd/audit/<YYYY-MM-DD>.jsonl carries the previous line's HMAC; modifying any earlier line breaks the chain at the next verification. The chain does not protect against an attacker who controls the HMAC key at write time (that is a different threat model). It does prove that a third-party reviewer who gets the log later can verify whether the run they are reading is the same run that was written.
Where is the comparison data verified from?
Each per-agent page links its primary sources at the top: the upstream project's README, the upstream docs page, and the bernstein adapter source under src/bernstein/adapters/<slug>.py. The verified-on date on each page is the day the operator last walked the source list and refreshed the matrix. If a row is out of date open an issue on the bernstein repo.