Fleet Strategy Brief

1 Should every agent be an Opus 4.8 orchestrator?

Your proposal: run every fleet agent on Opus 4.8 max as a thin orchestrator that spawns cheap Sonnet workers. I pushed back, you pushed back harder, and we landed somewhere better than either starting point. Here is the converged design and why.

The binding constraint

It is not dollars. All 10 agents share one Claude Max subscription. The real limit is the rolling 5-hour and 7-day usage windows. We recently added ~4x headroom (the 20x-plan routing change), and that headroom is exactly what turns this from "no" into "worth testing."

Where we started

Tier	Agents	Model / effort
Orchestrators	Sage, Apollo, Scribe	Opus 4.8 · max
Workers	Forge, Mercury, Felix, Librarian, Hippocrates, Argus	Sonnet 4.6 · high

We already tier by role. The proposal was to flip all six Sonnet workers up to Opus-max orchestrators.

What's right about it

It generalizes our own playbook: Opus as thin orchestration, Sonnet for labor.
Puts the best model on the highest-leverage cognition: decomposition, routing, knowing when an answer is wrong.
An orchestrator fans out 3–5 workers in parallel — wall-clock a single linear session can't match.
Adversarial verification becomes native: Opus designs a second worker to refute the first.

What's wrong / the catch

Multi-agent is a token multiplier (~15x), not a saver — it buys quality and parallelism, against a fixed pool.
Spawn overhead inverts the benefit on small tasks: a 2-min job is cheaper done inline — at Opus cost.
"Inverse scaling" is real: more thinking can worsen accuracy on easy tasks (classify, filter, dedup).
Quota bursts: 10 always-on Opus agents pinging the same 5h window concurrently is the failure mode.

Your key correction: prompting direction

"A higher-reasoning model prompting a lower one beats a lower model prompting a higher one."

This is sharper than my original "let workers escalate to Opus" idea, and it's correct. Spec-writing is itself a reasoning task. When a Sonnet worker escalates upward, it frames the problem — and can under-specify or drop the load-bearing detail, capping the Opus it calls. So top-down (Opus prompts down) genuinely beats bottom-up (Sonnet hands up). That demotes my "universal escalation" recommendation and reframes the whole question.

The routing axis is therefore not "how important is the agent" but "how hard/variable is the task framing, and is the decomposition parallelizable?"

Hard / variable framing + parallel work → Opus orchestrator prompting down to Sonnet workers.
Simple / stable / sequential framing → Sonnet native; framing isn't the bottleneck.

What the research said

Anthropic's own Opus-orchestrator + Sonnet-workers system won 90.2% over single-agent Opus — at ~15x the token cost. This empirically validates your top-down instinct.
The 15x multiplier means it only pays for genuinely parallel / breadth-first work. Sequential, reactive work (inbox, cron probes, one-specialist hand-offs) pays the spawn tax for zero parallelism return.
Effort gains are logarithmic — first doubling of thinking helps a lot, later doublings barely. High-vs-max on a simple task is negligible quality, real cost.

The resolving move (yours): the sliding-effort Opus orchestrator

Your point that closed it: the heartbeat is not nothing-work. Scanning state and deciding what's worth doing is a judgment task — that's Opus's job, not Sonnet's. So:

Heartbeat = low-effort Opus. Cheap scan, Opus judgment about what to work on, at a low floor.
Slide effort up on a real find. Escalate reasoning depth only for the hard work, only when found.
Top-down spawn for execution. Once it knows what to task out, it spawns Sonnet workers (Opus prompts down).
Opus sub-sessions for the genuinely complex sub-problems.

The load-bearing fact (verified against first-party Anthropic docs): effort=max is a ceiling, not a force-pin — as long as Adaptive Thinking is on (default in 4.6+ / Claude Code). Adaptive Thinking self-allocates thinking per prompt: nearly free on an empty heartbeat, deep on a hard find. Which means our current Opus-max agents already scale down on easy prompts — they are not burning max thinking every beat. My earlier "always-on Opus burns the pool on idle" objection was weaker than I stated, and I'm correcting it on the record.

Verdict

Test, don't flip

Run the A/B — but wire the guardrails first.

At 1x headroom, "always-on Opus burns the pool" was a hard constraint and a flat no. At 4x headroom it's a testable hypothesis. But Codex is right that a naive flip teaches us nothing and risks a quota wall — so the experiment needs per-agent quota budgets + a kill-switch + matched-task scoring wired in before Forge flips. See the Codex pass below.

