DEV Community: Alex Chernysh

Orchestration primitive or desktop ADE? Choosing your multi-agent coding layer in 2026

Alex Chernysh — Tue, 21 Apr 2026 14:11:04 +0000

The multi-agent coding tool category went from a handful of projects in late 2024 to thirty-plus by mid-2026. Along the way it split into two shapes that solve adjacent-but-different problems. Here's when to reach for each, and why you might end up using both.

The two shapes

Desktop ADEs. A downloadable desktop application. You install it like any other app, open a window, configure credentials, and see your repo, your agents, and your diffs in a unified UI. Examples in the open-source corner: emdash (Electron app, 23 CLI providers supported, YC W26-funded), Conductor, Cline's desktop mode. Closed-source you'd put in the same category: Claude Code's VS Code extension, Cursor's "run in background" mode.

Orchestration primitives. A library or CLI you import into your own workflow. You don't see a window; you see a process you can pipe into other things. Examples: Bernstein (the project this blog belongs to — 18 CLI adapters, Python-importable), Workz, certain configurations of Plandex. LangGraph and CrewAI are adjacent but different — they orchestrate LLM calls, not CLI coding agents.

The distinction is not about which is better. It's about what layer of the problem you're solving.

What a desktop ADE does well

A desktop ADE gives you:

A visual workspace. Diffs, PR status, CI checks, agent logs all in one window.
Zero-config launch. You open the app, it picks up your repo, agents just work.
Identity handled. Credentials in the OS keychain, not in a .env file that leaks.
Distribution pattern. Electron installers for macOS, Windows, Linux. Your non-terminal colleague can use it.

This shape is the right answer when:

You're the kind of developer who keeps an IDE open all day and wants agents integrated into that workflow, not hidden in a tmux pane.
You're onboarding teammates who don't live in the terminal.
You want one tool that covers edit, review, merge, and CI visibility end-to-end.

What it trades off:

Not programmable from the outside. You can't import emdash or write a CI job that kicks off a parallel agent run via emdash's API. It's a UI, not a library.
Ships with opinionated conventions. Agents live in app-managed worktrees; audit logs live in app databases. Extracting them into another system is possible but not first-class.
Cross-machine coordination is an extra feature (SSH mode, remote runtime) rather than the default shape.

What an orchestration primitive does well

A primitive gives you:

A process you can script. bernstein run --goal "..." | jq . works. So does invoking it from a GitHub Actions workflow, or importing bernstein.core in your Python code.
Deterministic coordination. The scheduler is a regular event loop. Every run is replay-able from the audit trail.
MCP server mode. Your agent-of-choice can talk to the orchestrator through the same Model Context Protocol Anthropic publishes for Claude Code.
Composition. A primitive is one step in a larger pipeline: linter → primitive multi-agent pass → janitor → merge queue → deploy.

This shape is the right answer when:

You want to embed multi-agent coding into a system you already run: CI, internal dev-platform, evaluation harness.
You care about reproducibility. HMAC-chained audit trails give you "did the agent really do exactly that?" answers days later.
You're already in a scripting-first workflow and don't want a new app to keep open.

What it trades off:

No visual diff/merge UI out of the box. You git diff the worktree, or plug it into your existing tools.
Setup needs a terminal. pipx install bernstein && bernstein init, not a double-click installer.
It's one layer of a larger stack. You'll likely pair it with a separate review tool, CI system, and notification channel.

Decision shortcuts

Building a product on top of multi-agent coding? Reach for a primitive. Libraries compose; apps don't.
Onboarding a team that wants a single download? Reach for a desktop ADE. Developer ergonomics of an opinionated installable app is hard to beat for non-power-users.
Running agents as part of CI / evaluation / internal platform? Primitive, nearly always.
Running agents on your own laptop during normal dev work? Either works; it's a preference question. Try both for a week.
Need to prove to compliance or security "here's exactly what happened"? HMAC audit trails live in the primitive layer. ADE output logs are usually app-scoped.

They often co-exist

Nothing prevents running both. A pattern we've seen in Bernstein's early users:

Bernstein in CI for the "every PR gets a lint-plus-refactor agent pass" step.
Desktop ADE for interactive "I'm pairing with Claude Code on this refactor" flow.
Bernstein's MCP server mode exposed to the ADE so both see the same audit trail.

