About this page. Authored by me, Robert himself. The Oracle Blast concept surfaced during an adversarial review of my “orchestrator” skill — Claude drafted it under my direction afterwards — using the working records of the AI models that executed the work. The closing “Cognitive tiers” section is excerpted from Claude’s draft.

The Oracle Blast

The Best Way to Answer “Which Model Do I Choose?”

One of the first questions that pops into my head when tackling a project with AI is the inevitable, “Which model do I choose?” I have felt akin to my entire future unfolding differently depending on how I made that choice.

My AI collaborators and I had started to identify the choice based on “who” we needed: the most base models for an “intern” (fast tasks, easy-to-check, easy-to-correct), the more advanced workhorse models for a “personal assistant” (repetitive tasks that require some level of knowledge work or thought, teachable workflows that a person could learn), the heavy, competitive models for a “paid expert” (ambitious goals and tasks where the desired end is understood, but there are gaps in the plan to get there) and the frontier models for a “machine genie” (the most ambitious projects where the goal is hazily known, and almost nothing about the path forward is).

Anthropic’s own recommendation for Claude is to think of Haiku, their lowest model for fast, searchable answers and work; Sonnet as the “workhorse” for everyday tasks and workflows, Opus for ambitious tasks and projects, and Fable “for your most ambitious projects”. (A lecture provided by Anthropic that I attended specifically mentioned Fable is best with minimal prompting — more on that later).

These guidelines, no matter who gave them to me or how I implemented them, still gave me a feeling that I had chosen randomly, and I was missing something.

NEW OBJECTIVE: Remove the stress by finding a dependable method of selecting a model.

Common Pitfalls

At first, the temptation was to default to the model that was the best, highest-performing, most-frontier-and-cutting-edge, etc. However, those tokens add up quickly. Even if money is no object, I found some cases where more advanced models genuinely performed worse. As a personal assistant that triages my data and organizes it into lists and calendars, Sonnet 4.6 dependably outperformed Opus 4.8. Opus list items were too ambitious, too long, included unnecessary data. A machined divinity stuffed into a secretary’s desk. Sonnet naturally produced personal-assistant tier work, and at a slimmer cost.

I switched to an escalation model afterwards: lower models try, and only when they bump into issues or the need for multiple attempts do they flag the need to escalate. This didn’t work either, and the results were way more annoying — down the line from developing something, I would have a frontier model review it and find a lot of issues that had snowballed or gone unnoticed.

Then I tried an orchestrator model: a smarter model plans, a lower model executes. The way I explained it to Claude for building my orchestrator skill was “Opus plans and writes what’s dangerous, Sonnet writes what’s numerous, Haiku writes what’s mechanical, Fable attacks what’s irreversible.” This worked better, but still had some cost issues: namely, a ~$1610 bill in API calls. (12,449 API calls, 10.6M output tokens, ~2.57B cache-read tokens, ~$22/finding).

So I turned the model itself on the problem. I asked a frontier model for an adversarial review of my model selection logic at its fundamental cognitive tier. Here is what the model surfaced:

Strength of the Oracle

“[Your] doctrine is keyed on the wrong axis. ‘Dangerous / numerous / mechanical / irreversible’ are task adjectives; the variable that actually determines how cheap you can go is strength of the objective oracle.”

I felt less like a mAIker, more like a fAIker. What in simulacra is the “objective oracle?” Perhaps the reader will, like me, only remember vague references to the Oracle at Delphi from their Greek mythology education — something about a person in a stupor divining the future while under the influence and proclaiming it as divine insight.

To know the strength of the objective oracle, I had to start with what an oracle actually IS. Wikipedia defines an oracle as “a person or thing considered to provide insight, wise counsel or prophetic predictions.” This jives with my “Oracle at Delphi” understanding; it does not at all help reconcile what this had to do with AI.

To help grasp this concept, let’s go back to the Oracle at Delphi. Wikipedia describes prophecies being delivered “in a frenzied or ecstatic state induced by vapours rising from an opening in the rock, and that she spoke gibberish.” Say one were to hear this gibberish… then what? What does it mean? What do I do now? Am I to go out and act differently based on what looks like an asphyxiant-induced psychosis? Without any objective, falsifiable statements, without any ground truth to test, without a repo to check… “right” and “wrong” are impossible to figure out in this context without a second pair of eyes coming in to check.

