Meta Launches Muse Code for Long-Running Work on Large Codebases

Meta launched Muse Code in beta on August 5, promising an AI agent that can work autonomously for up to 24 hours. The Meta TechCrunch story matters because the product targets large repositories, where coding agents remain least predictable.

Muse Code is a terminal-based agent powered by Muse Spark 1.2, Meta’s new coding-focused model. Meta says the system can plan changes, write code, run tests, and validate results across complex software projects.

That pitch puts Meta against Anthropic’s Claude Code, OpenAI’s Codex, Cursor, and GitHub Copilot. These products already compete for developers who want more than autocomplete or isolated code generation.

Meta is entering late, but it is not simply releasing another model. Muse Code combines long-running execution, persistent task history, parallel subagents, and isolated working environments.

The central question is whether those mechanisms produce dependable work, not merely longer sessions. An agent that remains active for 24 hours can complete more steps, but it also has more time to compound mistakes.

What Meta Actually Launched With Muse Code

Muse Code shifts Meta’s coding strategy from supplying a model to controlling the complete agent workflow.

Muse Code is currently a beta product that runs from a developer’s terminal. According to the Muse Code launch, Meta designed it for complete software-engineering tasks across large repositories.

A coding agent differs from a conventional chatbot because it can take actions through tools. It can inspect files, edit code, execute commands, read test results, and revise its approach.

Meta says Muse Code can remain active for as long as 24 hours and perform more than 1,000 tool calls. Those limits position the product for migrations, debugging investigations, and features that span many services.

The agent can also delegate work to parallel subagents. Each subagent operates in an isolated Git worktree, which is a separate working copy attached to the same repository.

That isolation matters because simultaneous agents can otherwise overwrite files or interfere with each other’s unfinished changes. Worktrees let them explore separate branches before the main agent evaluates their output.

Meta also describes an append-only local event log. This record preserves actions and results so the system can reconstruct earlier work instead of relying entirely on a model’s active context.

Persistence is important in long tasks because context windows are finite. Even large windows become crowded when an agent reads thousands of files, command results, tests, and intermediate plans.

Muse Code therefore treats memory as an operational system rather than one long prompt. Its history can survive context compression and, according to Meta, continue across process restarts.

The product runs on Muse Spark 1.2, an updated model focused on coding. Meta is distributing that model through Muse Code and its developer API.

Meta has not published enough independent evidence to establish how these features behave across unfamiliar enterprise repositories. The announcement describes the intended system, while the beta will reveal its practical limits.

The distinction is essential. Planning, persistence, and tool access are capabilities. Reliable completion requires correct decisions across every stage of a task.

Muse Code creates more opportunities for the model to inspect and verify its work. It also creates more opportunities for a mistaken assumption to travel across subagents.

That tension makes the launch more consequential than another benchmark update. Meta is testing whether better orchestration can narrow the gap between impressive coding demonstrations and dependable software maintenance.

Why Large Codebases Are the Real Test

The hardest part of coding-agent work is locating the right context without losing the relationships that make a change safe.

Small coding demonstrations often begin with a self-contained request. The model sees the relevant function, writes a patch, and runs a focused test.

A production repository rarely offers that clarity. A seemingly local change can affect shared schemas, build rules, deployment scripts, authentication policies, and services maintained by different teams.

Large repositories also contain competing sources of truth. Documentation can be stale, tests can be incomplete, and two implementations can reflect different stages of a migration.

The agent must decide which evidence deserves priority. It must also recognize when the available evidence is insufficient and ask for human direction.

Meta’s earlier Muse Spark 1.1 release already targeted these problems. The company said that model could diagnose complex bugs, implement enterprise features, and execute large migrations.

Muse Spark 1.1 supported planning, subagent delegation, goal conditioning, and context compaction. Context compaction summarizes earlier work so the agent can continue without retaining every raw interaction.

It also had a one-million-token context window. That capacity can hold substantial code and documentation, but repository size alone is not the decisive metric.

The model still needs to retrieve the correct files. It must understand dependencies, distinguish generated code from source code, and avoid treating unrelated matches as relevant evidence.