If you're already using a desktop ADE and it covers what you need, keep it. If you hit the "but I want to run this from a shell script / from CI / inside another service" wall, that's the signal to look at a primitive, regardless of which specific one.

Bernstein's specific positioning

Bernstein is the primitive-shape tool. What we optimize for:

Deterministic coordinator written in plain Python — no LLM in the scheduling loop, so runs are reproducible.
HMAC-chained audit trail — every agent action is replay-able bit-for-bit days later.
MCP server mode — expose Bernstein to any MCP-capable client (Claude Code, Cursor, or your own agent).
18 CLI adapters including Claude Code, Codex, Cursor, Aider, Gemini CLI, OpenAI Agents SDK, Amp, Cody, Ollama, and more.
Apache 2.0, BYOK, pipx install bernstein.

What we don't build: a desktop UI. If you need one, emdash and Conductor both do that well and are worth trying.

The category is large enough to have multiple right answers. The question is which layer of your stack you're optimizing for. A primitive and an ADE are not competing with each other. They're competing with the "write a bunch of glue code to make two agents work on the same repo without destroying it" option — which nearly everyone used until twelve months ago, and which neither shape is going back to.

From 4,000 Lines to 200: Decomposing Bernstein's Core

Alex Chernysh — Tue, 21 Apr 2026 14:10:28 +0000

Bernstein's orchestrator.py hit 4,198 lines. We used 11 parallel agents, orchestrated by Bernstein itself, to decompose it into 15 sub-packages in the first pass, each under 400 lines. Subsequent refactors extended this to 22 sub-packages. Here's how that worked and what we learned.

How a file gets to 4,000 lines

It happens gradually. The orchestrator started as a clean 300-line module that managed a tick loop: check for tasks, spawn agents, collect results. Then it grew. Cost tracking logic. Quality gates. Token monitoring. Git worktree management. Heartbeat detection. Idle agent recycling. Shutdown coordination.

Each addition was small and reasonable. But after two months of active development, orchestrator.py was a 4,198-line monolith that imported 47 modules and had 23 public methods. The test file was 2,800 lines. IDE navigation was painful. Merge conflicts were constant because every feature touched the same file.

The rule we now follow: if a module crosses 600 lines, it's time to decompose.

The plan

We defined 15 target sub-packages, each responsible for one concern:

Sub-package	Responsibility	Lines (after)
`orchestration/`	Lifecycle, tick pipeline	~350
`agents/`	Spawner, discovery, heartbeat	~380
`tasks/`	Task store, retry, scheduling	~340
`quality/`	Quality gates, CI monitor	~290
`cost/`	Cost tracking, budgets	~310
`tokens/`	Token monitoring, intervention	~250
`security/`	Audit logs, policy engine	~270
`git/`	Worktree management, merge queue	~280
`persistence/`	WAL, checkpointing	~220
`planning/`	Plan loading, dependencies	~200
`routing/`	Model selection, bandit	~320
`communication/`	Bulletin board, messaging	~180
`server/`	Task server, API	~260
`config/`	Configuration, defaults	~190
`observability/`	Metrics, tracing	~240

The decomposition needed to be backward-compatible. Existing code importing from bernstein.core.orchestrator import Orchestrator had to keep working.

11 agents, 15 packages

Here's the recursive part: we used Bernstein to execute the decomposition. A YAML plan defined 15 extraction stages with dependency edges (e.g., tasks/ had to be extracted before agents/ because the spawner depends on the task store).

11 agents ran in parallel across independent sub-packages. Each agent:

Extracted the relevant functions and classes from orchestrator.py
Created the new sub-package with proper __init__.py exports
Updated all internal imports
Ran the sub-package's tests to verify nothing broke

The whole decomposition took about 3 hours of wall time. A human doing this manually — carefully moving code, fixing imports, running tests after each change — would spend 2-3 days.

The re-export shim pattern

Backward compatibility was the hardest constraint. We solved it with re-export shims. The original orchestrator.py became a thin file that imports from sub-packages and re-exports:

# src/bernstein/core/orchestrator.py (after — ~200 lines, down from 4,198)
"""Orchestrator shim — re-exports from sub-packages for backward compat."""

from bernstein.core.orchestration.lifecycle import Orchestrator
from bernstein.core.orchestration.tick import TickPipeline
from bernstein.core.orchestration.manager import OrchestratorManager
from bernstein.core.orchestration.shutdown import ShutdownCoordinator

__all__ = ["Orchestrator", "TickPipeline", "OrchestratorManager", "ShutdownCoordinator"]