The “strength” of the Oracle at Delphi was weak. One could no more make sense of what to do after the instructions than they did before. Wikipedia even goes on to say, “Priests interpreted her utterances as enigmatic prophecies and recomposed them into verse as dactylic hexameter.” Only after an interpreter intervened and wrote down the directions could the oracle carry any meaning. The priests were the “model” brought in to check the weak objective strength of the oracle.

Conversely, let’s look at another famous oracle — Noah’s prophetic vision to build an ark. Most of humanity’s oldest stories and belief systems mention a global flood, and explain what it was like before, during, and after. Well, the book of Genesis comes with an example oracle, when God warns Noah of the flood and tells him how to survive it:

…make yourself an ark of cypress wood; make rooms in it and coat it with pitch inside and out. This is how you are to build it: The ark is to be three hundred cubits long, fifty cubits wide and thirty cubits high. Make a roof for it, leaving below the roof an opening one cubit high all around. Put a door in the side of the ark and make lower, middle and upper decks.”
(Genesis 6:14–16, NIV)

He then goes on to include what to bring on the ark, where to store it, etc.

That’s a strong objective oracle. Nobody was there to interpret that oracle for Noah, but nobody was needed; Noah’s God even included precise measurements, expected food needs, the full project-manager suite of services. Since this oracle came with a well-developed plan, including even precise measurements, it was not difficult to check the output against the oracle; all Noah had to do was measure the dimensions of the completed ark, do an inventory of what was on the ark, and check it against his detailed oracle. Anybody could have checked… just measure the dimensions in cubits. This would not need any judgement to determine “right” from “wrong”. Anybody could check using a ruler and a manifest. In this case, Noah could use a lightweight, efficient model.

YOU are the objective oracle. How STRONG of an objective oracle are you? Or, more plainly, how clear vs. subjective are your directions? Are you giving the model input that looks more like precise, step-by-step directions (a full software dev plan with phases, a detailed Gantt chart, a completed novel needing to be scanned for use of passive voice, measurements for an ark in cubits, etc.)? Or does it seem more like a vague statement that provides more questions than answers (“Make me a video game”, “I want to start a business”, “get rid of all of the bugs in my app”, etc.)?

In general, the best practice is to always be the strongest objective oracle possible.

Start by giving yourself a crash dump from your brain. Get everything out of your mind and onto paper or in a .txt or .md. Stream of consciousness is fine, any length is fine; just try to capture everything about your goal that is relevant.

Next, pretend you wanted to explain to somebody how to do it. Can you reshape your stream of consciousness into a plan that somebody else can execute, and with results that are easy to check?

If not, that’s a weak oracle. And there’s no shame in that game. Much like the Oracle at Delphi had priests to check the ramblings and convert them into dactylic hexameter, consider a heavy or frontier model to check your input and convert it to your intended output.

Conversely, if you have a pretty well-mapped task or workflow, like Noah, and you just want it to be done with speed and accuracy, consider a workhorse or mechanical tier model to check your work. In that case the oracle is strong, so the model does not need to be strong to check it.

This is why that blurb from Anthropic I mentioned earlier mostly works — “minimal prompting” usually translates to a weak oracle, which needs a frontier model to check it.

Pick the model by the strength needed to check the objective oracle — a weak oracle needs a stronger model to check it, a strong oracle can be checked by a weaker model.

The Blast Radius

This one is a little more self-explanatory. The blast radius is the size of the area/s affected by the decision. Let’s say somebody is learning to play video games for the first time. They won’t know what they’re doing! If they ask for help, they won’t know how to describe it beyond, “tell me how to make the displaced plumber jump.” That’s a weak oracle. Using the strength of the oracle as a guide by itself, this issue would appear to need a heavy model or a frontier model.

However… would you ask a genie to help you make the plumber jump? Or, more relevant, is it worth it to dole out ~$22 (instead of pennies) to make the plumber jump? Probably not… if the plumber doesn’t jump, everybody wakes up tomorrow. We all have our lives as they were before he failed to jump. No new contracts have been signed, nobody is hurt… in short, nothing has happened. That’s a small blast radius. For something that inconsequential, use the most lightweight and efficient model possible. If it’s wrong you can always just try again.

