Muse Spark 1.3 vs Claude Opus 5

Note: This comparison reflects my personal opinion and does not represent the views of any organization, including my employer.

Muse Spark 1.3 recently launched with benchmarks suggesting it can compete head-to-head with Claude Opus 5.

But how do they perform on real software projects, rather than benchmarks and toy examples?

I decided to find out.

This isn’t a comprehensive benchmark. It’s a qualitative comparison based on the kind of work I actually do when building products.

The Playground

I run an AI trading platform, wallstreetclaws.com, with multiple microservices and 30K+ lines of TypeScript and Python. There’s also a long backlog of features I want to build, making it a useful playground for testing coding agents.

The task:

We’re adding support for quant strategies—allowing users to define trading signals using combinations of sliding-window indicators (SMA, RSI, etc.) and equity fundamentals, along with position sizing, entry/exit rules and risk management.

For this test, the models had to:

Capture traces of strategy execution and visualize them in the backtest UI, making it easy for users to understand why each trade happened.

I used Claude Code for Opus and OpenCode for Muse Spark 1.3.

1. Codebase Navigation

Tie.

Both models did an excellent job understanding the codebase.

They identified the relevant files, found the tests, understood the microservice architecture, and figured out how to run the system end-to-end.

2. Testing & Verification

Claude wins.

Muse Spark figured out how to run the unit tests and an E2E smoke test. The smoke test involved generating fake data, starting multiple services, and verifying the flow end-to-end. It also added some useful unit tests.

Claude did all of that—and then went further.

It launched the entire application in a headless browser, took screenshots, inspected the UI, and iterated to fix visual issues.

That was a meaningful difference.

3. Correctness

Tie, with slightly different approaches.

Both produced technically correct implementations that satisfied the prompt.

Muse Spark relied heavily on typechecking and tests to catch and fix issues.

Claude generated code that was correct on the first attempt. The tests and typechecks passed without requiring iteration.

4. Cost

Muse Spark wins by a mile.

Muse Spark is currently free on OpenCode.

Claude consumed roughly 30% of my Claude Pro session limit for this task.

5. Speed

Muse Spark wins.

Muse Spark: ~15 minutes

Claude: ~26 minutes

Muse Spark also feels faster because it continuously shows what it’s doing.

Claude spends noticeably more time “thinking.”

That said, there’s an important caveat: Claude’s verification process was substantially more thorough, particularly because it used a headless browser to actually inspect the resulting UI.

6. Quality of the Final Artifact

Claude wins. And this is where things get interesting.

Muse Spark completed the task successfully.

Its implementation was perfectly reasonable. You couldn’t really fault it for failing to follow the specification.

But Claude’s output felt different.

It felt like Claude understood the user’s intent holistically, rather than simply implementing the requirements.

The resulting UI was something I would actually want to ship—and in some ways, it exceeded what I had explicitly asked for.

Muse Spark:

Claude:

Verdict

My takeaway:

Claude has better product sense.

It seems better at contextualizing the user’s intent beyond the literal specification—UX, information hierarchy, visual design, and what the final product should feel like.

So I’d lean toward Claude when building new product features where taste matters.

Muse Spark, on the other hand, is incredibly compelling as a fast, cheap workhorse.

I’d reach for it when the output can be deterministically verified:

• Refactors
• Bug fixes
• Well-defined libraries
• Mechanical code changes
• Tasks with a clear specification and strong automated tests

In other words:

Claude for judgment. Muse Spark for throughput.

A Point to Ponder

Software engineering isn’t just about correctness and raw coding ability.

It’s also about taste, human preference, UX, and product sense.

Benchmarks are reasonably good at measuring things like coding ability and correctness.

But how do you benchmark whether a model has good product taste?

How do you measure whether an implementation is something a user would love, rather than something that merely satisfies a specification?

That’s a much harder problem.

And I suspect that as coding agents get better at writing technically correct code, product sense may become one of the biggest differentiators between models.

I’d be very interested to see how frontier labs tackle this. Optimizing for benchmarks versus optimizing models for the messy, subjective reality of building real products.