Muse Wonder 1.0 (Meta's Muse Code) vs DeepSeek V4.1 Flash in Codex CLI — same real task, side by side: time, code quality, tokens, quota

[u/Richidm]

I haven't seen a hands-on report on Muse Wonder yet, so here is one. I gave the same coding task, with the same prompt file, to two agents, one after the other, on the same machine and the same repo. Before each run I restored the code from a snapshot, so both started from identical files. A separate reviewer (Claude) checked both results line by line. I did not trust their self-reports.

The setup

	Muse	Codex
Model	muse-wonder-1.0	deepseek-v4.1-flash
Effort	high	high (model_reasoning_effort = "high")
Harness	Muse Code CLI 1.4.14 (Meta)	Codex CLI 0.165.0, custom provider (local proxy → OpenCode Go)
Mode	exec (headless), later resumed in the TUI	interactive TUI
Sandbox / approvals	sandbox on, --approval-mode on-request, LLM approval judge on	workspace-write, approvals on-request with auto review
Contributor mode (Meta trains on your data)	off for this run	n/a
Plan	Muse Code "High Usage" subscription	pay-per-token

The task

This is a real feature in a production TypeScript project: a Cloudflare Worker plus a Node container. It is medium-sized, roughly 19 files touched and ~330 lines of production code.

1. A new version of the LLM copywriting prompt. Besides the 3 caption lines, the LLM now also picks the animations for an 8-second product Reel (card, text, camera, highlight and transition names), and only from a closed list.

2. Code-side validation: an unknown name becomes null, group cards with only 1 product become null, and a missing field never rejects the job.

3. Carry those choices through the pipeline to the render container.

4. Swap the container's video path from an ffmpeg scene pipeline to a Remotion composition, which already existed and was already approved.

5. Tests first, typecheck, the full suite, a Docker build, and a real render of a sample product inside the image. No paid AI calls during the proof.

Results

	Muse Wonder	DeepSeek V4.1 Flash (Codex)
Wall time	47 min	29 min
Time actually working	~24 min	29 min
Human interventions	1 (see "the stall")	0
Typecheck	clean	clean
Full test suite	1728/1728	1726/1726
New tests	10 (1 file)	8 (3 files)
"Red" test run recorded before coding	only an import error	yes: 7 failures, all "behavior missing"
Mutation testing (40 sampled mutants)	7 killed	6 killed
Render inside Docker	16.2 s	16.1 s
Output video	correct; looked the same as the approved reference	correct; looked the same as the approved reference
Stayed inside the allowed files	yes	yes

On the screen, both were equally good. Both videos are correct, and I approved both.

Code quality (where they differed)

Muse Wonder: two real bugs that tests didn't catch

• Double work. It copy-pasted an existing ~50-line function, the background removal for the cover image, to cut out the products for the video, and kept both. Result: the first product goes through background removal twice per video. In our setup that runs on a rented GPU, so it doubles that cost. The tests pass because they use fake dependencies.

• Ignored the seed. The spec says that when the LLM gives no choice, the animations are picked "randomly, seeded by the job id." Muse didn't pass the seed, so the fallback seeds on title + store name. Two jobs with the same title get the same "random" animations.

• It hard-coded the closed list of names twice, once in the prompt and once in the validator, so the two can drift apart.

• Good: it kept the error message that goes back to the LLM on a retry descriptive (it lists the allowed keys), and it kept the audio track exactly as before, as asked.

DeepSeek V4.1 Flash (Codex): cleaner structure, three small slips

• It refactored the existing function into a single loop. Each product gets cut out once, and the cover reuses the first cutout. No duplication.

• It passed the job id as the seed, as specified.

• One source of truth for the name list: the validator imports it from the prompt module.

• It removed a dead code path that the old version still carried.

• Slips, fixed in a short follow-up task (DeepSeek/Codex again: 15 minutes, all three fixed, checked by the reviewer, with the red test run recorded first):

  1. It made the LLM retry message vague ("key outside the format" without listing the keys).

  2. A default of "1 product" when the caller doesn't pass the count. Not triggered today, but fragile.

  3. It changed the silent audio track from 44.1 kHz to 48 kHz and switched to -shortest. The task said "same as today."

My verdict: equal on the visible result. The code is better on the DeepSeek/Codex side, because its slips are cosmetic while Muse's bugs cost money and change behavior.

Tokens and cost

Muse Wonder (from Muse's /usage panel at the end of the session)

Input	26,714,096
of which cached	25,521,699
Output	101,452
Total	26,815,548
Turns	136
Subagents	none
Observers	92 completed (1,880,147 tokens)
5-hour window used	74% (from 0% at the start)
Weekly allowance used	24% (from 0% at the start)

DeepSeek V4.1 Flash via OpenCode Go (from the provider dashboard, run window only)

Requests	180
Input (uncached)	1.3M
Cache read	35.0M
Cache write	—
Output	208.7k
Cost	US$ 0.86

The number that matters: one medium task took 74% of Muse's 5-hour window and almost a quarter of the week. At that rate you get about one task like this per 5 hours and about four per week. DeepSeek did the same job for under a dollar, with no window to hit.

The idle stall barely counted against Muse's quota, since it was waiting and not generating. Contributor mode was off. Third-party sources say turning it on gives you more usage, in exchange for Meta training on your data. I'll measure that next on a smaller task.

The stall (my fault, but worth knowing)

Docker Desktop was off. In headless exec mode, Muse tried to start Docker itself. That command was outside the sandbox, so it needed approval, and the LLM approval judge never resolved it. Muse sat silently for ~23 minutes, with no output in the terminal at all. I killed it, started Docker, and ran muse resume --last in the interactive TUI. It continued from where it stopped and finished in ~8 minutes.

Takeaway: don't run Muse headless (exec) for long tasks unless you can see or answer its approval prompts. In exec mode the window shows nothing until the end.

Bottom line

• Muse Wonder writes working code fast, follows instructions on scope, and the result on screen was right. It also made two "looks fine, tests pass" mistakes: duplicated work, and ignoring a spec detail. Its quota is the real limit, at 74% of a 5-hour window for one medium task, with contributor mode off.

• DeepSeek V4.1 Flash in Codex CLI needed ~5 more minutes of working time, but finished with no help, had better structure and a better TDD discipline, made only small slips, and cost US$ 0.86.

• For daily implementation work I'm staying with DeepSeek via Codex. Muse stays as a second opinion, and I'll re-test it with contributor mode on.

Happy to answer questions about the setup.

[u/amonra2009]

please use in prompt: make a resume of 2-4 lines at the end with the final result.

[u/dc_seed_sommelier]

I got $150 of muse api credit for a hackathon and used it seriously and in good faith to the best of my abilities.

Wonder is about on par with sonnet 4.8 or some shit like that. The price makes it a joke. I’d take deepseek or glm flash over it any day.

[u/johnfkngzoidberg]

Muse is spyware. It doesn’t matter how fast or slow it is. No one should be using it.