[Feature]: Muse Code

[LouisDeconinck]

Before submitting

• I searched existing issues and did not find a duplicate.
• I am describing a concrete problem or use case, not just a vague idea.

Area

packages/contracts or packages/shared

Problem or use case

Meta has released Muse Code, their own AI agent coding terminal harness alongside their newest Muse Spark 1.2 model. Currently T3 Code does not support Muse Code as a coding harness.

Proposed solution

Add Muse Code as a supported option for T3 Code.

Why this matters

If you pick the Muse Spark 1.2 contributor option where they can train on your data, this is the best value model available.

Smallest useful scope

Muse Code as a coding agent.

Alternatives considered

No response

Risks or tradeoffs

No response

Examples or references

https://developer.meta.com/ai/products/muse-code/

Contribution

• I would be open to helping implement this.

[LouisDeconinck]

Any plans to implement Muse Code now that Muse Spark 1.3 is SOTA and practically free?

[fionn77]

not saying it shouldn't be added but currently you can also use it for free though OpenCode which already is implemented in t3 code

[LouisDeconinck]

That's how I'm currently using it, but the Must models are optimized for the Muse agent.

[quantmind-br]

I built a full Muse Code provider for T3 Code. The work is on my fork: quantmind-br/t3code → branch feat/muse-provider.

Posting here before opening a PR, per the contribution guidelines. If you think adding the Muse Code provider makes sense, I’d be happy to open a PR.

How it works

T3 Code talks to Muse directly over MSP — the Muse Session Protocol — not ACP and not TUI scraping. I wrote a native Effect-based MSP client (packages/effect-msp, modeled on effect-codex-app-server) rather than wrapping the official @muse-code/sdk, for the same reasons the other providers use their own protocol clients here.

One muse serve host process per T3 thread, kept alive across turns. That is what keeps the provider's prompt cache warm — every turn is a turn/start against the same session, so context (and cache) persists instead of being rebuilt each message.

Muse Code plans

The main draw: it makes a Muse Code subscription usable in T3 Code. Meta's plans (Everyday Usage, High Usage, Power Usage) bill a flat monthly rate rather than per token, and per Meta's own docs a subscription "only works through the Muse Code CLI" — usage through any other API key you create is billed pay-as-you-go instead (subscriptions docs).

This integration drives the CLI's own server mode with the credential CLI onboarding installed, so a subscriber's plan quota is what the agent consumes. No per-token key is involved unless you want one, and because accounts are isolated (below), a work plan and a personal pay-as-you-go key can sit side by side.

What's in

Full turn lifecycle: start, steer, interrupt, cancel, unqueue

Streaming: item/delta mapped to assistant text, reasoning text, and command output

Approvals and user-input round-trips: (approval/requested → T3 approval UI → approval/decide)

Attachments: images as real MSP image input parts (base64 + media type, image-only turns valid); other files reach the model as on-disk path lines

Subagents / workflows: delegated work projected onto the task lifecycle, so it lands in the Agents surface with agent identity, role, phases, and usage — workflow children as parented task rows

Rollback & resume: session/fork with cut point (semantically equivalent to T3's git checkpoints); resume cursor persisted through the generic rollback flow

Splice recovery: on view/gap, the adapter pages view/page through the durable range and replays each event through ordinary notification dispatch, with an exclusive upper bound, already-dispatched-cursor dedup, and content-suffix restoration for dropped reply text

Multi-account isolation: a new homePath setting drives XDG_CONFIG_HOME / XDG_DATA_HOME / MUSE_AUTH_PATH across all spawn points (adapter host, health probe, one-shot text generation), so separate Muse accounts get genuinely separate credential and session stores

Settings form, provider icon / driver metadata, and MuseTextGeneration for one-shot completion calls

Testing

Real-binary tests, not in-memory fakes: the MSP client is tested against a real child process (client.process.test.ts), and the adapter suite (MuseAdapter.test.ts, 12 tests) runs a scriptable mock muse serve host over real stdio — including the handshake, gap recovery, and account isolation. The targeted suite is green: 1,411 server tests, 5 effect-msp tests, typecheck clean across all four touched packages.

Known limitations (intentional, not TODOs)

readThread serves from the in-memory item cache (seeded from resume history), not a full re-read from the host

MSP v1 has no subagent/* notifications — subagent work is only observable as transcript items, so that is all the projection can see

reasoning.summary arrays are deliberately not content-reconciled (per-index field paths can't be placed by a character counter; reasoning is never the model's answer)

A usage-only revision after a task is closed is dropped rather than routed through a lifecycle event that didn't happen

No separate login flow is implemented: auth is whatever an already-installed muse CLI wrote during onboarding, which is also the surface a plan lives on

Open to feedback on the approach before I turn this into a PR — especially anything that would make it hard to maintain alongside the other provider adapters. If the maintainers feel this is a good fit for T3 Code, let me know and I'll gladly open the pull request!

[bhagyamudgal]

would love to have this

[cristianuibar]

I’ve opened #11258 with beta Muse Code support using Meta’s official SDK, including screenshots, a setup video, and verification results. It references the native Effect MSP implementation already proposed here. Feedback on which approach best fits T3’s direction would be welcome.