Conversely, even with a very good map or idea, some things have a very wide area of effect; the dominos don’t fall correctly if the first domino isn’t arranged and pushed just right. Take my very own discovery of the Oracle Blast:

I had a very good idea of what I wanted in my /orchestrator SKILL.md, and had even used it many times. (strong oracle)
However, I realized that I use my /orchestrator skill at the start of every project, and would continue to do so (high blast-radius -> every single plan I make with AI will be affected by how well this skill is written)
Rather than use a lightweight model or a workhorse model due to the strong oracle, I shifted the choice up to a frontier model to review my skill, due to the high blast radius — I wanted the strength of the check on the oracle to be at its highest.

The Oracle Blast

Strength of Oracle x Blast Radius Matrix

I now use the Strength of Oracle x Blast Radius Matrix (“The Oracle Blast” — below, under “Assignment Law”) in almost all of my skills. Feel free to incorporate it in your own model decision making by copying everything below the next paragraph reading “OBJECTIVE: COMPLETE (Eradicate model-selection stress)”. Check out my /orchestrator and /handoff skills to see it incorporated practically — models will spin up agents using the Oracle Blast if you tell them!

OBJECTIVE: COMPLETE (Eradicate model-selection stress)

Cognitive tiers

Doctrine is written in tiers, not model names, so it survives model churn. An example of the most recent tier→model mapping lives in Local operational notes at the bottom — the only part of this file that rots. Before writing the handoff, check whether the Local operational notes model list looks stale against what you know. If you have write access to this file, update it in-place and note the revision in the handoff; if not, alert the user to the rot and ask if they would like to proceed, or stop and address the rot first. Flag if you have any uncertainty about your own training recency. If the user confirms the mapping is current or provides corrected values, proceed. If unresolved, generate the handoff with a visible WARNING block at the top of the Suggested tier section.

Tier	Characteristics
frontier	Capability: Strongest available; used sparingly — primarily as a gate and adversarial reviewer, not as a primary content generator. *Route here to generate* when: opening framing or constitutional review where the oracle’s strength is not yet established and a misframed plan compounds downstream (campaign-open plans, constitutional prompts and docs); or when an irreversible step needs a break-attempt before authorization and heavy cannot serve as its own adversarial reviewer. Route here to review when:** the oracle is weak and the blast radius is high (frontier adversarial review compensates for the absent oracle); any irreversible step regardless of quadrant; any step where blast radius is catastrophic (root-damaging, org-ending, health-adverse) — at catastrophic blast, frontier reviews every step, not only irreversible ones. Constraint: Not a default escalation from heavy. If recommending frontier, include the explicit justification (gate, irreversibility check, or framing review) in Reasoning.
heavy	Capability: High-capability orchestrator and sustained generator. *Route here to generate* when: the oracle is weak and the blast radius is high — concurrency issues, lifecycle edge cases, subtle semantic contracts, mutations to long-lived state; orchestrating any session that will call multiple agents. Constraint:** Not the default escalation from workhorse. Frontier adversarial review still applies at irreversible steps and at every step when blast radius is catastrophic, even when heavy is the generation tier.
workhorse	Capability: The default execution and verification tier. Route here when: numerous well-specified items; systematic sweeps and triage passes; verification runs and peer spot-checks on weak-oracle / low-blast work; any session where the oracle is strong or the blast radius is low enough that a wrong result costs a correction pass, not a recovery operation. Constraint: Not a substitute for mechanical when items are fully spec’d and file-scoped; not a substitute for heavy when oracle weakness and high blast radius combine.
mechanical	Capability: Spec-only execution. Route here when: every item is fully specified, spelled out individually, and scoped to named files — execution only, no interpretation or adaptation required. Constraint: Give it files, not the repo. Resolve all ambiguity before routing here; it executes specs, it does not interpret.

Adversarial review: a decorrelated agent attempts to break the output —
find inputs, edge cases, or readings that cause it to fail — without access
to the generating agent’s reasoning. The goal is falsification, not improvement.

Assignment law: Oracle × Blast-Radius Matrix

Oracle — what checks the output. Strong: a mechanical discriminator exists (a repro that flips, tests, typecheck, schema validation, a diffable ground truth). Weak: judgment-scored; no repro; right and wrong are only visible to a person after the fact.

