On July 9, Meta released Muse Spark 1.1, a multimodal reasoning model built for agentic work, along with the public preview of the Meta Model API. We placed it inside Swarm research and gave it an ambiguous market question. Twenty-nine agents, 40.5 million tokens, and roughly 30 minutes later, it produced a usable report. The more important result was what the surrounding system had to learn before the model could do that reliably.
The test: Swarm research #
SwarmOS is INT21’s cloud-native platform for coordinating large populations of agents. It already powers PTX Kernel Factory. Swarm research applies the same architecture to research: decompose a question recursively, search in parallel, preserve evidence, reconcile contradictions, and synthesize an auditable answer. We used our agent swarms to conduct research on various of high value topics.
We asked three model configurations the same question:
The run telemetry was:
GPT-5.6-Sol-max: 44 agents, 581,151,849 tokens, about five hours.GPT-5.6-Terra-xhigh: 17 agents, 35,875,171 tokens, about one hour.Meta Muse Spark 1.1-xhigh: 29 agents, 40,500,345 tokens, about 30 minutes.
This was not a controlled benchmark. Agent counts, prompts, token budgets, evidence cutoffs, and backend behavior differed, and token accounting can vary across APIs. The useful comparison is operational: cost, latency, evidence quality, and review effort per trusted result.
What the workload exposed #
Muse Spark did not become productive through a model swap alone. The first runs exposed three integration gaps:
- Recursive delegation had to be explicit: a subagent could launch more agents, yield while they worked, then resume and synthesize.
- Workspace boundaries had to be explicit: agents operated in isolated environments, not on one shared computer.
- API compatibility was not behavioral equivalence: Meta’s API was familiar enough for a fast integration, but this workload still required three generations of the backend adapter.
SwarmOS used those failures to improve delegation instructions, runtime assumptions, handoffs, and provider integration. One operator drove the adaptation over a few hours.
That is what self-improving means here. The foundation model’s weights did not change. The system around it learned how to assign work, recover from failure, and make the next run more reliable.
What the three reports agreed on #
We reviewed each report against the other two rather than treating any one output as ground truth.
was the strongest final synthesis. It separated documented Huawei 800G capability from unproven global hyperscaler qualification and public 1.6T leadership. It also treated Lumentum’s risk as indirect and Marvell’s exposure as two-sided because competing module vendors may still use Marvell silicon.Solprovided the cleanest conservative baseline. Its July 9, 2025 evidence cutoff established Huawei’s capability but did not find proof of non-Huawei qualification, merchant scale, hyperscaler adoption, or direct displacement of a named Lumentum or Marvell program.Terraproduced the broadest map of regulation, supply chains, technology roadmaps, and scenarios. It concluded that Huawei is a credible direct competitor in China and selected non-U.S. markets, while the wider Chinese optical ecosystem may create more immediate global pressure. Greater use of secondary sources and stronger inference increased the review burden.Muse Spark
Despite different methods and evidence cutoffs, all three reached the same bounded conclusion: Huawei is a real optical competitor, but the risk depends on product layer, geography, qualification, regulation, and supply chain. Capability is not the same as proven global commercial scale.
What should we do differently #
Treat the control plane as the durable asset
Models will change faster than enterprise systems. A control plane that can observe failures, adapt orchestration, and integrate a provider in hours reduces model lock-in. The strategic choice is not one permanent model; it is a governed portfolio behind stable interfaces.
Route models by role
The fastest worker, the best evidence reviewer, and the most conservative synthesizer may be different models. Swarm architecture makes that a routing decision instead of an all-or-nothing vendor decision.
Measure cost per trusted result
Token price is only one input. Enterprise evaluation should include elapsed time, failed calls, source quality, contradiction handling, reviewer hours, and reproducibility. A cheaper run that requires extensive verification can be more expensive in production.
Test operational semantics, not just model quality
Long-running agents depend on recursion, isolation, recovery, context compaction, evidence handoffs, observability, and exact API behavior. A strong model can still fail if those contracts are ambiguous.
The larger signal #
Muse Spark 1.1 did not win or lose a clean benchmark here. It crossed a more useful threshold: after rapid adaptation by the harness, a newly available model became a productive worker inside a recursive research system and completed a large-scale result in about 30 minutes.
For enterprise AI leaders, the architecture is the conclusion. The winning system may not be one model. It may be a control plane that continuously recruits, tests, specializes, verifies, and replaces models as capabilities and economics change.
Download the full reports #
This was an independent INT21 system test, not a controlled vendor benchmark. The research question concerns public companies, but neither this article nor the linked reports constitute investment advice.