The experiment

Flip Forge (currently Sonnet = clean baseline, high task volume, measurable output) to a low-floor adaptive Opus orchestrator with strict top-down Sonnet spawning, for one week.
Measure: (a) quota consumed vs its Sonnet baseline, (b) output quality on its task stream, (c) wall-clock.
Decision rule: if the quality gain justifies the quota delta given 4x headroom, expand the tier. If not, role-tiering holds.

One open implementation question (for Forge)

Can reasoning effort slide within a single live cortextos session as an explicit runtime dial — or do we rely on adaptive-thinking (automatic) + spawn-up (explicit) to get the same low→high curve? This is an implementation detail, not a flaw in the design.

Codex adversarial pass

Codex came back harder than I did — verdict REVISE, not "ship the test." Its core point: the idea is plausible, but it isn't decision-grade until it proves quota safety, measurement validity, and rollback behavior under rolling-window pressure. The most important finding is quantitative, and it changes the experiment design. I'm presenting it straight.

🤖Codex stress-testREVISE

1 · "Top-down beats bottom-up" is load-bearing but still hand-wavy

An Opus orchestrator can amplify a bad task frame into many confidently-wrong Sonnet outputs. Fix: mandatory spec checks (adversarial self-review, worker challenge prompts, explicit acceptance criteria) before any worker fan-out.

2 · The 15x multiplier can erase the 4x headroom (the big one)

The math: fleet-wide adoption is ~15x baseline = exceeds 4x headroom by 3.75x. Even one flipped agent stays under 4x only if Forge is under ~21% of total baseline fleet usage. Fix: hard per-agent rolling-window budgets, concurrency caps, and a rule that orchestration disables once projected 5h/7d usage crosses a safety threshold.

3 · One-agent / one-week A/B is NOT decision-grade

It confounds model, orchestration strategy, task mix, operator behavior, quota state, and latency all at once. Fix: replay matched historical Forge tasks, pre-register scoring rubrics, measure normalized quality per token and per hour, run paired Sonnet-vs-Opus on the same task samples.

4 · Burst-collapse failure mode is unaddressed

Simultaneous "real finds" across the always-on fleet all spawn workers at once → latency spikes, task starvation, fleet-wide quota lockout. Fix: central scheduler that reserves quota for heartbeats, queues noncritical fan-out, enforces global spawn limits, and degrades to Sonnet-only before hitting the window wall.

5 · The Adaptive Thinking assumption may not hold

Low-effort Opus reliably detecting when to spend more is unproven in this setup — easy-looking tasks hide hard constraints, hard-looking ones waste effort. Fix: treat adaptive effort as a hypothesis — log all trigger decisions and missed/false escalations, define explicit spawn-up rules for known high-risk task classes.

6 · Hidden assumption: framing difficulty can be classified cheaply up front

The whole routing axis assumes you can cheaply judge "hard framing + parallelizable" before doing the work. Fix: lightweight routing checklist, sampled audits of routing mistakes, default-to-Sonnet for any case where the EV of orchestration can't be written down explicitly.

My read on the disagreement: Codex and I agree the idea is sound in principle and we converged on the same top-down direction you pushed. Where Codex is right and I was loose: finding #2 (the headroom math) and #3 (my one-agent A/B is too confounded to be decision-grade). So the honest recommendation tightens: still worth running, but the experiment needs per-agent quota budgets + a kill-switch + matched-task scoring wired in before the flip — otherwise we learn nothing trustworthy and risk a fleet-wide quota wall. That's a Forge build item, not a blocker on the decision.

2 YouTube thumbnail engine

Scribe flagged the current thumbnails read like a content mill (split-panel, garbled in-model text). Here's the validated engine spec, the pilot plan, and why we are not building a 395-clip factory yet.

High-CTR principles (2024–2026, sourced)