Every existing import path works unchanged. New code imports from the specific sub-package. Over time, the shims can be deprecated.

What we learned

Dependency graphs matter more than you think. The extraction order was critical. Extracting git/ before tasks/ would have created circular imports because the merge queue references task completion callbacks. We had to map the dependency graph before writing the plan.

Tests are the safety net. Each extraction step ran the full test suite. We caught 14 import errors, 3 circular dependencies, and 1 subtle bug where a function relied on module-level state that moved to a different file. Without tests, at least half of those would have shipped broken.

600 lines is a good limit. After the decomposition, the largest sub-package is agents/ at ~380 lines. Every module is small enough to read in one sitting, grep effectively, and test in isolation. When a new file starts approaching 600 lines, we split it proactively.

Orchestrators can orchestrate themselves. There's something satisfying about using your own tool to refactor itself. The decomposition was one of our most complex multi-agent runs, and it validated that the parallel execution model works for real refactoring tasks, not just greenfield code generation.

The result

Before: 1 file, 4,198 lines, 47 imports, constant merge conflicts.
After: 15 sub-packages in the first pass (extended to 22 in later refactors), ~280 lines average, clean dependency boundaries, agents can work on different packages without conflicts.

The full source is on GitHub. The re-export shims are in the top-level files like orchestrator.py, spawner.py, and task_lifecycle.py.

Getting Started: Your First Multi-Agent Run in 5 Minutes

Alex Chernysh — Tue, 21 Apr 2026 14:09:52 +0000

This guide gets you from zero to a working multi-agent session in under 5 minutes. You'll install Bernstein, configure Claude Code as your agent, run a goal, and understand the output.

Step 1: Install Bernstein

Bernstein requires Python 3.12+. Install it with pip or uv:

pip install bernstein

Or if you use uv:

uv pip install bernstein

Verify the installation:

bernstein --version
# bernstein 1.8.8

Step 2: Configure your agent

Bernstein needs at least one CLI coding agent installed. The fastest setup uses Claude Code, but 18 agents are supported including Codex, Gemini CLI, the OpenAI Agents SDK, Aider, and more.

Make sure Claude Code is installed and your API key is set:

# Install Claude Code if you haven't
npm install -g @anthropic-ai/claude-code

# Set your API key
export ANTHROPIC_API_KEY=sk-ant-...

Bernstein auto-detects installed agents. Verify it finds yours:

bernstein agents
# Available agents:
#   claude (Claude Code) ✓

Step 3: Run your first goal

cd into any git repository and run a goal:

cd your-project
bernstein run --goal "Add type hints to all functions in src/utils.py"

Bernstein will:

Decompose the goal into concrete tasks
Assign each task a role, priority, and model
Spawn agents in isolated git worktrees
Monitor progress via heartbeats and output parsing
Merge completed work back to your branch

Step 4: Read the TUI

The terminal UI shows live progress:

┌─ Bernstein v1.8.8 ─────────────────────────────────┐
│ Goal: Add type hints to all functions in src/utils  │
│ Tasks: 3 total │ 1 running │ 1 done │ 1 pending    │
│ Agents: 2 active │ Cost: $0.12                      │
├─────────────────────────────────────────────────────┤
│ ✓ task-001  Analyze existing type usage    00:42    │
│ ► task-002  Add type hints to helpers      01:15    │
│ ○ task-003  Add type hints to validators   pending  │
└─────────────────────────────────────────────────────┘

✓ = completed and merged
► = currently running
○ = pending (waiting for dependencies or an available agent)

Press q to stop gracefully (agents finish their current task) or Ctrl+C to force stop.

Step 5: Check the results

When all tasks complete, check what changed:

git log --oneline -5
# a1b2c3d Add type hints to validator functions
# d4e5f6g Add type hints to helper functions
# h7i8j9k Analyze existing type usage in src/utils.py

Each agent's work is a separate commit, merged through Bernstein's merge queue. If any task failed, its changes are rolled back and the failure is logged in .sdd/dead_letter.json.

What to try next

Run a YAML plan for structured, multi-stage projects:

bernstein run plans/my-project.yaml

Plans let you define stages, dependencies, roles, and complexity per task. See the plan file docs for the full schema.

Use multiple agent types by installing additional adapters:

# Bernstein will route tasks to the best available agent
pip install codex-cli  # or install any supported agent
bernstein agents       # see all detected agents