Muse Code adds a purpose-built harness around that model lineage. A harness is the execution layer that gives a model tools, instructions, permissions, memory, and feedback.

This design reflects an important change in coding-agent competition. Model intelligence remains important, but the surrounding system increasingly determines whether that intelligence survives a long workflow.

A capable model inside a weak harness can repeat searches, forget decisions, or declare success without running the right tests. A structured harness can constrain those failures and expose them to reviewers.

Muse Code’s event log addresses forgotten history. Isolated worktrees address parallel-edit conflicts. Persistent agents address tasks that exceed one interactive session.

None of those features guarantees that the agent understands a repository’s architecture. They improve the conditions under which it can attempt that understanding.

A realistic large-codebase task might begin with a failing checkout flow. The visible error could originate in a frontend component, an API contract, or a database migration.

Muse Code would need to trace the failure across those boundaries. It would then have to modify the correct layer, preserve compatibility, and select tests that capture the affected behavior.

An agent can produce syntactically valid code while misunderstanding the contract between services. That kind of error often passes a narrow unit test and fails under integration traffic.

Large repositories therefore reward disciplined context gathering more than raw code generation. They also expose the cost of confident but incomplete reasoning.

Engineering teams evaluating Muse Code should measure how often it finds the true dependency chain. The amount of code it generates is a much weaker signal.

Meta TechCrunch Coverage Reveals Who Faces Pressure

Meta’s target is the established agent workflow owned by Anthropic, OpenAI, Cursor, and GitHub, not the traditional autocomplete market.

The cited Meta TechCrunch coverage frames Muse Code as Meta’s answer to products that already handle multi-step software tasks.

Anthropic helped establish the terminal-agent format with Claude Code. OpenAI’s Codex also works through repositories, executes tools, and produces changes for developers to review.

Cursor has pushed the category toward persistent automation. Its asynchronous agents aim to reduce the prompt-and-monitor loop that keeps developers watching each task.

GitHub has a different advantage. Copilot already sits beside repositories, issues, pull requests, Actions workflows, and organizational access controls.

Meta must persuade developers to introduce another agent into that chain. Compatibility with existing tools helps, but trust and workflow integration will decide adoption.

Muse Code’s strongest competitive argument is its combination of model and harness. Meta can train Muse Spark against the same operating patterns that Muse Code uses in production.

That alignment can reduce friction between a model’s learned behavior and the tools available at runtime. A model trained for parallel delegation should use subagents more deliberately than a generic model.

Meta also has extensive internal experience with large software systems. Its earlier CodeCompose assistant served tens of thousands of developers across nine programming languages, according to published CodeCompose research.

Internal experience does not automatically transfer to customer environments. Meta controls its own infrastructure, conventions, evaluation systems, and developer policies.

External repositories contain different languages, build tools, permission models, and undocumented assumptions. Success inside Meta is supporting evidence, not independent validation.

The company’s late entry can still pressure competitors in two ways. First, another major provider gives buyers more leverage when selecting a coding model or agent platform.

Second, Meta can connect feedback from its model API and Muse Code. That connection may accelerate improvements in tool use, task recovery, and repository navigation.

Competitors retain important defenses. Anthropic has accumulated usage experience through Claude Code, while OpenAI can improve Codex through its own agent workflows.

Cursor owns an integrated editor experience, and GitHub controls the collaboration surface where many code changes become reviewable work.

Muse Code must therefore win on task completion, not feature count. Parallel subagents mean little if their output requires more review than one carefully supervised agent.

Developers will also compare how each product handles interruptions. A useful agent should explain what it changed, what remains uncertain, and how a reviewer can reproduce its verification.

This is where the competitive fight becomes operational. The winning system will not be the one that writes the most code.

It will be the agent that turns an ambiguous request into a reviewable change while preserving evidence. That includes plans, command results, tests, diffs, and unresolved risks.

The 24-Hour Promise Creates a Reliability Tradeoff

Longer autonomy increases the value of successful work and the potential cost of an undetected mistake.