Face + emotion: faces ~38% higher CTR; expression drives ~60% of emotional impact; face fills ≥40% of frame height.
Text 3–5 words max (1–3 is the sweet spot); >5 collapses at mobile scale.
Mobile legibility: 70%+ views are mobile — must still read when downscaled to 120px wide.
Single focal subject: one hero, rule of thirds. Split-panel = content-mill look (confirms Scribe's diagnosis).
Curiosity gap: "Why your head feels heavy" beats "Posture Science" 2–4x.

The key call: composite text in code, not in-model

Gemini Nano Banana Pro has no native face-lock (a 12-thumbnail batch of a named doctor will drift) and is inconsistent on fine letterforms (brand type occasionally garbles). So: use Gemini for the background plate + relit cutout only; overlay headline/brand type via code (HTML/CSS+Playwright or Pillow). Pixel-perfect brand type, zero text-render risk, text swaps without regenerating.

The engine recipe

Background plate (Gemini): topic keyword → branded gradient + depth blur + brand-color glow. No face, no text. 1280×720.
Doctor cutout: pre-approved expression still → segment (rembg) → anchor ~50% frame height → subtle pink/gold edge glow.
Text compositing (code): 3–5 word curiosity hook, Montserrat ExtraBold, white + heavy black stroke + shadow.
Mobile-120px gate: resize to 120px, check text-vs-bg contrast, auto-bump stroke and retry on fail.
Per-topic variety: vary background hue + expression (pain=empathetic, myth-bust=skeptical, how-to=pointing); hold face anchor, text zone, font constant.

Pilot plan (from Scribe, this morning)

Item	Status
Compositing toolchain (Pillow + Playwright + Gemini + nano-banana skill)	VERIFIED ready — 2 quick internal installs left (rembg, Montserrat). Answers your Q2.
Individual approved doctor stills	GAP — only have `doctors-group-3docs.png`. Pilot proves format on best-available enhanced frames; shoot is the quality upgrade, not a launch gate.
Pilot scope	6 thumbnails, one per topic archetype (pain, myth-bust, how-to, pediatric, prenatal, wellness) — not 395.
CTR loop	Baseline current CTR → swap → measure 7d / 1k impressions → gate at not-worse, target +15% rel, before any scale.
Reversible scaffolding	GREENLIT — Scribe building now (installs, compositor fork, manifest+review schema, 6 pilot hooks). Zero image-gen, zero channel swaps until you approve.

Codex adversarial pass — thumbnail engine

🤖Codex stress-testSHIP-WITH-FIXES

1 · No validation loop (biggest risk)

The engine could process all 395 clips and never know if the new format beats the old on real CTR. Fix: build the CTR measurement loop in from day one — ship a small batch, measure, then scale. No factory before the format is proven.

2 · Don't categorically ban in-model text

For 3–5 word headlines, Gemini's in-image text can integrate lighting better than a pasted overlay. Fix: code-composited text stays the default, but add an experimental bakeoff lane — pick by CTR, not assumption.

3 · Real photo shoot is NOT a launch blocker

"Non-negotiable shoot" turns a quality upgrade into a stall. Fix: two paths — ship-now from existing approved stills, upgrade later with a controlled shoot. Schedule it, don't gate on it.

4 · WCAG 4.5:1 is a guardrail, not truth

It's an accessibility standard, not a CTR standard — can reject punchy designs. Fix: keep the 120px gate, add OCR/readability + clutter detection + manual sampling + CTR feedback.

5 · Cutout/relight needs QA, relight risks likeness

rembg fails on hair/glasses/coats; relighting can subtly alter the doctor. Fix: mask preview + edge checks + manual cleanup queue + a "no relight" fallback for likeness-sensitive photos.

6 · Missing production scaffolding

No output validation, batch manifests, review states, YouTube file gates, brand-safety policy. Fix: add these before treating it as a build ticket. (Scribe is building exactly this scaffolding now.)

→ What I need from you

Model routing

Greenlight the 1-week Forge A/B? Flip Forge to low-floor adaptive Opus orchestrator + strict top-down Sonnet spawning, measure quota / quality / wall-clock against its Sonnet baseline. (My recommendation: yes — it's cheap at 4x headroom and converts the whole debate into a measurement.)

Thumbnail engine

Q1 — Schedule a doctor expression shoot? Scribe default: yes schedule it, but do not gate the pilot on it.
Q2 — Compositing toolchain? Effectively answered — Scribe has Pillow + Playwright ready. Default: code-composited text.
Q3 — One doctor or three per thumbnail? Scribe default: one (multi-person breaks Gemini face preservation and tests higher CTR).
Data gap: the CTR loop needs confirmed read access to VE YouTube Studio analytics — or tell me who holds it and I'll route the metric pull there.

Everything reversible is already moving (Scribe's scaffolding). Nothing gets generated or published, and no agent gets flipped, until you say go.