Evaluating Orchestrator-Worker Architectures: A Comparative Benchmark of Solo vs. Sub-agent LLM Implementations in Complex Coding Tasks

In the rapidly evolving landscape of agentic workflows, a critical architectural question has emerged: Is it more efficient to utilize a single, highly capable "Solo Agent," or to implement an "Orchestrator-Worker" pattern where a primary model delegates sub-tasks to smaller, specialized sub-agents? While the industry trend leans heavily toward multi-agent delegation for complex reasoning, recent empirical testing suggests that naive implementation of sub-agents can lead to significant regressions in code integrity, increased latency, and unexpected cost overheads.

This post details an experimental study involving seven distinct model configurations tasked with executing a high-complexity coding assignment: the implementation of a detailed 7-phase execution plan.

Experimental Methodology

The experiment was designed to test the limits of delegation by applying a consistent prompt across various model hierarchies. The core task involved a multi-stage specification requiring the agent to implement all actions according to a predefined, granular 7-phase plan without human intervention (zero-shot implementation).

Test Configurations

The simulations were categorized into two primary architectural archetypes:

1. Solo Agent Architectures: These configurations utilized a single model instance to manage the entire context and execution loop.

   • Claude 3 Opus (Solo)
   • Claude 3 Sonnet High Effort (Solo)
   • GPT Sol Medium (Solo)

2. Orchestrator-Worker Architect/Delegation Architectures: These configurations utilized a primary "orchestrator" model tasked with sequential delegation to sub-agents.

   • Opus $\rightarrow$ Sonnet High Effort
   • Sonnet High Effort $\rightarrow$ Haiku Medium Effort
   • Opus $\rightarrow$ Haiku Medium Effort
   • Sol Medium $\rightarrow$ Luna High Effort

Evaluation Metrics

To ensure a rigorous comparison, the following technical metrics were tracked:

• Cost Efficiency: Calculated via API token pricing and subscription-based usage analysis.
• Latency (Time to Completion): The total duration from prompt submission to final code delivery.
• Code Integrity: Measured through automated test pass rates, static analysis error detection, and the successful avoidance of race conditions.
• Implementation Depth: Quantified by the volume of functional code produced and the inclusion of supplementary testing suites.

Results: The Cost-Latency Pareto Frontier

The data reveals a stark divergence between API pricing models and actual operational efficiency.

The Economic Fallacy of Sub-agents

A common hypothesis in agentic design is that delegating to smaller models (like Haiku) reduces costs. While the experiment confirmed that Opus $\rightarrow$ Haiku was indeed the least expensive configuration among Anthropic's model suite, this cost reduction came at a significant performance penalty: it was roughly twice as slow as solo implementations.

Conversely, when analyzing GPT-based models via API pricing, Sol Medium appeared significantly cheaper than its counterparts. However, when comparing subscription-based usage—where models are effectively "subsidized" by the provider—the cost delta between Sol Solo and Opues Solo narrowed significantly. This highlights a critical nuance for developers: architectural decisions must be driven by the specific deployment environment (API vs. Subscription).

Latency Bottlenecks

The experiment identified severe latency regressions in certain delegation patterns. Specifically, delegating to Luna High Effort resulted in "astronomically slow" execution times. Furthermore, the overhead of managing context hand-offs between an orchestrator and a sub-agent often negated the speed advantages of using smaller models, particularly when those sub-agents required higher effort levels for reasoning.

Code Quality and Architectural Fragility

The most critical findings emerged from the analysis of code integrity and static analysis.

The Breakdown of Static Analysis

In both configurations where Haiku acted as a sub-agent (under both Opus and Sonnet orchestrators), the implementation failed to pass basic static analysis. These were not merely stylistic errors but clear, uncorrected syntax or structural bugs. This suggests that the fragmentation of context—splitting a single 7-phase plan into discrete delegation events—prevents the sub-agent from maintaining the global state necessary for syntactically correct, large-scale implementations.

Emergent Bugs: Race Conditions

The Sonnet $\rightarrow$ Haiku configuration demonstrated an even more complex failure mode: the introduction of a race condition. While the orchestrator (Sonnet) provided the plan, the sub-agent's inability to grasp the temporal dependencies within the implementation phases led to non-deterministic execution errors that were not present in solo agent runs.

The Superiority of Solo Implementation

In terms of passing specific high-complexity test cases, only Opus Solo and Sonnet Solo (without sub-agents) achieved success. These models operated within a unified context window, allowing for seamless integration of the 7 phases without the "contextual drift" inherent in delegation.

Conclusion: Toward Advanced Orchestration

The experiment concludes that naive delegation is an anti-pattern. Simply instructing an orchestrator to "use sub-agents" often results in higher costs, increased latency, and degraded code quality. The most economically viable and performant option identified was the use of a highly capable solo agent, specifically Sonnet High Effort (Solo).

However, this does not render sub-agents obsolete; rather, it necessitates more sophisticated orchestration strategies. Future iterations of this research will focus on:

• Parallel Sub-agent Execution: Moving away from sequential delegation to reduce latency.
• Input Caching Strategies: Minimizing the overhead of context re-injection.
• Role-Specific Prompting: Defining granular, specialized roles for sub-agents rather than generic task delegation.
• Verification Loops: Implementing automated review stages between the orchestrator and worker to mitigate static analysis failures and race conditions.

For now, if your goal is rapid, reliable code implementation, a single, high-capability model remains the superior architectural choice.