← Back to blog

· Timothy O'Brien

Advisor and Orchestrator Without Claude Code

A cheap executor, a smarter on-call model, and a difficulty router. The pattern builds in any harness - no Claude Code required.

A small ivory steam engine on the lower left emitting a stream of amber dots along dotted rails; a wide lower lane carries the dots straight across the frame while a thin lane arcs upward to a large amber advisory console on the upper right; faint tags hang in the midground; deep charcoal-navy backdrop, layered depth.

This week Anthropic announced Advisor and Orchestrator as production features, and every tutorial about them assumes you write your agent in Claude Code. You do not need Claude Code. You barely need Anthropic’s API. Both features are old ideas wearing a new API hat, and you can build the same effect into any harness: a router that knows what things cost, and a system for calling in the expensive model only when the cheap one is stuck.

What the two features actually do

Advisor pairs a fast executor model (Sonnet or Haiku) with a heavyweight advisor (Opus). When the executor hits a decision it is not confident about, it calls the advisor mid-task, weighs the advice, and keeps going. You add a tool called advisor_20260301 to your request, Anthropic runs the loop inside one API call, and max_uses is your cost lever. Orchestrator is the team version: a lead agent breaks a job into pieces, farms them out to specialist subagents with their own models, prompts, and tools, and the workers message each other and report back.

Neither idea is new. The cascade pattern — cheap model first, expensive model on escalation — goes back years (FrugalGPT in 2023, RouteLLM after it). What Anthropic did is remove the orchestration code: one tool entry, one beta header, done. It is genuinely convenient, and it locks you to their executor-advisor pair. If you work in pi, in OpenCode, in any self-built harness, you need the DIY version. It is less magic and it teaches you more.

Pick a router that understands difficulty

The core of both features is a difficulty judgment: which requests deserve the expensive model? If you have no harness support at all, you can start with rules instead of routing. Anything touching architecture, security review, or a gnarly migration goes to the premium model by policy. Boilerplate, tests for already-written code, dependency bumps, formatting — cheap model, every time. This static split is crude and it works: routing studies put typical coding-agent savings at 30-40% before any fancy classification, with a caveat — a cheap model mis-routed onto hard work can cost more in rework than it saved.

The next level is escalation on signals. Let the cheap model run. If its tests fail twice, if it reports uncertainty, if it starts editing the same file three times, route the task up. A project that measured this found the trap: the cheap model answered 2.5x more verbosely than the expensive one, so per-token price told you nothing about actual cost. Count tokens, not rates.

If you want the router off the shelf, LiteLLM ships one with fallbacks and budget caps, OpenRouter carries auto-routing by task, and the pi harness has a community extension, pi-router, that scores prompt difficulty and routes between tiers with failover. Pi is a useful baseline: a minimal harness — read, write, edit, bash — where the model is a choice inside it, so a router bolted on top actually sticks.

Build the advisor yourself

The advisor pattern is easier than it sounds and it generalizes far past Anthropic’s models. Any agent that can spawn a second model call can do it:

  1. Run the cheap model as your executor, always.
  2. When it stalls — failed verification, repeated edits, an explicitly reported low-confidence state — make one expensive call that carries a compressed summary of the executor’s context and the specific question.
  3. Feed the verdict back into the executor’s loop as a message.

The Anthropic version syncs context for you; the DIY version costs a few extra calls and works with any two models on any provider. Cap the advisor calls, as Anthropic’s max_uses does — three consultations per task is a reasonable start — because the failure mode is an executor that visits the advisor every ten minutes and quietly erases the savings. I know this from the expensive side: I once watched a premium-model session burn through a sum I will not repeat in public before admitting the task needed a plan, not a bigger model.

The orchestrator pattern is the same trick with roles. In practice, a simple version beats most vendor wizardry: one agent holds the plan and the review duty, several parallel workers hold narrow tasks and never see the full plan. Keep the lead on the expensive model and the workers cheap — working subagent setups all cap depth and scope, because every inter-agent message is a billable round trip. I run my own work through a harness organized this way: a cheap coordinator model for the loop, heavier models delegated in only for writing, synthesis, and review, with results coming back as summaries instead of transcripts. The orchestrator was not born in Claude Code. It is just delegation with a budget.

The honest part

None of this is proven magic. Cascade routing saves money when the router is right and costs money when it is wrong, and nobody publishes their mis-route rate. What is safe to claim: the two capabilities Anthropic made easy this week are implementable by hand in an afternoon, the hand-rolled versions transfer across providers and harnesses instead of locking into one, and the controls — call caps, escalation signals, token-based accounting — matter more than which model sits at the top of the stack.

Keep reading
This post is part of the thinking behind Orchestrator: Your Next Job Title — recognizing and building the work of delegated intelligence.