Muse Spark 1.3 in Claude Code: the best harness is not the one you already know

Meta’s model is available through its own coding agent and API. The practical question is which harness gives you the best combination of model fidelity, tool reliability, safety, and observability.

Meta has created a naming trap that matters to anyone trying to use its newest model. Muse Spark 1.3 is the model. Muse Code is Meta’s terminal coding agent. The command installed on your machine is muse, which is why people casually call the product “Muse CLI.”

The decision is clearer than the social feed suggests:

• Use Muse Code when you want the closest thing to Meta’s intended model-and-harness pairing.
• Use OpenCode as the practical default for Muse Spark 1.3 if you want a familiar, portable agent that can call Meta’s documented OpenAI-compatible API directly.
• Use Claude Code only as a conditional adapter. Meta claims compatibility, but an authenticated 1.3 session using Claude Code’s Messages route still needs to be verified feature by feature.
• Use Harbor around any of them when the goal is a repeatable benchmark, CI gate, or regression suite.

That is the important distinction between a model launch and a usable coding system: the harness owns the tool loop, permissions, context compaction, retries, approvals, and the record of what actually happened.

Three takeaways

1. “Muse CLI” is shorthand, not a separate open-source Meta project. Meta calls the product Muse Code and distributes the muse host through an installer. The public open-source surface is a separate SDK and cookbook.
2. OpenCode is the cleanest first experiment with 1.3. It can point directly at Meta’s OpenAI-compatible API, avoiding an Anthropic-to-OpenAI translation layer.
3. YouTube and X show adoption, not proof. They show Muse Spark 1.3 appearing in OpenCode, OpenRouter, Cursor and other routes. I found no reproducible public evidence of 1.3 running inside Claude Code with the full model, tool and usage path verified.

What Meta actually built

Meta’s August launch describes Muse Code as a terminal coding agent for planning, writing and validating work across large repositories. The product is more than a prompt box: Meta says Muse Spark 1.2 was co-trained with the Muse Code harness using successful harness trajectories, optimizations for goals and context compaction, subagent recipes, and the Muse Code toolset. (Meta’s Muse Code launch)

The 1.3 release adds an important qualification. Meta says Muse Spark 1.3 was trained across a diverse set of harnesses, and says it is better at long-horizon work, tool use, clarification, recovering from gaps, and confirming consequential actions. (Meta’s Muse Spark 1.3 announcement)

Those statements fit together. Muse Code is the highest-fidelity reference implementation for Meta’s own recipes, but Muse Spark 1.3 is not officially described as locked to that one runtime. The model’s observed behavior depends on the agent around it: the system prompt, tool definitions, context window management, approval policy, filesystem, shell, browser, retries, and whether subagents share or isolate state.

This is why a Muse Code benchmark and a Claude Code benchmark are not model-only results. They are measurements of two systems.

How to access Muse Spark 1.3 now

Route 1: Muse Code, the native harness

Meta’s 1.3 announcement says the model is rolling out in Muse Code and the Meta Model API. For macOS and Linux, Meta publishes this installation command:

curl -fsSL https://dev.meta.ai/install.sh | bash

The command is official, but the security decision is still yours: inspect a remote installer before running it on a development machine that has repository credentials. The installer source shows that the muse launcher is placed under ~/.local/bin/muse by default and uses an account/device flow. The accessible launch materials do not expose a stable, documented public login command, so avoid treating third-party muse login instructions as canonical. (official installer)

Route 2: Meta Model API

Meta’s public cookbook gives the most concrete 1.3 API path. Create a Model API account and key at dev.meta.ai, keep the key in MODEL_API_KEY, point an OpenAI-compatible client at https://api.meta.ai/v1, and use the wire model ID muse-spark-1.3. The cookbook lists a 1,048,576-token context window. (Meta Model API cookbook)

export MODEL_API_KEY="LLM|your-key"

The key shape and endpoint are documented examples, not a reason to commit secrets or copy a key into a project file. The API surface is changing quickly; verify the model returned by the endpoint and pin the cookbook commit or your own configuration when you begin an evaluation.

Route 3: OpenCode, OpenRouter and other providers