Blast radius — the cost of being wrong. High: data integrity, irreversible effects, wide contract surface, long-lived state. Low: localized and reversible; a wrong result costs a correction pass, not a recovery operation.

Reading the conversation for oracle and blast signals

Before applying the matrix, assess the two inputs. Neither announces itself — you have to infer from the transcript.

Oracle strength

Look for evidence of a mechanical discriminator: something that will flip unambiguously from fail to pass when the output is correct.

Strong oracle signals:

A test suite, type-checker, linter, schema validator, or other automated check is in scope or already exists
The task has a diffable ground truth (a target output, a reference implementation, a spec with acceptance criteria stated as conditions)
Correctness is binary — it runs or it doesn’t, it passes or it doesn’t, the numbers match or they don’t
The session has already produced a repro that fails in the current state

Weak oracle signals:

Correctness requires a person reading the output and judging it (“does this feel right,” “is this tone appropriate,” “is this analysis sound”)
There is a rubric, but the rubric was authored for this task and has not itself been validated
The acceptance criterion is something like “the user is satisfied” or “it matches the intent”
No one in the session has named a check — the implicit standard is “I’ll know it when I see it”

If a rubric exists but was assembled for this campaign with no external grounding, treat it as weak until proven otherwise. A rubric is not automatically an oracle.

Blast radius

Look for signals about the cost of a wrong result that survives to the next gate.

High blast signals:

Irreversible or hard-to-reverse operations: deletes, migrations, deploys, publishes, sends
Shared contract surface: a public API, a schema consumed by other systems, a configuration file with downstream readers
Long-lived state: a database, a document that will be used as a source of truth by others, a spec that will be acted on by multiple agents
The session is mid-recovery from a prior failure — another wrong move compounds the damage

Low blast signals:

Changes are scoped to a private working directory, a branch, or a throwaway artifact
The output can be discarded and regenerated at negligible cost
No external system or person depends on this result until the user explicitly promotes it
The task is exploratory: its purpose is to produce a draft, not a landing

If signals are mixed — say, the output is reversible but will be read by other agents before the user reviews it — weight toward high. Downstream propagation turns a locally reversible action into a wide-radius one.

Tier the generation by what checks it, not by task adjectives.

	Strong oracle	Weak oracle
High blast	Tier: Workhorse generates; Heavy reviews Effort: Generation → high; verification → high–maximum Posture: The oracle is the arbiter — spend on verification and gates, not on generation. Heavy review compensates for the one thing the oracle cannot catch: a misframed task that produces a wrong-but-valid output. Gates: Oracle gate at every step. Irreversible steps additionally require Frontier review and explicit user authorization before execution.	Tier: Heavy generates; Frontier adversarial review Effort: Maximum throughout — no oracle exists to compensate for deliberation failures, so deliberation must be the safeguard Posture: Smallest possible steps; keep each atomic so rollback remains possible despite high blast. Adversarial review is not optional — it substitutes for the absent oracle. High effort on a misframed task buys elaborate wrongness; invest effort in framing first. Gates: User gate before anything lands; no exceptions.
Low blast	Tier: Mechanical or Workhorse generates Effort: Low–medium on generation; scale up only if the oracle reveals systematic failure Posture: Lean on the oracle — it is cheap, fast, and sufficient. Human review is optional; when applied, keep it lightweight. Do not overspend on generation when the oracle catches errors anyway. A pattern of oracle failures is the signal to escalate tier, not individual misses. Gates: Oracle gate only. No peer review required unless failures are appearing at a pattern level across items.	Tier: Workhorse generates; Workhorse peer spot-checks Effort: Medium on generation; low on review — wrong is recoverable, so the cost of a miss is a correction pass, not a recovery operation Posture: Keep review lightweight; a second Workhorse pass is the check, not Heavy or Frontier. If a pattern of errors emerges across items, escalate the review posture — not the generation tier. The low blast is what keeps this affordable; do not let weak-oracle anxiety push spend beyond what the stakes justify. Gates: No formal gate; peer judgment is the check.

Non-code campaigns: same mechanics, different nouns

The oracle × blast-radius framework applies to any campaign regardless of substrate.
Translate the code vocabulary into your campaign’s terms:

