Reached #13 on Stanford's Terminal Bench leaderboard. Orchestrator, explorer & coder agents working together with intelligent context sharing.
Reached #13 on Stanford's Terminal Bench leaderboard. Orchestrator, explorer & coder agents working together with intelligent context sharing.
TL;DR:
The orchestrator acts as the brain of the operation - it receives the user's task but never touches code directly. Instead, it:
The orchestrator's lack of direct code access forces proper delegation and verification patterns, leading to more strategic solutions.
For a full breakdown of this project's code structure, see here
The model uses xml tags to define an action, and YAML to define the parameters of an action if they exist. Below shows the model thinking and then dispatching a coder agent.
…Terminal bench is a brilliant benchmark created by Stanford and Laude Institute to quantify agents' ability to complete complex tasks in the terminal. My Orchestrator system achieved 13th place on the leaderboard, demonstrating competitive performance against leading AI coding assistants.
I ran the Orchestrator evaluations with both Claude-4-Sonnet and also Qwen3-Coder-480B-A35B:
This image shows Qwen-3-Coder performance on the benchmark. The screenshot towards the top of this README shows Sonnet-4 performance.
One of the most striking results is the amount of tokens used by Sonnet-4 as opposed to Qwen3-Coder.
The below table shows the total tokens (input and output included) processed across the TerminalBench evaluation run (5 attempts at 80 tasks = 400 trajectories).
| Model | Success Rate | Total Evaluation Cost | Token Usage |
|---|---|---|---|
| Claude Sonnet-4 | 37.0% | $263.56* | 93.2M tokens |
| Qwen-3-Coder | 19.7% | $217.83 | 14.7M tokens |
*Claude Sonnet-4 costs reflect heavy caching usage, reducing actual API costs
While all agents use the same underlying LLM, each operates with its own context window, specialised system message, and distinct toolset. This creates functionally different agents optimised for their specific roles.
System message
Role: Strategic coordinator and persistent intelligence layer
Capabilities: Task decomposition, context management, subagent delegation
Tools: Task creation, subagent launching, context store management
Restrictions: Cannot read or modify code directly - operates purely at architectural level
The orchestrator maintains the complete picture across all tasks, tracking discoveries and progress. It crafts precise task descriptions that explicitly specify what contexts subagents should return, ensuring focused and valuable information gathering.
Trust Calibration Strategy:
The orchestrator employs adaptive delegation based on task complexity:
System message
Role: Read-only investigation and verification specialist
Capabilities: System exploration, code analysis, test execution, verification
Tools: File reading, search operations (grep/glob), bash commands, temporary script creation
Restrictions: Cannot modify existing files - strictly read-only operations
Explorers gather intelligence about the codebase, verify implementations, and discover system behaviors. They create knowledge artifacts that eliminate redundant exploration for future agents.
System message
Role: Implementation specialist with write access
Capabilities: Code creation/modification, refactoring, bug fixes, system changes
Tools: Full file operations (read/write/edit), bash commands, search operations
Restrictions: None - full system access for implementation tasks
Coders transform architectural vision into working code. They receive focused tasks with relevant contexts and implement solutions while maintaining code quality and conventions.
I introduced a novel approach to multi-agent coordination through the Context Store - a persistent knowledge layer that transforms isolated agent actions into coherent problem-solving. Unlike traditional multi-agent systems where agents operate in isolation, my architecture enables sophisticated knowledge accumulation and sharing.
The Context Store Pattern:
Key Benefits:
This architecture ensures that every piece of discovered information becomes a permanent building block for future tasks, creating a system that genuinely learns and adapts throughout the problem-solving process.
The orchestrator maintains a comprehensive task management system that tracks all subagent activities:
Core Functions:
The task manager serves as the orchestrator's operational memory - while the context store holds discovered knowledge, the task manager tracks the journey of discovery itself. This dual-layer system ensures the orchestrator always knows both what it has learned AND how it learned it, enabling sophisticated multi-step solutions that build intelligently on previous attempts.
One thing I noticed during early evaluations was that whilst the system was on track to complete extremely complex tasks, it would use lots of subagents to get there, and therefore the task would time out.
Therefore the orchestrator now employs a philosophy for time-efficient execution, recognising that wasted time often stems from poor task specification rather than slow execution:
Prevention Principles:
For dev:
uv syncTo run evals:
./run_terminal_bench_eval.shTo quickly test various models: See /tests
No open issues yet, or sync has not completed.