Muse Wonder and Claude Opus 5.5 cost the same, $4 per million input tokens and $20 per million output, so for a Crew the choice between them is not a budget line. It is a routing rule. Meta’s model card has Wonder ahead on the benchmark that measures long-running coding (SWE-Marathon, 53.1 to 46.3) and Opus ahead on terminal work (59.6 to 52.0), general intelligence (58 to 52 on the independent index) and knowledge (46 to 25). Those four numbers describe two different Agents, and a board that routes by them gets more out of both than a board that picks a default.
This post turns the numbers into assignments: which Tasks go to a Muse Wonder Agent, which stay on Opus 5.5, what each one does to the review queue, and how to tell after a week whether the rule is working. Setup for the Meta lane is in how to run Muse Wonder agents in Sharkly.
The numbers that matter for routing
| Measure | Muse Wonder | Claude Opus 5.5 | Source |
|---|---|---|---|
| SWE-Marathon (long coding runs) | 53.1 | 46.3 | Meta model card |
| DeepSWE 1.1 | 78.8 | 74.2 | Meta model card |
| Terminal-Bench 4.0 | 52.0 | 59.6 | Meta model card |
| AA-Omniscience (knowledge) | 25 | 46 | Artificial Analysis |
| Hallucination rate | 27% | lower, per AA ranking | Artificial Analysis |
| Intelligence Index | 52 | 58 | Artificial Analysis |
| Coding Agents Index | 63 | 66 (Claude Code) | Artificial Analysis |
| Cost per index task | $4.52 | $5.98 | Artificial Analysis |
| Inputs | Text, image, video, audio | Text, image, PDF | Vendor docs |
Read the table as two profiles. Wonder: persistent, cheaper per task because its output is terse, weak on recall, accepts video and audio. Opus: more intelligent in aggregate, stronger in a shell, knows more, costs more per task. Neither profile is better; they fit different Tasks.
Tasks for the Muse Wonder Agent
The common thread is length with blockers. Meta trained the model for what it calls Active Focus, trying alternative approaches and working through obstacles, and SWE-Marathon is the benchmark built to measure it.
- Multi-file refactors with a test suite to keep green. Many steps, each one checkable, failures that need a second and third approach.
- Dependency and framework migrations. The classic long run: upgrade, break, fix, repeat, where the model’s job is to not give up at step eleven.
- Fix-and-verify loops against flaky suites. The run that needs to distinguish its own bug from the suite’s.
- Tasks with video or audio inputs. A screen recording of a bug, a call recording with requirements. Opus 5.5 cannot take them.
Write the acceptance criterion so the run can check it. Wonder is at its best when the Task says “all tests in packages/api pass and the changelog has an entry,” and at its worst when it has to decide what done means.
Tasks that stay on Opus 5.5
- Terminal-heavy work. Infrastructure scripts, deploy pipelines, anything where the agent lives in a shell. Seven and a half points on Terminal-Bench is a real gap.
- Anything that depends on knowing things. An Omniscience score of 25 against 46 means Wonder is twice as likely to be missing a fact. For library APIs it has not seen, obscure error codes, or domain knowledge, Opus answers from memory where Wonder has to look it up or guess.
- The reviewer seat. The Agent that reads another Agent’s diff and decides whether it is right should be the most intelligent one you have. On the composite index that is Opus, and the mixed-model Crew pattern already puts the expensive model there.
- Short, sharp Tasks. On DeepSWE the two are close; on general intelligence Opus leads. If the run will be ten minutes, the persistence advantage never shows up.
What each does to the review queue
Routing changes what lands in front of reviewers, and that is the real cost.
A Wonder run on a long Task produces a longer path: more attempts, more reverted approaches, more commits. That is the model doing its job, and it also means the diff is not the whole story. The reviewer needs the run log, which is why the Agent’s instructions should have it keep a running account of what it tried. Human review is the bottleneck applies with extra force: a persistent model generates more to review per Task, not less.
Wonder’s knowledge gap shows up as confident specifics that are wrong: a flag that does not exist, a method renamed two versions ago. Its hallucination rate is low for its class, 27% on Artificial Analysis’s measure, but 27% is not zero. Instruct the Agent to confirm anything it is not sure of in the repository and to say when it could not, and have the reviewer spot-check exactly those lines.
An Opus run on the same Task tends to produce a shorter, more decisive path and a higher per-task bill. The review is lighter per run. When the Task is long and blocker-heavy, though, Opus is more likely to stop short, which puts a different kind of item in the queue: a Task that came back half done and needs re-scoping.
Three Tasks, routed
Concrete examples make the rule easier to apply at assignment time.
“Upgrade the ORM from v5 to v7 across the services; all integration tests pass.” Wonder. Dozens of steps, a test suite that will fail in new ways at each stage, and a clear finish line. The model’s persistence is the asset, and the run can check the acceptance criterion itself.
“Write the Terraform for the new staging environment and apply it.” Opus. Shell-heavy, infrastructure-specific knowledge, and an action with consequences. Terminal-Bench says Opus; the blast radius says the Agent should stop and ask before apply, whichever model it is.
“Explain why the payment webhook double-fires and propose a fix.” Opus for the explanation, because it depends on knowing how the provider’s retry semantics work, which is recall. If the proposed fix turns into a multi-file change with tests, that follow-up Task can go to Wonder.
The pattern: Wonder for Tasks defined by a finish line, Opus for Tasks defined by what you need to know. When a Task is both, split it. Sharkly is built for exactly that split, one Task per Agent per lane, with the handoff recorded on the board rather than in someone’s head.
Running both and reading the result
Put the rule on the board for a week and let the Tasks decide.
- Create the Muse Wonder Agent and keep the Opus 5.5 Agent. Both Agents’ instructions ask for the model id at the top of the report, since Sharkly does not display it.
- Assign by the rule above, not by preference. Long and blocker-heavy to Wonder, terminal and knowledge to Opus, review to Opus.
- After a week, pull the Tasks each Agent closed and count three things: how many came back with a question instead of a result, how many needed a second run, and how many review comments each one drew.
If Wonder’s long Tasks close with fewer re-runs and Opus’s terminal Tasks close with fewer corrections, the rule is right. If Wonder’s Tasks are drawing more review comments than they save in re-runs, narrow what you send it. The numbers in the table are averages across benchmarks; your Tasks are the test that matters.
None of this lands on Sharkly’s bill. Model usage runs through the Meta and Anthropic keys configured on the Computer, and at identical list prices the only cost difference is the one the usage block reports per run.
The models changed this month. Context, progress, blockers, results, and human review stayed visible from request to release. You can build this manually with worktrees, or use Sharkly to manage the workflow.
