TL;DR
The cheapest acceptable model is not necessarily the smallest model, and the highest-scoring model is not automatically the safest choice. The useful routing question is: what evidence does this step need, what can happen if it is wrong, and how will the workflow recover?
OpenAI released GPT-6 Sol and Luna on September 22, 2026, with lower API prices than their GPT-5.6 counterparts. Anthropic released Claude Opus 5.5 the same day and said it costs less to run than Opus 5. Microsoft and Google already document model routers that trade off cost and quality. Together, these are strong signals that model choice is moving from a one-time vendor decision into a per-task workflow decision.
For meeting and knowledge work, use four lanes:
1. Extract: recover explicit facts into a fixed structure. 2. Synthesize: connect supplied evidence without inventing missing context. 3. Judge: compare tradeoffs or propose a decision for human review. 4. Act: change an external system only behind explicit authority and verification.
Start with the lowest-cost lane that passes your own task-specific test. Escalate when evidence is missing, sources conflict, the output is hard to reverse, or the model would cross an authority boundary. A stronger model can improve a draft. It cannot grant permission, make an unsupported claim true, or turn an unverified summary into a decision record.
What changed on September 22
OpenAI introduced GPT-6 Sol and GPT-6 Luna as lower-cost members of the GPT-6 family. Its published API prices are $2 per million input tokens and $10 per million output tokens for Sol, and $0.10 input and $0.50 output for Luna. OpenAI describes both as 50% cheaper than the promotional prices of their GPT-5.6 predecessors.
The same day, Anthropic introduced Claude Opus 5.5. Its published API prices are $4 per million input tokens and $20 per million output tokens. Anthropic says cheaper tokens plus lower token use reduce the cost of running Opus 5.5 by 40% compared with Opus 5.
Those are vendor claims and vendor-reported evaluations. Their benchmark harnesses, effort settings, safety behavior, token use, and task mixes are not interchangeable. OpenAI's strongest claims do not prove that Sol or Luna is best for your meeting workflow. Anthropic's strongest claims do not prove that Opus 5.5 is the right escalation model for every decision.
The durable development is the shape of the market: vendors are shipping capability and cost tiers at the same time, while cloud platforms are making routing a product primitive.
- Microsoft documents cost-optimized, quality-optimized, and balanced routing, and explicitly recommends evaluating individual models in the workload rather than treating routing as a substitute for model knowledge.
- Google Cloud announced an experimental Vertex AI Model Optimizer in April 2025 to route prompts according to a requested balance of quality and cost.
The wrong way to route meeting work
Three shortcuts look efficient and fail in predictable ways.
Route by transcript length
A long source can still require simple extraction. A one-line request can require delicate judgment. Input size affects context limits and cost, but it does not tell you the consequence of a mistake.
Route every task to the strongest model
This pays frontier-model cost for routine formatting and classification while hiding whether a smaller model could meet the same quality bar. It also encourages teams to treat model reputation as a substitute for evaluation.
Route every task to the cheapest model, then retry
Retries can cost more than correct first-pass routing. More importantly, repeated low-quality output can erase source distinctions, invent ownership, or create an external commitment before anyone notices the failure.
The routing unit should be the work step, not the whole meeting and not the model name.
Four lanes for evidence-first routing
Lane 1: Extract
Use the extract lane for bounded transformations with explicit source support and a fixed schema.
Examples:
- list every date stated in the transcript;
- copy agreed action items into
owner,task, anddue_datefields; - classify each follow-up as customer, product, legal, or unresolved;
- normalize names against an approved participant list.
A fast, low-cost model can be a good fit if it passes a representative extraction test. Escalate when the source is noisy, two speakers contradict each other, a required field depends on unstated context, or the schema itself is ambiguous.
Lane 2: Synthesize
Use the synthesize lane when the model must connect several supplied facts but should not decide what the team will do.
Examples:
- group repeated customer objections and preserve the evidence for each group;
- compare a meeting decision with the current project brief;
- draft a weekly update from reviewed meeting records;
- separate decisions, proposals, open questions, and rejected options.
Escalate when sources conflict, an old document may have been superseded, the output collapses proposals into decisions, or a missing fact changes the conclusion.
Lane 3: Judge
Use the judge lane when the model is asked to compare tradeoffs, find a failure in a plan, or recommend a next step.
Examples:
- compare two product options against an approved rubric;
- identify which customer commitments are at risk;
- review a hiring scorecard draft for unsupported claims;
- challenge a project plan against the evidence discussed in the meeting.
Escalate to a domain owner, not merely another model, when the task involves legal, employment, financial, security, medical, or other high-impact judgment. Model escalation and human escalation solve different problems.
Lane 4: Act
Use the act lane only when the workflow has permission to change an external system.
Examples include creating a ticket, updating a reviewed backlog item, saving an approved note, or sending a message. Each action needs an explicit destination, allowed fields, authorization rule, preview or verification step, and recovery path.
The model that drafted the output should not silently expand its own authority. A frontier model may be better at following a complex instruction, but capability is not permission. For irreversible or public actions, use human approval or a policy-enforced gate even when the model's confidence is high.
A routing card for one workflow
Before automating model choice, write one card for the workflow.
| Field | Question |
|---|---|
| Task | What exact transformation, comparison, recommendation, or action is requested? |
| Evidence | Which transcript, screen, document, policy, or system state may be used? |
| Consequence | What happens if the output is incomplete, wrong, or sent to the wrong place? |
| Test | What observable result determines whether this model tier passes? |
| Escalation | Which missing, conflicting, sensitive, or high-impact condition routes upward or stops? |
| Authority | Who may approve the output or external action? |
| Recovery | Can the change be previewed, corrected, rolled back, or replayed from the source? |
This card is deliberately independent of model names. Model families will change. The evidence and consequence boundaries of a real workflow should be more stable.
Worked example: from a product meeting to a backlog update
Imagine a product review where the team discusses an onboarding failure, looks at two screenshots, proposes three fixes, selects one experiment, and leaves the launch date unresolved.
One prompt that asks a single model to “summarize the meeting and update the backlog” hides four different jobs.
| Step | Lane | Required check |
|---|---|---|
| Recover the exact failure, owners, and dates | Extract | Every field points back to the meeting source |
| Group screenshots and transcript statements by proposed fix | Synthesize | Disagreement and missing evidence remain visible |
| Compare the fixes against the approved success criteria | Judge | Recommendation cites the rubric and includes a counterargument |
| Update the selected backlog item | Act | A person confirms selection, fields, and destination before write |
The first step may pass on a low-cost model. The second may need a balanced model because it crosses transcript and visual evidence. The third may justify a frontier model. The fourth is not solved by picking a stronger model; it is solved by a clear approval and write boundary.
If the transcript says “Sam can probably take this” but nobody accepts ownership, the extraction should return owner: unassigned. If the screenshot version does not match the current product, synthesis should flag the mismatch. If the rubric is missing, judgment should stop. If the destination item is unclear, the action should not run.
That is failure-driven routing: the workflow escalates because a specific quality or authority condition was triggered, not because a vendor published a higher benchmark score.
Build a test set before building a router
Do not evaluate on polished examples alone. Collect a small set that represents the failures your workflow actually sees.
Include:
- a clean meeting with explicit decisions and owners;
- a noisy meeting with corrections and overlapping speakers;
- a meeting where proposals are discussed but nothing is selected;
- conflicting transcript and document evidence;
- a missing screenshot or unavailable source;
- a request that exceeds the user's authority;
- an output destination that cannot be verified.
1. Source recovery: Can each important claim be found in the allowed evidence? 2. Unsupported commitment rate: Did the model invent a decision, owner, date, or promise? 3. Material omission rate: Did it drop disagreement, a constraint, or an unresolved item? 4. Escalation recall: Did it stop or route upward when the test expected it to? 5. Structured-output validity: Did required fields and status labels survive? 6. Action safety: Did it avoid writing when approval, destination, or permission was unclear? 7. Human correction time: How much work was required before the output was safe to use? 8. Task cost and latency: What did a passing result cost, and how long did it take?
Choose the least expensive tier that clears the quality bar across the test set. Re-run the test when the model, prompt, source format, tool access, or destination changes. A model version upgrade is a workflow change even when the API name looks familiar.
Where a personal AI interface fits
Shadow is an AI interface for Mac that sees, hears, and runs. Its role in this framework is the work surface: authorized meeting context, relevant screen context, a configured Skill, and an output destination can remain connected instead of being manually copied through separate apps.
Shadow's current Meeting Skills and Action Skills are user-configured workflows. Its privacy and data guide explains when content remains local and when optional features send selected content to external services.
This article does not claim that Shadow currently exposes automatic model routing, chooses among GPT-6 Sol, Luna, and Claude Opus 5.5, or makes approval decisions. The four-lane framework is a way to design and evaluate personal-AI workflows as model choice becomes more granular.
The product implication is narrower: the model should not be the only thing a workflow remembers. A reliable personal AI also needs the source boundary, status of the claim, allowed action, human owner, and recovery path.
What is real, what is interpretation, and what remains unproven
Real now
- OpenAI published GPT-6 Sol and Luna prices and availability on September 22, 2026.
- Anthropic published Claude Opus 5.5 pricing and its own cost and performance claims on September 22, 2026.
- Microsoft documents routing modes, and Google has documented an experimental model optimizer that trades off cost and quality.
- Teams can evaluate different models on the same task-specific examples and keep model selection separate from action authorization.
Interpretation
- The four lanes in this article are an original workflow-design frame for meeting and knowledge work.
- Failure-driven escalation is more durable than assigning one permanent model to every task.
- Better cost-to-capability tiers make per-step routing more useful, but only when evaluation and observability travel with the route.
Unproven
- Vendor benchmarks do not establish which model is best for your transcripts, documents, permissions, or destinations.
- Lower token prices do not guarantee lower cost per successful task after retries and review.
- A router does not guarantee factuality, privacy, correct authorization, or a safe external action.
- This article does not report a head-to-head Shadow test of GPT-6 Sol, Luna, or Claude Opus 5.5.
The decision rule
Route by evidence, consequence, and recovery.
Use a low-cost model for bounded extraction when it passes the test. Use a balanced model when synthesis must preserve several sources. Use a stronger model when judgment is genuinely difficult. Put every external action behind the authority and verification the consequence requires.
When a step fails, name the reason. Missing evidence should ask for evidence. Conflicting sources should ask for review. High consequence should ask for an owner. Unclear authority should stop the action.
If your work begins in a meeting or on a Mac screen, download Shadow and test one bounded Skill. Start with a workflow where every important claim can be recovered and every handoff can be inspected.
Sources and verification date
This article was researched and verified on September 25, 2026.
- OpenAI: Introducing GPT-6 Sol and Luna, September 22, 2026.
- Anthropic: Introducing Claude Opus 5.5, September 22, 2026.
- Microsoft Azure Architecture Center: Choose the right AI model for your workload, accessed September 25, 2026.
- Google Cloud: Gemini 2.5 on Vertex AI and Vertex AI Model Optimizer, April 9, 2025; accessed September 25, 2026.
This article was written by Chad Oh, Shadow's AI writer. While we strive for accuracy, AI-generated content may contain errors. If you spot something off, let us know.