Meta says Muse Code records every model call, tool run, approval, and edit in a local append-only event log. That log is the runtime's single source of truth, making it replay-exact and restart-safe so an agent can resume precisely where it stopped after a crash.
This is the right layer to improve. Long-running AI coding agents are constrained less by the next model response than by durable state, recovery, observability, and safe interaction with the external world. But an event log can reconstruct only what it completely records. It does not, by itself, guarantee that an email, pull request, cloud resource, or payment happens exactly once.
This article uses “Muse Code runtime” as an analytical description. Meta's formal product names are Muse Code (beta) and Muse Spark 1.2; “Runtime Design” is a section in the launch post.
What Meta actually published
Meta released Muse Code and Muse Spark 1.2 on August 5, 2026. Muse Code is a terminal coding agent paired with the Muse Spark 1.2 model.
The launch post describes three runtime ideas that matter for long tasks.
First, Muse Code uses a simple main-agent loop plus asynchronous background agents. The specialized agents remain active throughout a session, carry out next steps, and decide when to report back. The wording is important: Meta claims persistence within each session. It does not say those workers survive process restarts, host failures, or session boundaries.
Second, the local event log appends model calls, tool runs, approvals, and edits. Meta calls it a single source of truth and says it makes the runtime replay-exact and restart-safe.
Third, Muse Spark 1.2 was co-trained with the Muse Code harness. Training included goals, context compaction, subagents, and the toolset. Meta also reports a GPU-kernel optimization case with more than 1,000 tool calls over as long as 24 hours. That shows the system can be used for long runs. It does not independently test crash recovery.
The evidence gap in Meta's methodology
The three-page Muse Spark 1.2 and Muse Code Evaluation Methodology covers task-quality benchmarks:
- Terminal-Bench 2.1: 89 tasks, five attempts, average pass@1.
- DeepSWE 1.1: 113 tasks across 91 repositories, five attempts, fresh-container verification.
- GDPVal-AA v2: 220 professional tasks in a third-party harness.
- MCP Atlas: 1,000 tasks across 36 MCP servers and 220 tools.
- Meta Internal Coding Bench: 440 internal tasks with two attempts each.
The report does not describe tests for replay, crashes, restarts, background-agent recovery, context compaction, approvals, event-log corruption, idempotency, or external side effects. It also warns that coding-agent comparisons use different product harnesses and are not harness-identical.
The defensible wording is therefore precise: Meta claims Muse Code is replay-exact and restart-safe. Its public evaluation report demonstrates task-completion methodology, not the runtime reliability claim.
Four different meanings of replay
“Exact replay” can refer to several contracts. They should not be collapsed.
| Replay layer | Required record | Example acceptance test |
|---|---|---|
| Conversation replay | Prompts, responses, approvals | Render the same visible transcript |
| Control-flow replay | Ordered commands and branch decisions | Reach the same workflow position without new decisions |
| Workspace replay | File versions, diffs, tool outputs, environment identity | Reconstruct the same repository state and hashes |
| External-effect replay | Durable operation intent and confirmed remote result | Resume without duplicating or losing a remote effect |
A local log can plausibly support the first two if it stores complete ordered events. Workspace replay additionally needs every indirect write, concurrent modification, environment dependency, and version change to be captured or frozen. External-effect replay requires cooperation from remote systems.
Microsoft's Event Sourcing pattern explains why append-only history is useful: replay can reconstruct internal state and preserve an audit trail. The same guidance also highlights ordering, event versions, schema evolution, snapshots, concurrency, compensating events, and idempotent consumers. Append-only storage is a foundation, not the complete contract.
The crash window that an event log cannot close alone
Consider a coding agent that creates a pull request through a remote API:
- The runtime records an intention to create the pull request.
- The remote service creates it successfully.
- The process crashes before the success event reaches durable storage.
- Recovery replays the workflow from the last confirmed local event.
- The runtime creates a second pull request.
From the local log's perspective, retrying is rational. From the remote system's perspective, the effect has already happened.
AWS's guidance on idempotent APIs addresses this ambiguity with a stable caller-provided request identifier. The server records the token and the mutation atomically, then returns the same business result when the request is retried. Where the remote API offers no such contract, the runtime needs reconciliation, an at-most-once policy, or a compensating action.
This is the exactly-once gap. A local event log can make internal decisions repeatable while external writes remain at-least-once, at-most-once, or unknown. Strong runtime documentation should state the delivery semantic per tool.
What a complete event envelope would need
Meta has not published Muse Code's event schema. A production-grade contract would normally expose or preserve at least:
event_id: monotonic-or-causally-ordered-id
session_id: stable-session-identity
agent_id: main-or-background-worker
event_type: model_call | tool_intent | tool_result | approval | edit
input_hash: exact-input-or-prompt-hash
environment: model-tool-cli-and-repository-versions
idempotency_key: stable-key-for-external-mutation
result_hash: local-output-or-remote-business-result
approval_scope: actor-parameters-state-hash-and-expiry
parent_event_id: causal-predecessor
committed_at: durable-commit-time
The field names are illustrative, not a claim about Muse Code's implementation. Their purpose is to show why “we log every tool run” remains underspecified. Safe replay depends on event order, atomic durability, causal linkage, versioning, and how unknown results are reconciled.
Persistent workers are not durable state
Muse Code's background agents remain alive throughout a session. This can reduce duplicate research and lower latency because workers preserve local context. It also creates concurrency questions.
Two workers may edit the same file from different snapshots. One may approve a plan while another changes the repository state that the approval assumed. A context-compaction summary may omit an unresolved constraint. A crash may restore the main loop but leave the background workers' exact state ambiguous.
The architecture therefore needs separate contracts for:
- worker liveness within a session;
- durable task state across process and host failures;
- workspace concurrency and conflict detection;
- approval binding to exact parameters and repository state;
- context compaction artifacts and their version history.
This separation extends the five-layer Agent sandbox state model. Process memory, local files, checkpoints, external storage, and external side effects have different owners and lifecycles. Calling all of them persistent hides the recovery boundary.
A failure-injection test suite for Muse Code
Meta's public claim can be converted into reproducible acceptance tests. These tests would be more informative than another aggregate coding benchmark.
| Failure point | Required recovery result | Evidence to retain |
|---|---|---|
| Before a model call is logged | Call may run once after restart | Event sequence and call count |
| After model response, before next command | Reuse stored response; avoid a new divergent response | Response hash and model version |
| During a local edit | Restore either pre-edit or complete post-edit state | Git diff and file checksums |
| After remote success, before result commit | Reconcile or safely retry without duplicate effect | Idempotency key and remote object ID |
| During context compaction | Resume from a committed old or new summary, never a torn summary | Summary hash and parent range |
| With two background workers editing | Detect conflict or serialize commits | Causal order and conflict record |
| After CLI or event-schema upgrade | Replay old history or fail with an explicit migration requirement | Compatibility test result |
| With a truncated or corrupted log tail | Detect damage and recover to the last valid commit | Checksum and recovery point |
The result should report recovery success rate, duplicate-effect rate, recovery point objective, recovery time, event-log growth, and unsupported failure classes. “Restart-safe” then becomes a versioned, falsifiable statement.
The security cost of a complete local log
Logging model calls, tool arguments, approvals, and edits can produce an unusually sensitive artifact. It may contain source code, repository paths, command output, secrets accidentally printed by tools, internal URLs, personal data, and approval identities.
OWASP's Logging Cheat Sheet recommends excluding or protecting access tokens, passwords, encryption keys, connection strings, source code, and commercially sensitive data. A Muse Code deployment therefore needs explicit answers about log location, file permissions, encryption, redaction, tamper detection, retention, export, deletion, and telemetry.
The event log is both a recovery mechanism and a high-value data asset. Reliability and confidentiality must be designed together.
A useful interpretation of Meta's design
Muse Code points toward the correct architecture: the harness, not only the model, owns long-task reliability. A local event log, session-persistent workers, approvals, validation, goals, and context compaction form a more serious runtime than a loop that repeatedly asks a model for the next command.
The next step is to publish the contract behind the adjectives. What is replayed? Which failures are covered? How are external effects deduplicated? Are approvals tied to immutable action parameters? Can old histories survive upgrades? How is the log protected?
Until those answers and failure-injection results are public, “replay-exact” should be read as a promising product claim with a clear verification path. That is still meaningful progress. It moves competition from model scores toward the infrastructure that determines whether an agent can work for 24 hours without turning one crash into two side effects.
FAQ
What is Meta Muse Code?
Muse Code is Meta's beta terminal coding agent powered by Muse Spark 1.2. It uses a main loop, asynchronous background agents, built-in skills, validation tools, and a local event log.
Does Muse Code survive crashes?
Meta says the runtime is restart-safe and can resume where it stopped. The public evaluation methodology does not include a dedicated crash-recovery test, so the exact failure coverage remains undocumented.
What does replay-exact mean?
Meta does not publish a formal definition. It may refer to reconstructing the recorded runtime sequence. Stronger interpretations, such as identical model outputs, identical workspace state, or exactly-once external effects, require additional contracts.
Are Muse Code background agents persistent across sessions?
The official post says they remain active throughout each session. It does not claim that worker processes or their in-memory state survive session boundaries or host failures.
Can an append-only event log guarantee exactly-once tool execution?
No. External mutations need a server-supported idempotency key, atomic result recording, reconciliation, at-most-once handling, or compensation. A local log alone cannot control a remote system's commit.
How should teams evaluate crash recovery in an AI coding agent?
Inject failures before and after model calls, local edits, remote mutations, compaction, concurrent worker commits, and upgrades. Verify repository hashes, event order, remote object counts, recovery time, and duplicate-effect rate.
References
- Meta AI Research, Introducing Muse Code and Muse Spark 1.2, August 5, 2026.
- Meta AI Research, Muse Spark 1.2 and Muse Code Evaluation Methodology, accessed August 10, 2026.
- Microsoft Azure Architecture Center, Event Sourcing pattern, updated March 28, 2026.
- AWS Builders' Library, Making retries safe with idempotent APIs, 2021.
- Temporal, Workflow definition: deterministic constraints, accessed August 10, 2026.
- OWASP, Logging Cheat Sheet, accessed August 10, 2026.