One API, every harness: the Model API ecosystem play
Meta shipped its coding model everywhere developers already are — the OpenAI SDK, the Anthropic SDK, rival agent CLIs, even OpenRouter. Compatibility-first is the distribution strategy.
Three values, and you’re in
Connecting almost any tool to Muse Spark takes the same three values: base URL https://api.meta.ai/v1, your MODEL_API_KEY, and a model ID like muse-spark-1.2. That works because the API speaks the formats the ecosystem standardized on: OpenAI-style chat completions and responses, plus an Anthropic-format Messages endpoint for harnesses built that way. Keep your SDK, keep your code, change one URL.
Even the competitors’ harnesses
The compatibility list is pointed: OpenCode, LangChain, LlamaIndex, the Vercel AI SDK, Continue — and Claude Code, Anthropic’s own agent, which plugs in via the Messages API. Meta will happily serve tokens inside a rival’s harness. Some agents skip configuration entirely: self-configuring CLIs like OpenCode, Goose, and Roo accept a pasted provider description — base URL, model ID, context window, supported features — and wire themselves up.
The strategic read isn’t subtle. Every existing coding tool becomes a distribution channel for Muse Spark tokens, with zero switching cost as the pitch. And distribution extends beyond Meta’s own door: Muse Spark 1.2 is also available through OpenRouter, meeting developers who aggregate providers where they already shop.
So why does Muse Code exist?
If any harness can run the model, why build one? Because compatibility gets you function, not fit. Muse Spark 1.2 was co-trained with Muse Code specifically — its training included the harness’s toolset, its subagent choreography, its goal and compaction recipes. A generic wrapper gets a very good model; Muse Code gets a model that has already rehearsed the exact plays its runtime calls — persistent background agents, worktree fan-out, the event log. The open API is the wide funnel; the native agent is the deep end.
A pragmatic adoption path
The two-layer strategy suggests its own migration plan. Day one: point your current setup — whatever it is — at the Model API and evaluate the model on your real work, risking nothing. If the model earns its place, try Muse Code for the workflows where harness fit compounds: long-horizon tasks, parallel multi-part jobs, work you’ll want to audit later. The cookbook covers both layers, and the tier guide covers what the tokens cost once you commit.