Meta’s 24-hour operating window sounds useful because major migrations rarely fit inside a short chat. An agent may need to inspect dependencies, update many packages, and run lengthy test suites.

Persistence also reduces the burden of restarting a task after context compression. The event log gives the system a record that can support recovery.

Yet time is not the same as progress. An agent can spend hours following the wrong hypothesis, repeatedly adjusting symptoms without identifying the original defect.

Parallel execution expands that problem. If the main agent delegates from a flawed plan, several subagents can create incompatible changes at once.

Isolated worktrees prevent direct file collisions. They do not resolve conceptual conflicts, such as two subagents implementing different assumptions about the same interface.

The main agent must reconcile those assumptions. That requires understanding why each change exists, not simply merging patches that pass local checks.

Verification creates another challenge. A coding agent can run tests, but it must choose tests that represent the true acceptance criteria.

Existing test suites may omit security boundaries, performance behavior, accessibility requirements, or interactions with external services. Passing tests should increase confidence, not end the investigation automatically.

Meta says Muse Code can write and validate code, but validation remains a company claim until broader testing confirms it. Beta users should examine the evidence attached to every completion.

The most useful review package should include the original plan, changed files, executed commands, test results, and known gaps. It should also identify assumptions that the agent could not verify.

Security teams will need clear controls around tool permissions. A terminal agent can read local files, execute scripts, access credentials, and interact with network services.

Organizations should limit those capabilities according to task requirements. A documentation update does not need production credentials, and a test repair should not control deployment infrastructure.

The same caution applies to data governance. Source code can contain proprietary logic, customer identifiers, internal endpoints, and security-sensitive configuration.

Teams need explicit answers about what leaves the machine, what Meta retains, and whether activity can be used for model improvement. Those answers should come from applicable terms and enterprise controls.

Muse Code’s local event log could improve auditability because developers can inspect a durable action history. Its value depends on completeness and resistance to accidental alteration.

An event log also creates sensitive data. Commands and outputs can expose paths, secret values, customer data, or details about vulnerabilities.

Organizations must decide how long to retain those logs and who can access them. Useful traceability should not become uncontrolled duplication of sensitive engineering information.

Long-running agents also change developer behavior. People may review a large finished diff instead of guiding smaller decisions throughout the task.

That approach can save attention when the agent works correctly. It can increase review burden when the final change contains many connected mistakes.

Teams should start with bounded tasks and explicit approval gates. They can expand autonomy after measuring failure patterns in their own repositories.

Meta’s promise is therefore best understood as increased operating capacity. Reliability still depends on permissions, context quality, verification design, and human review.

Benchmarks Cannot Settle the Muse Code Question

A model score cannot show whether Muse Code will respect the hidden constraints inside a company’s repository.

Meta has used evaluations to argue that the Muse Spark family improved at coding and agentic work. Those results help compare model versions under controlled conditions.

They do not replicate a living codebase. Public benchmarks usually provide a defined issue, a fixed repository state, and an automated method for judging the patch.

Enterprise tasks often begin with incomplete descriptions. Requirements change while work is underway, and the correct behavior may exist only in conversations or operational history.

An agent may also face environmental failures unrelated to its code. Dependencies can disappear, tests can be flaky, and credentials can expire.

The agent must distinguish those failures from a defective patch. That distinction requires judgment, documentation, and sometimes a human decision.

Benchmark contamination adds another uncertainty. A model can appear stronger when training data overlaps with public tasks, even without directly reproducing an answer.

Independent evaluations help, but harness differences can still change results. Tool design, prompting, context retrieval, and retry policies all influence completion rates.

Muse Code should therefore be evaluated as a system. Testing Muse Spark 1.2 inside another harness would answer a different question.

A useful internal trial should include representative repository tasks that were completed previously by human engineers. Reviewers can compare the agent’s process with the accepted change.

Teams should include different task categories. Bug localization, dependency upgrades, migrations, feature implementation, test repair, and documentation each stress different abilities.

The trial should record more than pass rates. Important measures include unnecessary file changes, review time, reverted patches, missed requirements, and human interventions.