Meta’s developer overview points users to OpenRouter as another route, and OpenCode has publicly announced 1.3 availability. These options reduce setup friction, but they add a provider layer between your agent and Meta. That can change effective pricing, limits, availability, tool behavior, data handling, and usage visibility. Record the provider and exact model slug in every result; meta/muse-spark-1.3 is a provider-specific identifier, not the Meta wire ID.

The Contributor tier deserves its own warning. The current launch-day rate card lists standard Muse Spark 1.3 at $1.25 per million fresh input tokens and $4.25 per million output tokens. Contributor is listed at $0.10 and $0.20, but Meta may use Contributor prompts and completions for training. The discount is a data-policy choice, not merely a cheaper API key. Recheck the live terms before sending proprietary code. (Meta pricing and rate limits)

For an India-based team, treat access as a live account check. Meta previously described expanded global access for Muse Spark 1.2, but the 1.3 announcement does not publish a country allowlist. USD prices also exclude GST, foreign-exchange fees and any intermediary markup.

Can you use Muse Spark 1.3 in Claude Code?

Meta’s cookbook says its Model API is compatible with the Anthropic SDK and agent CLIs including Claude Code. That is a useful official signal, but it does not make every endpoint interchangeable.

Claude Code’s own gateway documentation says a custom gateway must expose a supported API format. Claude Code’s Anthropic path expects the Messages protocol at:

POST <ANTHROPIC_BASE_URL>/v1/messages

That is a different wire contract from Meta’s documented OpenAI examples at https://api.meta.ai/v1. Anthropic also says it does not support routing Claude Code to non-Claude models through a gateway. (Claude Code gateway docs, gateway protocol)

The safe conclusion is vendor-claimed compatibility, not a verified 1.3 Claude Code run. A technical check found the Meta Messages route responds as an unauthenticated endpoint, but that does not prove access for every account or confirm tool-call, streaming, MCP, reasoning and usage compatibility.

If you already use Claude Code, this is the configuration shape to test—not a guarantee that Meta has enabled every feature for your account:

export MODEL_API_KEY="LLM|your-key"
export ANTHROPIC_BASE_URL="https://api.meta.ai"
export ANTHROPIC_AUTH_TOKEN="$MODEL_API_KEY"
export ANTHROPIC_MODEL="muse-spark-1.3"
export ANTHROPIC_DEFAULT_OPUS_MODEL="$ANTHROPIC_MODEL"
export ANTHROPIC_DEFAULT_SONNET_MODEL="$ANTHROPIC_MODEL"
export ANTHROPIC_DEFAULT_HAIKU_MODEL="$ANTHROPIC_MODEL"
export CLAUDE_CODE_SUBAGENT_MODEL="$ANTHROPIC_MODEL"

Pinning every slot matters. If a background agent keeps a Claude default, a session can look like a Muse run while a subtask silently uses a different model. Start with a read-only smoke test; verify the model name, one streamed response, one harmless tool call, and usage fields before allowing edits or production credentials.

If direct Messages compatibility fails, a translation proxy can convert Claude Code requests to Meta’s OpenAI-compatible endpoint. That may be useful for an experiment, but it creates a new failure boundary. A proxy can drop tool-search references, reasoning metadata, prompt-cache semantics or exact cost data. It also makes the proxy—not Claude Code—the place where policy and billing must be audited.

Harness comparison

The model layer is shared; the harness changes the protocol adapter, tool policy, isolation and evidence trail. Original EyesTech diagram.

My recommendation is therefore two-layered:

For everyday experimentation, use OpenCode directly against Meta’s API. It gives Muse Spark 1.3 a clean protocol path and makes it easy to compare a second model in the same agent. Use a container or disposable worktree because an OpenAI-compatible provider does not itself sandbox shell commands.

For the native Meta baseline, run Muse Code separately. If the model behaves better there, that is evidence about the full Meta system—not proof that another harness is “wrong.” The public Muse Code SDK is worth watching if you need to programmatically control sessions, but it is a developer preview and does not include the host binary.

For comparisons, wrap both in Harbor. Harbor’s isolated environments and verifiers let you measure completed work rather than screenshots of a successful demo. The right unit is a task result with a model ID, harness version, tool trace, timing, cost, retries and cleanup burden.

What YouTube and X actually prove