Monitor costs across sessions:

bernstein cost
# Session total: $0.47
# By model: haiku=$0.03, sonnet=$0.28, opus=$0.16

Check the API for programmatic access:

# Task server runs on port 8052 during sessions
curl http://127.0.0.1:8052/status

How Bernstein Routes Tasks to the Right Model

Alex Chernysh — Tue, 21 Apr 2026 14:09:16 +0000

Not every coding task needs Opus. Bernstein's contextual bandit router learns which model handles each task type best, then routes accordingly. In our own runs, the bandit router cut spend roughly in half compared to uniform model selection. Measure yours with bernstein cost.

The uniform selection problem

Most multi-agent setups use the same model for everything. Every task — whether it's renaming a variable or designing an authentication system — gets routed to the same model at the same effort level. This is wasteful. A docs task that writes a docstring doesn't need the same model as a security task that implements credential scoping.

The cost difference is real. At current API pricing, routing a simple task to Haiku instead of Opus costs roughly 30x less. Over a session with 40-60 tasks, that adds up fast.

How the router works

Bernstein's routing pipeline has three layers:

Layer 1: Heuristic classification. Every task has a complexity field (low, medium, high) and a role (backend, frontend, qa, security, etc.). The router uses a rule-based classifier to make an initial model/effort assignment. Low-complexity tasks default to Haiku or Sonnet with standard effort. High-complexity tasks get Opus with max effort.

Layer 2: Epsilon-greedy bandit. This is where it gets interesting. The bandit maintains per-role reward estimates for each model. When a task arrives, it exploits the best-known model 80% of the time and explores alternatives 20% of the time. Rewards come from task outcomes: did the agent complete the task? Did tests pass? How many retries were needed?

# Simplified selection logic
candidates = ["sonnet", "opus"] if task.complexity == "high" else CASCADE
selected = bandit.select(role=task.role, candidate_models=candidates)

The CASCADE list includes all available models from cheapest to most capable. For high-complexity tasks, the bandit only considers Sonnet and Opus — sending a hard architecture task to Haiku would waste the agent's time even if it's cheap.

Layer 3: Effectiveness seeding. The bandit warms up using historical effectiveness data from the .sdd/metrics/ directory. If a previous run showed that backend tasks succeed 95% of the time with Sonnet but only 70% with Haiku, the bandit starts with that prior. No cold-start problem after the first session.

What the router learns

After a few sessions, clear patterns emerge:

Task type	Typical model	Why
Docs, docstrings	Haiku	Templated output, low reasoning
Test writing	Sonnet	Needs code understanding, not creativity
Bug fixes	Sonnet	Pattern matching on error traces
Refactoring	Sonnet/Opus	Depends on scope
Architecture, security	Opus	Requires deep reasoning

These aren't hardcoded rules — they're learned from outcomes. If your codebase has unusually complex tests, the bandit will learn to route test tasks to a stronger model.

Configuration

The bandit is enabled by default when a metrics directory exists. You can tune exploration rate and model cascade in your config:

# .sdd/config.yaml
routing:
  bandit_epsilon: 0.2          # 20% exploration
  cascade: [haiku, sonnet, opus]
  min_samples_per_arm: 5       # explore each option at least 5 times

To disable bandit routing and use pure heuristics:

routing:
  bandit_enabled: false

The numbers

Across our internal runs (self-development sessions where Bernstein improves its own codebase), the bandit router cut per-session spend roughly in half compared to the baseline of Sonnet-for-everything. Task completion rates stayed within a couple of percentage points, so cheaper models handle their assigned tasks fine. Measure your own runs with bernstein cost.

The savings compound. A 10-agent session running 50 tasks might cost $15-20 with uniform Sonnet. With bandit routing, the same session runs $7-10. Over weeks of iterative development, that's the difference between a side project budget and a real expense.

Community Spotlight: April 2026

Alex Chernysh — Tue, 21 Apr 2026 14:08:40 +0000

Every month we spotlight the people who make Bernstein better. Here are April's highlights from the first month of public development.

What happened in April

Bernstein went from v1.0.0 to v1.8.8 in a few weeks. The pace was intense, and community contributions made a real difference:

