You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It is a Claude Code plugin that turns a session into a three-role pipeline instead of one model doing everything:
an architect on the most capable model that never types implementation code — it owns decomposition, writes a fully self-contained spec per unit of work, picks a reasoning effort per unit, and judges the evidence that comes back;
one or more implementer lanes on a cheaper (and deliberately different-vendor) model that receive the spec with none of the architect's conversation context and return a structured report with verification evidence;
an advisor on the strong model again, in a clean context, that reads the accumulated diff against the stated goal before anything is called done.
The economics are the point: judgment tokens are expensive and low-volume, implementation tokens are cheap and high-volume, and the premium is spent only where it changes the outcome.
Why PortOS should have this
A PortOS Chief of Staff task today resolves to exactly one provider and one model for the whole run. selectModelForTask (server/services/agentModelSelection.js) picks a tier once at spawn from complexity heuristics plus taskLearning history, resolveThinkingLevel (server/services/thinkingLevels.js) resolves a single run-level effort from task.metadata.thinkingLevel, and agentProviderResolution.js resolves one provider (with a fallback chain) for the run. There is no way to say "plan this on the strongest model, let a cheap model do the typing, then have the strong model check the result against what I actually asked for."
That costs the user real money on every heavy task: today a task that needs strong reasoning for ten minutes of planning pays the premium model's rate for the other fifty minutes of mechanical editing too. It also means every PortOS agent run is single-vendor — the model that wrote the code is the model family that reviews it, so shared blind spots survive.
The user-facing outcome
On the CoS task form and in AI Providers (/ai), the user can pick an orchestration profile for a task: which provider/model is the architect, which is the implementer lane, and which reviews the result. A task run in orchestrated mode shows, in /cos/agents, which lane produced each part of the work and what each lane cost. When the cheap lane is unavailable the run fails loudly rather than quietly re-spending on the architect's model. Before the run reports done, the finished diff is checked against the task's own stated objective.
Recommended defaults
Off by default. Orchestrated mode is opt-in per task and per app-task pin; the existing single-provider path stays the default so no existing task changes behavior.
No implicit lane substitution. If the implementer lane's provider is unavailable, the run stops with a named reason. The whole point of the profile is the cost/vendor split; silently swapping it away is worse than failing.
Effort is named per delegated step, not once per run — the architect picks the lowest adequate rung for each spec.
The reviewer sees the objective. A code-quality review that never saw what was asked cannot catch "shipped something else".
Provenance: studied
DannyMac180/fable-advisor(MIT, © 2026 Dan McAteer) on 2026-09-03. Clean-room: no code, prose, or config copied — only the technique is described, reimplemented against PortOS's own modules.What the studied repo does
It is a Claude Code plugin that turns a session into a three-role pipeline instead of one model doing everything:
The economics are the point: judgment tokens are expensive and low-volume, implementation tokens are cheap and high-volume, and the premium is spent only where it changes the outcome.
Why PortOS should have this
A PortOS Chief of Staff task today resolves to exactly one provider and one model for the whole run.
selectModelForTask(server/services/agentModelSelection.js) picks a tier once at spawn from complexity heuristics plustaskLearninghistory,resolveThinkingLevel(server/services/thinkingLevels.js) resolves a single run-level effort fromtask.metadata.thinkingLevel, andagentProviderResolution.jsresolves one provider (with a fallback chain) for the run. There is no way to say "plan this on the strongest model, let a cheap model do the typing, then have the strong model check the result against what I actually asked for."That costs the user real money on every heavy task: today a task that needs strong reasoning for ten minutes of planning pays the premium model's rate for the other fifty minutes of mechanical editing too. It also means every PortOS agent run is single-vendor — the model that wrote the code is the model family that reviews it, so shared blind spots survive.
The user-facing outcome
On the CoS task form and in AI Providers (
/ai), the user can pick an orchestration profile for a task: which provider/model is the architect, which is the implementer lane, and which reviews the result. A task run in orchestrated mode shows, in/cos/agents, which lane produced each part of the work and what each lane cost. When the cheap lane is unavailable the run fails loudly rather than quietly re-spending on the architect's model. Before the run reports done, the finished diff is checked against the task's own stated objective.Recommended defaults
Phases (each independently shippable)
orchestratedexecution mode, and the per-step spec+effort contract.Scope: large — one epic, three phases; phase 1 is the load-bearing one.
Decomposed into
orchestratedexecution mode, and the per-step spec+effort contractThe agent that ships the LAST open child should tick its box here and close this epic with a summarizing comment.