Muse Code's Session Bus: Inter-Session Messaging as the Operator Primitive

Muse Code came out of beta on September 1, and the consequential change is not a new model. It is inter-session messaging on the same machine, so one live session can hand a warning or resolved question to another without the operator retyping it. This article uses “session bus” as shorthand; Meta calls the feature inter-session messaging.

The news summarizes fast. Meta’s developer post says Muse Code is out of beta with sessions that message each other, workflows for subagent teams, rewind, a developer-preview SDK, and monthly plans. The underlying model remains Muse Spark 1.2. A local CLI check during this review used Muse Code 1.0.1 and confirmed the session-message, export, serve, and schema command surfaces.

The beta review — engine, benchmarks, and the known-versus-unknown ledger — already lives in the Muse Code review. This piece stays on the new primitive and what it does to visibility across a mixed fleet, stall and attention signals, usage, and durable records.

The news first, and what didn’t change

Same engine. That is the most clarifying fact in the announcement. Muse Spark 1.2 carried the beta and it carries the release, which makes this a harness release rather than a model release. The new competitive surface is coordination: the sessions learned to talk.

The locality claim needs a boundary. Meta says inter-session messages stay on the same machine, and the current CLI exposes a local session-message service. That describes the coordination hop; it does not imply that model inference is local or that no other session data reaches Meta’s services.

And pricing finally exists. Everyday Usage is $5 per month and typically includes 10–50 requests per five-hour window. High Usage is $15 for three times the Everyday allowance; Power Usage is $50 for ten times the Everyday allowance. “Requests” still varies with task complexity, so the range is planning guidance, not a guaranteed count.

What the release did not establish is equally important: same-machine messaging is not evidence of fully local inference, and an out-of-beta label does not answer every data-handling question. Treat coordination locality and model/data locality as separate rows in a review.

The multi-agent workflows feature reads, so far, as orchestration sugar on top of the bus: named sessions, roles, a way to stand up several at once. The bus is the load-bearing part. Get the primitive clear and the workflow layer explains itself.

A reproducible two-session drill

Use a low-risk drill before wiring messaging into production work. Open two Muse sessions in a disposable repository. Give the first a planning question; tell the second not to edit until it receives a decision. In another shell, inspect the peers and address the receiver by the UUID returned by the CLI:

muse session-message list --json
muse session-message send --target <session-uuid>

The exact message should carry the decision, its constraints, and a verification target. A handoff such as “rotate refresh tokens” is incomplete; “rotate, revoke the family on reuse, preserve the /token contract, and run the auth tests” is actionable. The feature removes manual copy/paste, not the need for a good brief.

One discipline note before anyone romanticizes it. The handoff is only as good as the message, and the message is only as good as the brief the planner got. “Send the decision plus the constraints that produced it” turns out to be the same craft as writing a good subagent brief — the fan-out patterns piece applies almost unchanged, just sideways between peers instead of downward into workers.

For the first run, stop at one handoff. Record the sender, receiver, message body, receipt, resulting edit, and test result. Only then add a reviewer or Workflow fan-out. A convenient primitive that multiplies sessions is also a convenient way to multiply invisible dependencies.

Define acceptance before the send. The receiver should know which artifact it owns, which files or systems are out of scope, what evidence will establish completion, and where to report a blocked dependency. The sender should remain responsible for resolving ambiguity in its decision rather than forcing the receiver to infer intent from a short message. Afterward, compare the message with the resulting diff and exported records. If a reviewer cannot reconstruct why the handoff occurred and how its constraints affected the work, the workflow added coordination without adding accountability. That comparison gives the operator a concrete reason to keep, revise, or reject the workflow shape before scaling it.

Visibility: a pending message is a dependency nothing draws

Consider the first failure mode before it happens. A builder waits for a decision, while the planner has stopped at a permission prompt behind another terminal. The builder is not stalled by its own definition; it is waiting correctly for a message that may never arrive. Both sessions can look healthy while the workflow is dead.

That is the visibility bill for inter-session messaging. One stalled sender can block every receiver waiting downstream, while those receivers look patient rather than broken. Meta’s launch post establishes the message primitive; it does not promise a complete dependency graph for every outstanding handoff.

The mitigation can live partly outside the harness. Stall flags can identify a sender that stopped producing output, even if they do not understand the semantic dependency. The workflow itself should also carry deadlines and explicit failure messages so a receiver does not wait forever.

The bigger point is structural. Every harness is growing coordination features this year, and each one deepens the case for a companion layer under the harnesses — something whose job is the operator’s whole picture while each vendor draws only its own corner. The session bus doesn’t change that argument. It arms it.

Token burn: inter-session messaging replays context

A bus message is not free, and the reason is mechanical: the message lands in the receiver’s context as a new turn, and the receiver then reads whatever it needs to act. A builder does not inherit the planner’s prior file reads; it receives the conclusion, then may read overlapping files to implement it. The bus moves conclusions between sessions. It does not merge their contexts.