Architecture decomposition: 52 oversized modules broken into 22 focused sub-packages, each under 600 lines. The orchestrator monolith (4,198 lines) is now navigable, testable, and merge-conflict-free. Read the full story.
18 agent adapters: We started with 7 adapters and now support 18: Claude Code, Codex, Gemini CLI, OpenAI Agents SDK, Cursor, Aider, Amp, Kiro, Kilo, Qwen, Goose, Ollama, Cody, Continue, OpenCode, Cloudflare Agents, IaC, and a generic wrapper. Each adapter is a focused Python class under 200 lines.
Cost-aware routing: The contextual bandit router learns which model handles each task type best. In our own runs, the bandit cut spend roughly in half compared to sending everything to the same model.
Cloudflare cloud execution: Agents can now run on Cloudflare Workers with Durable Workflows, R2 artifact storage, and D1 state.
Windows support: Full cross-platform compatibility contributed by @oldschoola: environment passthrough, Unicode safety, process management, and terminal handling.

Contributors

Thanks to everyone who contributed PRs, reported bugs, and tested edge cases this month:

@oldschoola: Windows compatibility (3 merged PRs), codex config, task filtering, auto-PR
@Ai-chan-0411: community spotlight template
@alexanderxfgl-bit: spotlight generator script
@forfreedomforrich-eng: --dry-run flag, trigger URL fix
@TheCodingDragon0: bernstein config diff, glossary
@internet-dot: HOL workflow
@Beledarian: config path validation

All contributors are listed in CONTRIBUTORS.md.

How to get involved

Bernstein is Apache 2.0 and welcomes contributions of all sizes:

Good first issues: curated tasks for newcomers
Write a blog post: get published on bernstein.run
Adopt an adapter: become the maintainer for your favorite agent
Submit benchmarks: share your orchestration metrics

Running AI Agents on Cloudflare: Workers, Workflows, and Durable Objects

Alex Chernysh — Tue, 21 Apr 2026 14:08:39 +0000

Bernstein v1.8.4 ships with Cloudflare cloud execution. Agents can now run on Workers, multi-step tasks use Durable Workflows, artifacts go to R2, and state persists in D1. Here's the architecture and how to deploy.

Why local-only limits adoption

Running agents locally works for individual developers, but it has real constraints. Your laptop is the bottleneck: CPU, memory, and network all compete with your actual work. Long-running sessions drain battery. If you close your laptop, the session dies. And scaling beyond 4-5 concurrent agents on a MacBook starts hitting resource limits.

Cloud execution solves this. Agents run on remote infrastructure while you monitor progress from a dashboard or TUI. Sessions survive disconnects. You can scale to 20+ concurrent agents without melting your machine.

The Cloudflare stack

Cloudflare recently became OpenAI's infrastructure partner for agent cloud computing — the same infrastructure Bernstein agents can now run on. We chose Cloudflare's stack because it maps cleanly to orchestration primitives:

Workers handle lightweight, stateless agent execution. Each agent task runs in an isolated Worker with its own environment. Workers cold-start in under 50ms, so spinning up a new agent is nearly instant.

Durable Workflows orchestrate multi-step tasks. When an agent needs to clone a repo, run code, execute tests, and report results, the workflow ensures each step completes before the next begins — with automatic retries on failure. If a Worker crashes mid-task, the workflow resumes from the last completed step, not from scratch.

R2 stores artifacts. Agent outputs — diffs, test results, generated files — persist in R2 buckets. The orchestrator reads results from R2 when merging completed work back to the main branch.

D1 holds orchestration state. Task queues, agent assignments, cost metrics, and audit logs all live in D1. This replaces the local .sdd/ file-based state with a durable database that survives restarts and supports concurrent access from multiple Workers.

Architecture overview

Architecture diagram omitted in this cross-post. See the original post on bernstein.run for the rendered version.

The orchestrator itself runs as a Worker with a Durable Object for maintaining tick state. Agent Workers are spawned per-task and communicate results back through R2 and D1.

Deploying

Prerequisites: a Cloudflare account with Workers, R2, and D1 enabled, and wrangler installed.

# Authenticate with Cloudflare
wrangler login

# Deploy the Bernstein cloud stack
bernstein cloud deploy --project my-project

# This creates:
#   - Orchestrator Worker + Durable Object
#   - R2 bucket: bernstein-my-project-artifacts
#   - D1 database: bernstein-my-project-state
#   - Workflow definitions for multi-step tasks

Once deployed, run tasks against the cloud backend:

# Run a goal on cloud infrastructure
bernstein run --goal "Refactor auth module" --cloud

