This report describes the architecture, research context, and operating principles behind Halo-2.0. Private prompt templates, routing weights, security controls, and implementation-specific thresholds are intentionally omitted.
Executive finding
The central result of this report is that model choice should be treated as a live systems decision, not as a preference selected before a session begins. A long-running agent crosses different problem regimes: interpretation, repository reconnaissance, planning, mutation, visual judgment, factual research, debugging, and verification. Those regimes reward different forms of reasoning. Halo-2.0 therefore treats the model as one replaceable component inside a continuous execution thread. The user gives one objective; the runtime is responsible for preserving that objective while changing the reasoning engine when the work materially changes.
This position is no longer unusual at the research frontier. OpenRouter’s Fusion system sends a prompt to several models in parallel and has a judge analyze consensus, contradictions, coverage gaps, unique insights, and blind spots before an outer model writes the final answer.1 Sakana AI’s Fugu similarly presents multi-agent orchestration behind a familiar single-model API, learning how to assemble workers and assign subtasks rather than forcing the user to design a team manually.3 Halo-2.0 arrived at a related architectural conclusion through product engineering: the session should remain singular even when cognition is plural.
Oscerra’s internal development chronology predates the public launch dates of those products, but this statement is intentionally narrow. It is not a claim that model ensembles, routing, or orchestration were invented by Oscerra, and it is not a patent-priority assertion. It means only that Halo-2.0 was designed around provider-independent, task-sensitive routing before these particular public implementations became available. The useful comparison is architectural, not promotional: several independent teams have converged on the idea that diversity at inference time can outperform a single fixed model.
One user request should create one durable execution thread, even when many models contribute to it.
Why a single provider plateaus
A frontier model can be excellent and still be the wrong model for a particular phase of work. The limitation is not merely benchmark rank. Every provider makes a long sequence of choices about pretraining data mixtures, code and language coverage, filtering, synthetic data, post-training objectives, safety behavior, tool-use curricula, inference-time reasoning, latency, and product constraints. The resulting systems do not fail in identical ways. One may be unusually disciplined about requirements but conservative in visual invention; another may produce strong code quickly but over-commit before inspecting the repository; another may retrieve buried facts well but be less reliable at closing an engineering task with exact evidence.
These differences create error diversity. In ordinary ensemble learning, diversity matters because correlated errors cannot be repaired by voting or synthesis. The same principle appears in language-model ensembles: the Mixture-of-Agents work showed that models can improve when they receive other models’ outputs as auxiliary information, even when some contributing outputs are individually weaker.5 OpenRouter’s public Fusion results likewise attribute part of the gain to multiple reasoning paths, tool calls, and source selections. The point is not that disagreement is always valuable. It is that independent failure modes provide information a single trajectory cannot generate.
For an autonomous product, the practical consequence is severe. Provider lock-in is not only a commercial dependency; it can become an epistemic dependency. If planning, implementation, critique, and verification all inherit the same habits, then an error made early may be repeated with increasing confidence. A provider-independent runtime can interrupt that correlation. It can ask a different model to inspect the same evidence, temporarily transfer a specialized task, or convene a panel when the cost of a wrong decision is higher than the cost of additional inference.
Public evidence for multi-model lift
Selected DRACO results published by OpenRouter. Orange bars are fused panels; gray bars are solo models. Scores are percentages, and the configurations are not equal in cost or filtering behavior.
Maturity is operational judgment
Halo-2.0 uses the word mature in a deliberately operational sense. A mature base model is not simply the model with the highest aggregate benchmark score. It is a model that tends to make practical first decisions: inspect before editing, choose tools that reduce uncertainty, separate reversible exploration from irreversible mutation, identify hidden dependencies, and preserve the user’s actual objective when the surface request is underspecified. Maturity is therefore measured by the quality of the first few state transitions, not by the rhetorical confidence of the first answer.
During the evaluation window represented by this report, Oscerra’s internal tests frequently selected an Anthropic Claude model for that base role. The observation is time-bounded and task-bounded. It is neither a universal ranking nor a permanent endorsement, and Halo is designed to change the assignment as new models arrive. The important product commitment is provider neutrality: model selection is made for user outcome, not to preserve a vendor relationship. We avoid describing any provider as categorically superior because frontier behavior changes rapidly, access tiers differ, and a result on one workload does not transfer automatically to another.
The base model’s first responsibility is triage. It decides whether the prompt can be answered faithfully in one response or whether the requested outcome requires multiple actions. When action is required, it emits a compact structured assessment: relevant task characteristics, required capabilities, likely verification burden, a provisional overseer model, and the first tool calls that reduce uncertainty. This assessment is produced in one call. The system does not spend a chain of expensive planning turns narrating obvious facts. A tightly constrained schema allows a capable model to express a rich decision in a small number of tokens.
The intake pass: classify without overthinking
The intake pass converts natural language into an execution profile. It distinguishes, for example, a backend migration from a visual redesign, a factual report from an artifact-generation task, and a repair request from a greenfield build. It also records less visible properties: whether the task is stateful, whether it depends on files that have not been inspected, whether browser interaction is required, whether a wrong action is easily reversible, and what kind of evidence will be necessary at completion. These features matter more than broad labels such as “coding” or “research.”
The profile is intentionally sparse. The system asks for only the discriminative characteristics needed to choose a route and begin work. A backend task may be decomposed into repository scale, language ecosystem, migration risk, test availability, and need for cross-file reasoning. A design task may emphasize visual hierarchy, responsive behavior, image composition, and browser verification. The output is not shown as a dramatic plan; it is an internal control record. This keeps latency and cost low while giving the runtime enough structure to avoid a generic one-model-fits-all response.
The same pass chooses the first actions. Sometimes the correct opening is a file search or a small group of batched shell reads. Sometimes it is a todo ledger because the mission has several independently verifiable parts. Sometimes it is a direct answer because tools would add ceremony rather than evidence. The model does not receive permission to improvise indefinitely. Its first proposal is checked against the runtime’s tool catalog, mission state, and allowed action surface before the agentic loop begins.
A capability registry instead of a leaderboard
Halo’s model registry is not a single ordered list. It is closer to a multidimensional capability map. Each model is evaluated against narrower task characteristics: large-repository navigation, backend implementation, frontend taste, structured tool use, long-context retrieval, factual synthesis, debugging under incomplete evidence, schema adherence, instruction stability, latency, and cost. A model can be strong in one slice and average in another. The registry also records operational facts such as context limits, tool syntax, provider availability, streaming behavior, and known failure patterns.
Scores in that registry are treated as estimates, not immutable truth. They decay as model versions change, and they can be conditioned on the surrounding harness. A model that performs poorly with a generic prompt may become excellent with a provider-specific context frame; a model that wins a static benchmark may be unreliable when asked to use tools over thirty turns. For that reason, Halo combines benchmark evidence, replayable internal tasks, failure audits, and production telemetry. The selection layer is always allowed to say “insufficient evidence” rather than convert uncertainty into a false ranking.
This also prevents a common routing mistake: sending every task to the nominally strongest model. The strongest model may be unnecessarily expensive, slower than the user’s patience budget, or less precise on the exact subtask. Routing is an optimization under constraints. The objective is not to maximize abstract intelligence on every turn; it is to maximize expected mission quality while respecting latency, cost, privacy, tool compatibility, and the probability that another model will have to repair the result.
| Capability dimension | Why it is separated | Example routing effect |
|---|---|---|
| Repository navigation | Measures how well a model forms a correct map before editing. | Choose for reconnaissance even if another model writes the patch. |
| Visual judgment | Not captured by code benchmarks alone. | Delegate responsive polish or interface critique. |
| Schema reliability | Determines whether tool calls survive strict validation. | Prefer for control-plane turns and final structured output. |
| Long-context retrieval | Varies sharply by model and context position. | Choose for large document/code evidence synthesis. |
The overseer model and the first tool calls
Once the intake profile exists, the base model names a provisional overseer for the session. “Overseer” does not mean that one model writes every token. It means that one model currently owns the coherent interpretation of the user’s goal, the live plan, and the next decision boundary. Ownership can move, but it cannot be ambiguous. This prevents a multi-agent system from becoming a group chat in which every participant edits the plan, duplicates work, or assumes another participant has verified the result.
The first tool calls are chosen at the same time. This is important because model selection without action selection is incomplete. A model may be best at backend reasoning, yet the correct first move may be a cheap, deterministic grep that reveals the relevant files. Another task may need a parallel terminal batch to inspect configuration, tests, and entry points before any model should plan. Halo treats tools as evidence-producing operations. The opening route therefore includes both a cognitive owner and the smallest set of actions that can change the system’s uncertainty.
After those calls return, ordinary agentic execution begins: inspect, update the task state, mutate when justified, test, reflect, and close out against evidence. The proprietary details are intentionally omitted here. The public principle is enough: the model does not receive an unbounded transcript and a vague instruction to “be autonomous.” It receives a mission frame, a governed action surface, current workspace truth, and a compact record of what the last action actually proved.
Halo’s routing control plane
The model changes, but mission state and runtime authority remain stable.
On-the-fly routing as a native skill
The initial route is only a hypothesis. A session may reveal that the dominant difficulty is different from what the user’s wording suggested. A request that appears to be a small frontend fix may uncover a build-system problem; a research task may turn into document generation; a backend migration may reach a point where visual verification is the highest-risk step. Halo therefore allows routing decisions during execution rather than treating the opening choice as a contract.
Provider-aware context engineering helps the current model recognize those boundaries. The runtime can present the same mission state differently depending on the model’s tool conventions, training tendencies, and known blind spots. This is not a hidden answer key and it is not a way to force a preferred conclusion. It is closer to adapting an interface for different operators: emphasize unresolved evidence for a model that tends to rush; foreground the task ledger for a model that loses continuity; present a concise visual rubric for a model delegated to interface work. The exact prompts and weights remain private because they are part of Halo’s control system.
Crucially, the model can admit that another model is better suited to the next bounded piece of work. That admission is not framed as failure. It is a routing action with explicit scope. The current owner can request a temporary specialist for one task, a fixed number of turns, or a named completion condition. It can also sign off permanently when the remaining session has changed character. The runtime records who owns the thread, what state was transferred, and when control should return.
Temporary delegation versus permanent handoff
Temporary delegation is appropriate when the task has a local specialist boundary. A visual model may receive the current component, screenshots, and acceptance criteria, then return a patch and critique while the original overseer retains the broader repository state. A security-oriented model may inspect a risky migration and return findings without being allowed to mutate. A fast model may handle repetitive extraction while a stronger model preserves the architectural decisions. The delegated context is deliberately narrower than the full session, which reduces cost and prevents unrelated history from diluting the specialist’s attention.
Permanent handoff is different. It occurs when the remaining mission is better represented by another model’s strengths and the cost of repeated returns would exceed the value of continuity with the original owner. The outgoing model produces a compact signed state: current objective, completed and pending tasks, decisive evidence, open risks, relevant files, and the reason for transfer. The incoming model must acknowledge that state before acting. This is less theatrical than two models conversing; it is a controlled transfer of operational responsibility.
Both modes include a return condition. A temporary specialist returns after a task is checked off, a turn budget is reached, or a specified artifact is produced. A permanent handoff returns only if the new owner explicitly delegates again. These rules matter because “multi-agent” systems often fail through ownership ambiguity rather than lack of intelligence. Halo’s routing layer is designed to make the collaboration topology inspectable to the runtime even when it remains invisible to the user.
Ownership must stay explicit
Halo distinguishes ordinary continuation, bounded specialist work, and a full transfer of the execution thread.
Fusion mode for consequential decisions
Some decisions deserve more than a single trajectory. Before a large codebase repair, for example, Halo can launch several isolated investigators from different providers. They receive different analytical roles or perspectives: dependency topology, failure reproduction, architectural risk, test strategy, or minimal-change alternatives. They work in conceptual sandboxes and do not mutate the original workspace. This separation is critical. Parallel cognition is useful only if speculative branches cannot collide with production state.
The outputs are then given to a judge selected for synthesis and structured decision-making. The judge does not simply average prose. It identifies shared conclusions, contradictory assumptions, unique evidence, missing coverage, and proposals that are redundant or unsafe. OpenRouter’s Fusion documentation describes a related pattern in which the judge returns structured analysis rather than a naïve merged answer.2 Halo uses the same broad insight in an agentic setting: comparison must be explicit before a final actor receives permission to plan or mutate.
Fusion can also appear mid-session. After a large investigation, the agent may have enough evidence to know that the next decision is high leverage but not enough confidence to choose a single path. It can ask multiple models to interpret the same findings, generate candidate rewrites, or critique a proposed migration. The judge then produces the operative schema—plan updates, tool calls, or a bounded mutation proposal. Only that final structured result can affect the live workspace.
What public fusion results do—and do not—show
OpenRouter reported that a Fable 5 and GPT-5.5 panel synthesized by Opus 4.8 scored 69.0% on 100 DRACO deep-research tasks, above the individual models in the published table. A budget trio of Gemini 3 Flash, Kimi K2.6, and DeepSeek V4 Pro reached 64.7%, exceeding the listed solo scores for GPT-5.5 and Opus 4.8 while costing roughly half as much as the top frontier configuration.1 These results are useful evidence that multi-model deliberation can create real lift under controlled tools and a shared benchmark.
They are not proof that every panel beats every individual model. Seven Fable tasks were blocked by content filters, the benchmark emphasizes deep research, and Fusion adds latency and inference cost. OpenRouter also found a gain when Opus was fused with another run of itself, which suggests that stochastic path diversity and synthesis contribute alongside provider diversity. A careful system should therefore treat cross-provider diversity as one source of information, not a magical ingredient. The relevant question is whether the expected reduction in error is worth the additional compute for this decision.
Halo’s use of fusion is consequently selective. Short tactical prompts should not trigger a panel. Routine file reads, deterministic tests, and obvious local edits are better served by direct execution. Fusion is reserved for ambiguous or consequential boundaries: architecture, difficult root-cause analysis, high-value generation, multi-source research, or a decision whose downstream repair cost is large. The runtime’s job is partly to know when collective intelligence would be overkill.
Sakana Fugu and learned collaboration topology
Sakana AI’s Fugu offers another important comparison. Its public description emphasizes that model strengths are often problem-specific rather than merely domain-specific, making manual model switching difficult for end users. Fugu learns to assemble agents, assign roles, and coordinate subtasks behind an OpenAI-compatible interface.3 The associated Conductor research reports that a relatively small orchestrator can outperform every worker in its pool by becoming a meta-prompt engineer and recursively launching corrective workflows.4
Halo shares the desire to hide orchestration complexity, but it places stronger emphasis on a persistent execution substrate. The routing decision is coupled to tool admissibility, file state, task settlement, receipts, and closeout. In other words, the collective models do not merely answer a prompt; they participate in a governed mission whose external state outlives any one completion. This makes the judge’s output more constrained. A brilliant synthesis that cannot be translated into valid actions is not yet a useful agent decision.
The systems also suggest two complementary directions. Learned orchestration can discover non-obvious collaboration patterns that hand-authored rules miss. Runtime governance can keep those patterns grounded in real state and evidence. Halo’s long-term direction is not to choose between learned routing and explicit control, but to combine them: allow models to propose the collaboration topology while the runtime enforces ownership, budget, privacy, tool scope, and verification.
Cost, latency, and the right to decline fusion
A multi-model system can waste money very efficiently if routing is treated as spectacle. Every additional model increases token consumption, wall-clock latency, and the surface area for contradictory output. Halo therefore includes a right to decline orchestration. The intake pass can decide that one model and one deterministic tool call are enough. A specialist can decline a handoff if the state transfer is incomplete. A judge can report that the panel adds no material evidence. These outcomes are healthy; they prevent the product from optimizing for visible complexity.
Cost is modeled at the mission level rather than only the request level. A more expensive model may be cheaper if it avoids three repair cycles. A budget panel may be justified if it catches an architectural mistake before mutation. Conversely, a frontier panel is irrational for a reversible formatting change. The routing policy estimates not only immediate price but expected rework, verification burden, and user delay. Because those estimates are uncertain, Halo records the decision and can compare the projected value with the actual session outcome.
Latency is similarly staged. Parallel workers can reduce the wall-clock cost of multiple perspectives, but the judge still waits for useful coverage. Halo can stop early when enough independent evidence converges, exclude a slow worker whose contribution is unlikely to change the decision, or choose a latency-homogeneous panel for interactive turns. This resembles OpenRouter’s distinction between general Fusion and a faster preset, but the selection is tied to the mission’s current phase rather than a permanent user setting.
Failure modes and containment
Dynamic routing introduces new failure modes. A capability registry can become stale. A base model can misclassify the task. A specialist may receive too little context, while a judge may reward consensus even when every worker inherited the same false assumption. Provider outages can force a degraded route. Privacy requirements may exclude the nominally best model. A handoff may also lose tacit decisions that were never written into the task state. These are systems failures, not merely model failures, and they require explicit containment.
Halo addresses them with several principles. First, routing is provisional and reversible. Second, every handoff carries a state packet rather than a prose recap alone. Third, workers are given differentiated perspectives and, when appropriate, independent evidence-gathering tasks. Fourth, the judge must identify blind spots and contradictions instead of producing a confidence score with no explanation. Fifth, model assignments are auditable after the session so an evaluation can distinguish a bad model choice from a bad tool result or an incomplete mission frame.
The most important containment rule is that no model owns reality. Models propose actions; the runtime owns workspace state, tool receipts, task status, and completion. A model can be replaced without losing the file tree, the command exit code, the current snapshot, or the user’s original request. That separation is what makes dynamic routing safe enough to be useful. Without it, “switching models” often means copying a transcript and hoping the new model reconstructs the hidden state correctly.
Evaluation protocol
Routing should be evaluated against mission outcomes, not isolated answer preference. Oscerra’s test design uses replayable tasks with known repositories or artifacts, defined acceptance criteria, and a record of each route decision. Measures include first-action quality, unnecessary tool calls, time to first useful evidence, repair cycles, test pass rate, visual acceptance, unresolved verification gaps, and total cost. The same mission can be replayed with a fixed provider, a task router, temporary delegation, and fusion to identify where the complexity actually earns its keep.
A capability score is updated only when the evidence is sufficiently specific. “Model A failed coding” is not actionable. “Model A edited before reading the dependency boundary in a medium TypeScript monorepo” can inform a routing feature. Evaluations also separate model behavior from harness behavior: the same model may be tested with generic context, provider-adapted context, and the full Halo mission frame. This avoids attributing every improvement to the model when the control system is doing part of the work.
Finally, evaluation includes abstention. A good router must know when not to route, when not to fuse, and when no available model has enough evidence to proceed. The benchmark suite therefore penalizes unnecessary delegation and unsupported confidence. The objective is not to maximize the number of model transitions. It is to produce a smaller number of better state transitions while keeping the user’s experience coherent.
Product implications
For users, the ideal routing system is almost invisible. They should not have to learn a model catalog, compare context windows, or guess whether a visual task belongs to one provider and a backend task to another. The interface should expose only decisions that affect consent, cost, privacy, or a meaningful trade-off. Everything else belongs inside the platform. This is why Halo presents one workspace and one execution thread rather than a dashboard full of agent avatars.
Provider independence also changes the product relationship. Oscerra can adopt a new frontier model as soon as it proves useful on relevant tasks without forcing users to migrate their workflows. It can remove a model whose reliability falls, route around an outage, or honor a data constraint by excluding a provider. The user’s durable asset is not a relationship with a model name; it is the mission state, artifacts, evidence, and continuity preserved by the runtime.
The deeper implication is that “the model” becomes less central to product identity. Halo-2.0 is the orchestration, memory, tool law, workspace, and receipt system that allows multiple models to contribute without fragmenting the task. A model may be extraordinary, but it is still a worker inside a larger operational design. The product’s quality is determined by how well that design turns diverse intelligence into a verified result.
Conclusion
Dynamic model routing is not a promise that more models always produce a better answer. It is a disciplined response to a simple fact: complex work changes shape while it is being done. A fixed model selection made before the first read cannot anticipate every phase, and a transcript alone is not enough to transfer ownership safely. Halo-2.0 therefore routes capabilities around a stable mission state.
The base model performs compact triage, chooses an initial overseer, and begins with evidence-producing actions. The live agent can delegate temporarily, hand off permanently, or invoke a panel when the next decision warrants independent perspectives. Provider-aware context frames help each model operate inside a consistent runtime, while judges convert parallel speculation into one structured decision. Cost, latency, privacy, and verification remain first-class constraints.
Public systems such as OpenRouter Fusion and Sakana Fugu strengthen the case that inference-time collaboration is a major direction for frontier AI. Halo’s contribution is to place that collaboration inside an autonomous execution substrate where state, tools, receipts, and completion remain coherent. The result is not several assistants arguing in public. It is one agentic system capable of changing its mind—and its model—without losing the work.