Time-to-first-patch can be misleading. A fast patch that consumes hours of review may reduce overall engineering throughput.

The same applies to token usage or tool-call counts. More calls can reflect careful investigation, but they can also signal repeated confusion.

A strong result would show that Muse Code reduces total completion time while maintaining quality. It should also produce evidence that helps reviewers find mistakes quickly.

Developers should test how the agent behaves when instructions conflict. Large repositories commonly contain old guidance beside newer policies.

They should also introduce tasks with intentionally missing information. A trustworthy agent should surface uncertainty instead of inventing a requirement.

Failure recovery deserves separate evaluation. Teams should interrupt a task, restart the agent, and check whether its persistent history restores the correct plan.

Parallel subagents should be tested on changes with shared dependencies. Reviewers can then see whether the main agent detects incompatible assumptions before integration.

Security testing should include malicious or misleading text inside repository files. Coding agents can encounter prompt injection, where untrusted content attempts to redirect their behavior.

Meta previously said Muse Spark 1.1 resisted several forms of prompt attack under its evaluations. Those company-run results do not remove the need for repository-specific testing.

Muse Code’s beta status makes caution reasonable. Beta products often change interfaces, default permissions, logging behavior, and supported environments.

The right conclusion is neither that Muse Code works nor that it fails. Meta has presented a credible architecture for difficult tasks, while independent operational evidence remains limited.

What Developers Should Watch Next

The next three signals will show whether Muse Code becomes a serious engineering system or remains an ambitious beta.

The first signal is independent task completion on unfamiliar repositories. Public trials should include multi-service changes, hidden tests, and review by maintainers who know the code.

Successful results would strengthen Meta’s argument that persistent context and subagents improve large-repository work. Frequent architectural mistakes would weaken it, even if benchmark scores remain high.

The second signal is the quality of enterprise controls. Teams need detailed documentation for permissions, code retention, event logs, audit access, and administrative policy.

Clear controls would make Muse Code easier to pilot near proprietary code. Missing or shifting terms would keep security-conscious organizations on established platforms.

The third signal is competitive response. Anthropic, OpenAI, Cursor, and GitHub will likely emphasize longer tasks, better memory, parallel agents, or stronger review workflows.

If rivals adopt similar persistent architectures, Meta will have identified a meaningful direction for the category. If they focus elsewhere, Muse Code’s design may reflect a narrower use case.

Developers should also watch how Meta updates Muse Spark 1.2 through the beta. Improvements in the model can change tool selection and debugging behavior without redesigning the harness.

That model-harness connection is Meta’s central strategic asset. It gives the company control over both reasoning and execution.

However, integrated control can also increase switching costs. Teams may build policies and evaluation data around behavior that changes between model versions.

Engineering leaders should preserve their own acceptance criteria. Vendor benchmarks and demonstrations should supplement internal evidence, not replace it.

The Meta TechCrunch story signals that coding agents are moving beyond interactive assistance. The new contest centers on sustained, auditable work across repositories that no model can read carelessly.

For individual developers, the practical response is disciplined experimentation. Choose a bounded task, restrict permissions, preserve the diff, and examine every claimed validation step.

For engineering teams, repository knowledge becomes increasingly important. Agents perform better when architecture decisions, runbooks, and ownership rules are searchable and current.

A searchable knowledge base can help people assemble that context before assigning work. It does not remove the need for repository-native instructions and executable tests.

The Meta coding agent should be judged by the work it leaves behind. Reviewable evidence matters more than a confident completion message.

Muse Code has an architecture aimed at the right problem. It treats long software tasks as persistent, parallel processes rather than extended chat sessions.

Now Meta must show that longer operation produces better decisions. The strongest proof will come from real repositories, independent reviewers, and failures that the system explains honestly.

Before trusting a 24-hour run, ask a narrower question: can Muse Code complete one representative task while preserving every decision a human reviewer needs? That experiment will reveal more than a launch benchmark. It will show whether the agent understands your codebase, respects its constraints, and produces a change your team can safely own.