# Monitor from your terminal
bernstein cloud status

# Or check the dashboard
bernstein dashboard --cloud

Agent API keys (Anthropic, OpenAI, etc.) are stored as Worker secrets via wrangler secret put. They never leave the Cloudflare network.

Cost considerations

Cloudflare Workers pricing is request-based, not instance-based. You pay for the compute your agents actually use, not for idle VMs. For a typical 50-task session:

Workers compute: ~$0.50-2.00
R2 storage: pennies (artifacts are small)
D1 reads/writes: pennies (state operations are lightweight)

The cloud infrastructure cost is a small fraction of the LLM API costs that agents incur. The real savings come from not needing to keep your machine running and from being able to scale to more concurrent agents.

What's next

We're working on scheduled runs (trigger a session from a cron or GitHub webhook), multi-region execution (run agents closer to the repos they're working on), and a hosted dashboard for monitoring cloud sessions without a local CLI.

Try it: pip install bernstein and check the getting started guide.
Source: github.com/chernistry/bernstein

Stop using LLMs to schedule other LLMs

Alex Chernysh — Wed, 08 Apr 2026 12:56:54 +0000

Three AI coding agents on the same repo = three agents overwriting each other's work. Claude Code edits auth.py. Codex edits auth.py two seconds later. Claude's changes vanish. Meanwhile Gemini "refactors" the test suite and breaks six things.

Two weeks of this. Here's what fixed it: git worktrees per agent, a deterministic Python scheduler (not an LLM), and a janitor that verifies work before merge.

The wrong turn

My first orchestrator used an LLM to coordinate the other LLMs. A manager agent read the backlog, decided assignments, checked progress, re-planned on failure.

It was slow, expensive, and kept hallucinating priorities. ~40% of total tokens went to coordination overhead instead of code.

Then the obvious hit: scheduling is a solved problem. Operating systems have done concurrent process scheduling since the 1960s. Nobody uses neural networks for cron. Why use one for task assignment?

I ripped out the LLM scheduler. The result is Bernstein, an open-source orchestrator that coordinates any CLI coding agent with zero LLM tokens on scheduling.

The pipeline

Four stages:

Decompose: one LLM call takes your goal, outputs a task graph with roles, owned files, and dependencies.
Spawn: each task gets a fresh CLI agent in an isolated git worktree. Parallel execution. Main branch untouched.
Verify: a janitor checks concrete signals. Tests pass, files exist, linter clean, types correct. Binary outcomes, not opinions.
Merge: verified work lands on main. Failed tasks retry on a different model or get decomposed further.

Goal → Planner (LLM) → Task Graph → Orchestrator (Python) → Agents ‖
                                         ↓
                                    Janitor → Merge

The orchestrator is a Python event loop that polls a local task server, matches open tasks to available agents, and manages lifecycle. Deterministic, auditable, reproducible. Same inputs produce the same decisions.

Worktrees: the part that unlocked it

Each agent gets its own git worktree on a disposable branch:

git worktree add .sdd/worktrees/session-abc123 -b agent/session-abc123
# agent works in isolation
# janitor verifies, then:
git checkout main
git merge agent/session-abc123 --no-ff
git worktree remove .sdd/worktrees/session-abc123

Each agent thinks it owns the repo. No file locks, no coordination protocol between agents, no conflicts during work. The task graph declares file ownership, so overlapping files never get assigned concurrently.

Expensive directories (node_modules, .venv) get symlinked from the main tree so you don't pay setup cost per agent.

Model routing without vibes

Renaming a variable doesn't need Opus. But static rules for model selection go stale fast.

Bernstein uses a LinUCB contextual bandit that learns from outcomes. Features: complexity tier, file scope, role, estimated token budget. Reward: quality_score * (1 - normalized_cost). Cheapest model that passes the janitor wins.

Under ~50 completions it falls back to static cascade (haiku → sonnet → opus). After warm-up the bandit takes over. Policy persists across runs so learning accumulates.

Net effect in my runs: ~23% cost reduction vs. running everything on one top-tier model.

New in v1.8: MCP server mode

Since the original post, Bernstein gained a Model Context Protocol server. Any MCP-aware client (Claude Desktop, Cursor, VS Code, Zed) can now call Bernstein as a tool:

bernstein mcp --transport stdio