There is no honest universal multiplier. A planner and builder may duplicate file reads; three builders may share little or overlap almost completely. The only safe rule is directional: every active session has its own context, so cost grows with the number of workers, their lifetime, and duplicated input. A chatty pair can cost more than a single compact handoff because each round trip becomes fresh context on both ends.

The $5 tier is not mysterious: Meta describes 10–50 requests per five hours, with the actual count depending on complexity. But a request range does not reveal duplicated reading or the cost of a workflow shape. Automater currently recognizes Muse as a CLI lane, while its companion source deliberately exposes no Muse quota probe. Compare account-reported usage with completed outcomes, exported records, and elapsed time; do not invent a cross-provider token number the product cannot observe.

Evaluate the workflow shape before scaling the session count. Use comparable task classes and record how many sessions were active, which messages crossed between them, which files each receiver had to read again, which waits required operator attention, and which verified artifact the group produced. Account or provider usage remains the authority for metering; the local record explains where coordination duplicated work or removed manual handoffs. A bus is useful when the separation of roles improves the result or keeps independent work moving. It is overhead when sessions repeatedly exchange partial context, reread the same inputs, or wait on decisions that one session could have made directly.

Keep quality in the comparison. Fewer requests do not establish a better workflow if the receiving session missed a constraint or produced an artifact that failed its required check. More requests do not establish waste when independent review catches an error. Report the task boundary, evidence collected, and unsupported measurements beside any conclusion. That method turns a pricing allowance into an operator decision without pretending that request count, token exposure, wall time, and output quality are interchangeable units.

The archive question: is session bus traffic transcript?

The current CLI answers part of the archive question. muse export writes a session’s durable log as JSON, including timestamps, messages, tool calls and results, approvals, model IDs, and fork/subagent lineage. It reads local files offline and offers a --redacted share-safe variant. That is a much stronger export story than the beta had.

Bus traffic belongs in the durable record. A planner-to-builder message can contain the decision, constraints, and reason a diff has its final shape. If peer messages persist in exported logs, the work remains searchable. If they exist only in flight, the archive has holes at the joints where one session’s work became another’s.

One boundary remains unverified here: the public launch material and command help do not prove whether both the sent and received copies of a peer message appear in each exported durable log. The day-one operator test writes itself: send a unique marker, export both sessions, and search both JSON files for that marker.

muse export --session <planner-uuid> --out planner.json --redacted
muse export --session <builder-uuid> --out builder.json --redacted
rg 'BUS-CHECK-2026-09-01' planner.json builder.json

Why insist on it: replaying a fleet without the messages between sessions is a play with the dialogue removed. Export support makes external archiving possible, but it does not automatically mean every archive product already ingests Muse’s durable-log schema. Treat the exporter as the source artifact, and verify any downstream importer before relying on search or replay.

The protocol is not the bus

Two adjacent features are easy to blur. Inter-session messaging lets live Muse sessions exchange messages. The Muse Code SDK is a TypeScript library for driving Muse Code agent sessions over the Muse Session Protocol (MSP). MSP is the host/client wire contract; it is not merely a marketing name for peer messaging.

That distinction matters to integrators. The SDK repository labels itself pre-1.0 and gives no stability promise for minor releases. An operating layer can integrate with MSP, but it must pin and test the schema fingerprint rather than assuming today’s method set is permanent. Automater Desktop’s current source has an MSP adapter and schema-fingerprint checks; that is beta integration work, not a promise that every future Muse preview will be compatible. Automater Lite is free on automater.ai; Pro is $29/year.

A final verification aid ships in the CLI itself: muse schema generate-json-schema and muse schema generate-ts export the MSP schema embedded in the installed binary. That lets an integration test the exact host it will drive rather than copying types from a blog post.

FAQ: the Muse Code session bus

What is the Muse Code session bus?

The session bus is Muse Code’s inter-session messaging layer, shipped when the product left beta on September 1, 2026. Sessions on the same machine pass messages over a local socket, so one session can hand a resolved decision or task to another without the operator copying anything between panes.

What is the Muse Session Protocol?

Muse Session Protocol is the wire protocol used by the developer-preview TypeScript SDK to drive Muse Code agent sessions. It is adjacent to inter-session messaging, not synonymous with it. Preview status means minor releases can change APIs, so pin versions and validate the embedded schema.

How much does Muse Code cost after beta?

Monthly plans start at $5. Meta says Everyday Usage typically provides 10–50 requests every five hours; High Usage is $15 for three times that usage, and Power Usage is $50 for ten times it. The range varies with workload complexity. The engine remains Muse Spark 1.2.

Sources

• Muse Code: new plans and features — Meta developer blog
• Meta for Developers — news index — current out-of-beta listing
• Muse Code SDK — TypeScript SDK, MSP scope, schema, and developer-preview stability warning
• Muse Code SDK documentation — protocol and SDK reference
• Neowin — Meta graduates Muse Code out of beta — launch details and current subscription table cross-check