Code noun	Non-code equivalent
Isolation	Disjoint artifact ownership — each lane works on its own copies
Worktree	A lane’s private working directory
Merge	A sequential consolidation pass that folds a lane’s artifacts into the deliverable and re-runs accumulated checks
Gate	Whatever oracle grounding found or built — a validator run, rubric pass, ground-truth diff, or explicit user authorization
Repro	The failing example or violated criterion, committed as a runnable check

If no oracle exists and none can be built, declare it explicitly in the “Suggested tier and effort” section and route through the weak-oracle column. Never assert a rubric exists when none has been validated.

One structural difference from code campaigns: a flawed verdict in non-code work is as often a judgment disagreement as a broken mechanism. Gates are where competing readings get adjudicated — bring the competing interpretations alongside the refutations. If disagreement persists past two rounds, gate on the user; adjudication belongs to the gate, not the generation loop.

What transfers unchanged: the oracle × blast-radius matrix, round counts, checkpoints, and user gates.
What transfers with translation: the nouns above. Keep the handoff oriented to the campaign’s own goal — the matrix measures oracle strength and blast radius, not task shape.

Framing note: Effort multiplies wherever deliberation points. High effort on a misframed task compounds errors out of frame downstream. Spend effort where framing happens — clustering, triage, foundational gates, tasks upstream of a campaign — and let lane effort scale with problem depth only after the frame survives review.

Agentic-fleet handoffs — pin the model mapping

If the handoff this skill is producing is itself a plan intended for an agentic fleet or multiple sequential model calls, apply these three rules before writing the document:

Pull the current tier→model mapping from Local operational notes and pin it with today’s date into the plan. Do not leave tier names unresolved — a fleet executes the plan without a human in the loop to interpret “workhorse.” The pinned mapping is the execution contract. Example pin block:
   Tier→model mapping (pinned 2026-08-04)
   frontier  → Fable 5 / GPT-5.6 Sol (latest)
   heavy     → Opus 5 / Gemini Flash 3.6 (latest)
   workhorse → Sonnet / GPT-5.6 Terra (latest)
   mechanical → Haiku / GPT-5.6 Luna (latest)
Recommend a tier/effort for every planned agent, using the oracle x blast radius matrix.
List the agents in a table in the planned order they will be called. Example tier/effort table:
   | Work | Tier | Model | Effort | Why |
   |---|---|---|---|---|
   | Orchestrator | heavy | Opus 5 | high | Holds campaign state; dispatches lanes; merges |
   | Generation lane | workhorse | Sonnet 5 | medium | Well-specified items; oracle catches errors |
   | Adversarial review | frontier | Fable 5 | maximum | Irreversible step; frontier justification: irreversibility check |
   | Mechanical sweep | mechanical | Haiku 4.5 | low | Fully spec'd, file-scoped; no interpretation required |
Treat any tier→model staleness as a blocker, not a warning. If the mapping in Local operational notes looks stale and you do not have write access to update it, halt and surface the issue to the user before generating the agentic-fleet handoff plan. A fleet that
executes against a stale mapping may route work to the wrong tier with no human to catch the error mid-run.

This rule does not apply to handoffs destined for a single next agent; those can leave tier names unresolved and rely on that agent’s own Local operational notes.

Local operational notes — edit per deployment; keep out of the doctrine

Deployment-specific facts live here and only here so the rest of this file stays shareable.
Replace placeholder values with your deployment’s actuals. When the model menu changes,
update the mappings here and in new plans; the doctrine above should not need to change.

Last updated: 2026-08-03 (replace with your deployment’s values)

Tier→model mapping

frontier   → Fable 5 / Mythos / GLM 5.2 / Kimi K3 / GPT-5.6 Sol (latest)
heavy      → Opus 5 / Gemini Flash 3.6 (latest)
workhorse  → Sonnet / GPT-5.6 Terra / Gemini 3.5 Flash-Lite (latest)
mechanical → Haiku / GPT-5.6 Luna (latest)

Effort ladder

low → medium → high → xhigh → maximum

Cost multipliers (per completed item relative to mechanical; blend of per-token price and tokens consumed — re-measure when menu or pricing changes)

Tier	Multiplier
mechanical	1×
workhorse	3–5×
heavy	10–20×
frontier	≈ one heavy item at maximum deliberation

Deployment constraints (pricing caps, quota limits, compliance terms — add rows as needed)

Constraint	Detail
(none recorded)	—