Your IDE agent decomposes a goal, calls bernstein_run, and Bernstein fans out the work across 12 parallel CLI agents in worktrees. The IDE agent just waits for results. One cheap router model at the top, a swarm of cheap workers below, one expensive reviewer at the end — instead of one Opus chewing through 40 serialized tasks.

How it differs from CrewAI, AutoGen, LangGraph, Composio, emdash

	Bernstein	CrewAI / AutoGen / LangGraph	Composio / emdash
Scheduling	Deterministic Python	LLM-driven	Hosted/UI-driven
Works with	20+ CLI agents (Claude Code, Codex, Aider, etc.)	Their SDK classes	Their desktop app / web UI
Git isolation	Worktree per agent	None	Varies
Verification	Janitor + quality gates	Mostly absent	Mostly absent
Agent lifetime	Short: spawn, work, exit	Long-running	Long-running
State	File-based (inspect with `cat`)	In-memory / checkpointer	Cloud/hosted
Interface	CLI + MCP server	SDK	Desktop ADE

Philosophical difference: CrewAI/AutoGen/LangGraph are frameworks — you write agents in their SDK. Composio and emdash are desktop ADEs — you use their UI. Bernstein is infrastructure — you point it at Claude Code, Codex, or Aider (or all three in one run) and it handles the rest.

The LLM-driven coordination in those frameworks is non-deterministic and hard to debug. When Bernstein assigns task #47 to Sonnet, you can read the policy file and trace the feature vector that selected it. No prompt archaeology.

Trade-off: no agent-to-agent chat, no built-in RAG, no hosted option. It's a CLI for people who want their agents to write code and get out.

What still sucks

Agents hallucinate file paths. The janitor catches it, but retries cost tokens.
Context windows fill up on large codebases. Short-lived agents help; it's still a real constraint.
12 parallel Opus agents is not cheap. Budgets and the bandit help. Not attention-free.
Setup friction. At least one CLI agent must be installed and authenticated.
File ownership isn't bulletproof. Agents occasionally touch files outside their scope.

This is v1.8, not v10. But the core loop is stable and I've been running it against production code for months.

Getting started

pip install bernstein
cd your-project
bernstein init
bernstein -g "Add rate limiting middleware"
bernstein live    # TUI
bernstein cost    # spend so far

For multi-stage work, a YAML plan:

stages:
  - name: backend
    steps:
      - goal: "Add rate limiting middleware"
        role: backend
        complexity: medium
      - goal: "Integration tests for rate limiter"
        role: qa
        complexity: low
  - name: docs
    depends_on: [backend]
    steps:
      - goal: "Document rate limiting in OpenAPI spec"
        role: docs
        complexity: low

bernstein run plan.yaml              # deterministic execution
bernstein run --dry-run plan.yaml    # preview + cost estimate

Mix models in the same run. Claude Code for architecture, Gemini for boilerplate, Aider with a local Ollama model for offline tasks.

GitHub repo. Apache 2.0. Star if it saves you a merge conflict.

If you've been babysitting one agent at a time, try the worktree-per-agent pattern and tell me what breaks. I'm especially interested in failure modes I haven't hit yet.

DEV Community: Alex Chernysh

Orchestration primitive or desktop ADE? Choosing your multi-agent coding layer in 2026

The two shapes

What a desktop ADE does well

What an orchestration primitive does well

Decision shortcuts

They often co-exist

Bernstein's specific positioning

From 4,000 Lines to 200: Decomposing Bernstein's Core

How a file gets to 4,000 lines

The plan

11 agents, 15 packages

The re-export shim pattern

What we learned

The result

Further reading

Getting Started: Your First Multi-Agent Run in 5 Minutes

Step 1: Install Bernstein

Step 2: Configure your agent

Step 3: Run your first goal

Step 4: Read the TUI

Step 5: Check the results

What to try next

Further reading

How Bernstein Routes Tasks to the Right Model

The uniform selection problem

How the router works

What the router learns

Configuration

The numbers

Further reading

Community Spotlight: April 2026

What happened in April

Contributors

How to get involved

Running AI Agents on Cloudflare: Workers, Workflows, and Durable Objects

Why local-only limits adoption

The Cloudflare stack

Architecture overview

Deploying

Cost considerations

What's next

Stop using LLMs to schedule other LLMs

The wrong turn

The pipeline

Worktrees: the part that unlocked it

Model routing without vibes

New in v1.8: MCP server mode

How it differs from CrewAI, AutoGen, LangGraph, Composio, emdash

What still sucks

Getting started