Meta spans Muse agents, model APIs and downloadable Llama models

Meta’s AI offer now reaches across finished assistants, personal agents, hosted models and downloadable model releases. Muse is a personal agent; Muse Spark is a model family available to developers; Llama provides a separate model-distribution route. Those names describe different purchases and responsibilities. This blueprint helps a reader choose the right layer before comparing capability, cost or control.

01 / ProductMeta’s AI products are several distinct layers

Meta’s Muse announcement describes a personal agent running in a dedicated cloud computer, accessible through an app or WhatsApp. The launch is rolling out in the US, with free use and paid subscriptions for additional capacity. Geographic rollout and plan access matter: an announcement about broad ambitions does not establish availability in every country.

The Muse Spark 1.3 release, dated 2 September 2026, identifies Muse Code and Meta Model API as access routes. The earlier API introduction explains the hosted developer offer. A model endpoint provides reasoning and generation capabilities; the surrounding application must supply its own workflow and execution environment.

Llama is a separate route. Meta’s official repository distributes model information and download instructions, while the Llama 4 licence sets release-specific conditions. Do not assume that access to Llama weights means Muse Spark weights are distributed under the same terms, or that all Meta AI products share one deployment model.

02 / AudienceChoose between using an agent and building an application

An individual who wants help coordinating tasks should first evaluate the finished product available to their account and region. A developer embedding an assistant into a business application has a different requirement: predictable inputs and outputs, permissions, error handling and a bill attributable to the application. Consumer convenience and API suitability should be evaluated separately.

For a company building a tool-enabled assistant, our Anthropic blueprint provides a contextual comparison of model and application responsibilities. The useful comparison is how each route handles your task, tools and review requirements. A broad ranking of models will not tell you whether a proposed action can be shown clearly to the person responsible for approving it.

For a team that specifically needs control over weights and hosting, the Hugging Face blueprint is the more relevant adjacent read. Start by identifying a model with suitable licence and serving requirements. Do not begin a private-deployment project around the name of a hosted assistant and only later discover that the required model is not available in that form.

03 / WorkflowA proposed project-coordination assistant using the API

Consider a small design studio that wants an assistant to prepare a daily project handover. The proposed application should read approved project records, identify unresolved decisions and draft a plan for the next work session. It should keep the project owner in control of messages and deadline changes. This is an editorial design example, not a hands-on test or a description of Meta’s internal system.

Define the output before connecting tools

Use a fixed handover structure: completed work, outstanding decisions, blocked items and proposed next actions. Each item should point to a source record. A deadline quoted in a conversation might be a suggestion; a deadline stored in the project plan might be the accepted commitment. Make that distinction visible so the assistant does not turn brainstorming into a promise.

Start with a read-only project lookup and a separate function that retrieves a specific document. Give the model stable project identifiers rather than requiring it to infer the intended client from a similar name. The application should enforce which projects the signed-in user can read before passing information to the model.

Treat a tool call as a request to your application

Meta’s tool-calling documentation says developers define and execute their own tools. It recommends the Responses API for multi-turn agents while also supporting Chat Completions. The important architectural point is that the model proposes a call and your application handles execution. A generated function name or argument is not permission to access an arbitrary record.

Validate a proposed lookup against the selected project and the user’s rights. Return a compact result with source identifiers and timestamps. If a task was updated during the conversation, fetch it again before preparing an action. The handover should not silently overwrite a newer decision with information from an earlier turn.

Keep writing separate from reading

The proposed first release should create a draft handover inside the application. A later release might prepare a message to collaborators or a changed deadline, but show the precise recipient, text and record change before execution. Preserve the distinction between drafted, approved and completed work in both the interface and stored activity history.

Do not copy Muse’s security claims onto this custom application. Meta’s Muse design explanation describes a separate Sentinel permission authority and isolated execution environment in the finished product. Those are system-level features. An API client needs its own controls even when it uses a model from the same company.

Evaluate the messy cases

Build examples with two similarly named projects, contradictory deadlines, deleted documents and a task that moved to a different owner. Include text in a project attachment that tries to instruct the assistant to ignore the user. The correct output should preserve the project boundary and identify uncertainty, rather than turn every retrieved sentence into an instruction.

Review the handover against the underlying records. Measure omitted blockers, incorrect ownership and invented completion claims. Also record how many clarifications a project owner must make before the draft becomes useful. These measures reflect the coordination job more directly than how polished the prose looks on its first attempt.

04 / PricingCurrent API prices depend on data-use permission

Meta’s pricing and limits page was inspected in the public browser on 16 September 2026. It lists the following usage prices for Muse Spark 1.3. The tier is a data-use decision as well as a budget decision; these are API charges, separate from Muse or Muse Code subscriptions.

For the proposed design studio, choose the acceptable data treatment before estimating savings. The lower Contributor tariff is unsuitable for material the organisation cannot permit to be used for training. A prototype with invented project data can answer interface questions without establishing permission to send real client documents under the same tier.

Measure cost per accepted handover, including retrieval context, repeated turns and failed attempts. Keeping the entire project archive in every request may create unnecessary usage and confusion. A concise source packet can be easier to review, provided it retains the evidence needed to understand decisions and unresolved issues. Saving tokens is useful only when it does not remove essential context.

Self-hosted Llama has a different budget. Compute, serving engineering, monitoring and capacity replace some hosted-service costs; they do not disappear. A comparison should use the same task quality and availability requirements. It should also distinguish a software licence from the commercial terms of whichever cloud provider or inference host operates the model.

05 / DistinctionsThe breadth creates choice, but also easy category mistakes

Meta’s portfolio offers several ways to encounter its AI: a finished personal agent, a hosted developer model and downloadable model releases. Our assessment is that the most useful decision is which responsibility the reader wants to retain. Someone seeking a daily assistant may value an integrated environment, while a developer needs explicit control over application behaviour and data flow.

This breadth makes product naming unusually important. A demonstration in Muse does not prove the same behaviour in a bare API call. A successful Llama deployment does not establish access to Muse Spark’s capabilities. Document the exact product, model version and tier used in any internal comparison so later teams can reproduce the decision instead of relying on the broad label “Meta AI”.

06 / QuestionsWhich privacy and availability boundaries remain important?

Meta’s Muse security account distinguishes the launch Secure VM from the planned Confidential VM. It states that the launch design does not prevent Meta from accessing data when necessary to operate the service. Do not present the stronger planned protection as an already delivered property. The same source acknowledges that agents can still make mistakes.

We have not audited Muse’s security implementation or tested Muse Spark on private project records. For a custom application, verify the selected account’s model access, tier, tool behaviour and operational limits with a bounded pilot. For the consumer product, confirm regional availability and the actual permission settings in the account before delegating a task involving connected services.

07 / DecisionPick the layer that matches the work

Meta belongs in an AI shortlist because its offer spans models and applications with materially different deployment choices. That breadth is useful only when the boundary stays clear. Decide whether you need an assistant to use, an API to build with or weights to operate, then evaluate the chosen route against the work and data it will actually handle.