The social evidence is useful, but only if it is read as an access map rather than a benchmark.

YouTube now has some useful 1.3 field evidence. Agent Workflow Lab’s three-game video visibly names meta/muse-spark-1.3-contributor, OpenRouter and Hermes Agent CLI v0.21.0. It shows QA, human playtesting, repairs and failures, and identifies an upstream commit, but it does not publish the repository or raw run log. Matt Johnston’s test shows Muse Code and Spark 1.3/Ultra working through browser, C++, FPS, watch-site and CAD tasks, including failures and reported costs. It also lacks a public trace.

Those are stronger than a launch trailer, but they remain anecdotes. Mehul Mohan’s video shows the Muse Code model picker and parallel tabs, then blends the final result with later Fable edits. AICodeKing’s April “Muse Spark + Claude Code” predates 1.3, and a freeCodeCamp course published on 26 August, “Meta Muse Code & Muse Spark Course”, also predates the 2 September release. None of these videos is proof of a current 1.3 run inside Claude Code.

X shows a stronger availability pattern. OpenCode announced 1.3, OpenRouter announced availability, and Mark Zuckerberg announced the Meta rollout. Artificial Analysis posted a comparison where Muse was evaluated in Muse Code and Claude in Claude Code (post). That is a cross-harness comparison, not Muse Spark running inside Claude Code.

I also found an independent Cursor/OpenCode video report and a low-detail comment that the Muse CLI still needs work. Neither supplies the artifacts needed to establish a production recommendation. The social feed says “people are trying this.” It does not yet say “Claude Code is a verified 1.3 harness.”

The five-task test to run before you choose

Do not decide on a coding harness from one website demo. Create a harmless test repository and run the same five tasks through Muse Code, OpenCode, and Claude Code only after the Claude smoke test passes:

1. one bug fix with a regression test;
2. one multi-file feature;
3. one failing test that needs diagnosis;
4. one browser/UI change checked by a real verifier; and
5. one documentation change with a strict format.

Pin the model ID, reasoning level, harness version, system prompt, tool schema, context setting, provider route, region and network conditions. Record pass/fail, verifier output, wall-clock time, time to first token, input/output/cached/reasoning tokens, tool-call count, retries, refusals, human interventions and cleanup edits.

If the endpoint returns a different model, a subagent uses a different slot, or a proxy hides usage, stop the comparison. A “free Muse” result that silently falls back to a paid model is not a bargain; it is an invalid experiment.

What this changes

Muse Spark 1.3 is a model release, but Meta’s own story is a harness story too. Muse Code is the reference pairing; OpenCode is the best low-friction route for a clean API experiment; Claude Code is a compatibility project until the Messages path is proven; Harbor is the right place to turn those choices into evidence.

The first question should not be “which CLI looks most like Claude?” It should be: which system lets me attribute a completed code change to the exact model, tool loop, permissions, and cost that produced it?

Who should care

• Solo builders: start with OpenCode or Muse Code on a disposable branch; avoid Contributor for private repositories unless its training terms are acceptable.
• Claude Code users: test the direct Messages route only in an isolated repository and pin every model slot. Keep a known-good Claude configuration separate.
• Engineering teams: use standard Meta pricing for proprietary work unless legal and security owners approve the Contributor data-use terms; centralize usage and provider logs.
• Evaluation teams: use Harbor or an equivalent containerized runner, and publish the harness alongside the model result.

Limitations and update note

EyesTech did not run an authenticated Muse Spark 1.3 API session in this analysis. Meta’s co-training, availability, efficiency and compatibility statements are official claims. The YouTube and X examples are public anecdotes or platform announcements. The direct Claude Code route, MCP behavior, rate limits, pricing, regional access and provider availability require same-day rechecks because this is a fresh public-preview rollout.

Updated 3 September 2026. Confidence is high on the product/model naming and Meta’s published access routes; medium on the recommended harness ordering; and exploratory on direct Claude Code feature parity.

Get the EyesTech Signal: the next update should publish matched-harness task results with the model, tools, cost and cleanup visible.

Suggested internal links

• Muse Spark 1.3 benchmarks and pricing analysis
• Claude Fable 5.1 benchmarks and pricing
• DeepSeek V4 vs Kimi K2.6