Hard questions need a different operating contract
A routine classification or formatting task may need one fast model call. A high-value research, coding, security, finance, or policy question may need source evidence, competing approaches, verification, and a record of why the final answer was acceptable.
Sending every difficult prompt to several frontier models is one response, but it creates a new problem: every candidate is paid to solve the whole task, even when only one claim is uncertain. The final synthesis can also hide which evidence survived and why one answer defeated another.
Punk Chorus treats advanced reasoning as a governed execution job. Teams select it with one model id, punk/chorus, on Punk’s OpenAI-compatible or Anthropic-compatible gateway. The caller keeps its normal response format while Chorus coordinates evidence, routing, verification, budget, and receipts behind the runtime.
Chorus begins with a reasoning contract
Before choosing a model, Chorus builds a bounded contract for the request. The contract can include the task class, cost ceiling, latency mode, quality mode, research requirement, policy profile, audit depth, and receipt requirement.
Those controls answer practical questions before orchestration begins:
- How much may this answer cost?
- Does it need fresh source evidence?
- Is speed more important than maximum quality?
- Which provider or model classes are allowed?
- Must the answer meet a strict verification bar?
- Should this run teach a reusable circuit?
- Is the result being observed, shadowed, or served?
The contract limits the search space. Without it, a “smart routing” system can keep buying more intelligence without a clear stop condition.
Claim-level work keeps spending focused
Chorus decomposes the request into claims and dependencies instead of asking every solver for a complete essay. A source-backed comparison might contain factual claims, a calculation, a policy constraint, and a recommendation. Those parts do not necessarily need the same evidence or model.
The runtime can satisfy a stable step with an existing deterministic circuit, gather current facts through the semantic web lane, send an unresolved technical claim to a qualified model, and reserve a stronger synthesizer for the final answer. Verifiers can examine grounding, contradictions, schema, math, policy, or licensing where those checks are relevant.
This is the economic difference between selective orchestration and a permanent model panel. Chorus buys the next useful unit of intelligence rather than paying every candidate to repeat the entire task.
It also preserves fallback. A request that cannot meet its evidence, model, or policy contract can use an allowed live route, return a caveat, require approval, or fail clearly. Maximum quality is not permission to ignore a boundary.
Research mode connects answers to source evidence
Hard reasoning and web research are related but distinct. A coding task may need deep model work without public sources. A due-diligence question may require fresh evidence even if the synthesis itself is straightforward.
Chorus therefore treats research as an explicit mode. When enabled, it can search for sources, convert pages into compact semantic source cards, identify coverage gaps, and carry accepted evidence into the final ledger and receipt. Query count, source count, and context size remain bounded.
This makes source coverage inspectable. Operators can see which evidence was accepted, which claim remained unresolved, and which fetch failed. A citation list is useful, but an evidence trail is stronger when it shows how the sources affected the answer.
A reasoning receipt explains the served result
Every served Chorus run can produce a structured receipt linked to the final answer hash. The receipt is not a transcript of private chain of thought. It is an operational proof object.
Depending on the requested audit level, it can include:
- the reasoning contract;
- the claim graph summary;
- selected and rejected routes;
- source and research coverage;
- verifier outcomes;
- unresolved claims and caveats;
- model, token, cost, and latency totals;
- policy and circuit decisions;
- the final answer hash.
That receipt helps a reviewer answer “why was this answer allowed to leave?” without exposing internal prompts or private model reasoning. It can also be retrieved later through the run receipt or evidence-packet APIs.
Receipts matter most when the answer has consequences. A recommendation with a high confidence number but no inspectable route is hard to govern. A receipt makes the confidence, gaps, costs, and controls part of the same review object.
Observe and shadow before serving Chorus
A more sophisticated route should still earn production authority. Chorus can run in observe or shadow mode while the user continues to receive the baseline answer.
Historical replay asks whether a candidate route would have behaved acceptably on recorded work. Shadow evaluation asks whether it remains acceptable on current traffic without serving its answer or repeating side effects. Punk’s replay and shadow guide explains why both forms of evidence matter.
Teams can compare the baseline, Chorus result, source coverage, verifier outcomes, cost, latency, and human feedback before enabling service. The same evidence can later teach Punk which task shapes benefit from Chorus and which should stay on a simpler route.
Where Chorus fits with coding agents
Codex and Claude Code remain agent harnesses. Chorus can become the governed model route underneath them when a coding step benefits from stronger evidence or verification.
The Codex launcher sends native Responses traffic through Punk. The Claude Code launcher sends Anthropic-compatible Messages traffic. Either harness can select punk/chorus while preserving its local tools and execution boundary.
Chorus may return text or a typed tool plan, depending on the wire and request. The harness still decides whether and how to execute locally. A reasoning receipt does not grant shell, repository, or connector authority.
A practical first Chorus evaluation
Choose one difficult, repeated task with a reviewable answer standard. Define a budget, required sources, prohibited providers, acceptable latency, and the verifier outcomes that matter. Run Chorus in shadow mode beside the current route.
Review the receipt instead of judging only the prose. Did the accepted sources cover the important claims? Did the route stop spending once the contract was satisfied? Were unresolved claims visible? Did the final answer preserve caveats? Was the additional cost justified?
Chorus is valuable when it makes difficult work more defensible—not merely when it makes the answer sound more elaborate.
Questions readers ask
Is Punk Chorus a single AI model?
No. punk/chorus is a model selector for a governed runtime route. Depending on the request and configured policy, Chorus may use evidence, deterministic circuits, one model, selected specialist models, verifiers, or a bounded candidate panel.
Does Chorus always call multiple models?
No. Chorus is designed to spend selectively. It can stop after a qualified route satisfies the contract, and it should use additional models only when unresolved claims, verification gaps, or the requested quality mode justify them.
Does a Chorus receipt expose private chain of thought?
No. The receipt contains inspectable operational evidence such as the request contract, selected routes, source coverage, verifier outcomes, costs, confidence, and answer hash. It does not expose private model reasoning or internal prompts.