Meta Muse Business Calls: Token Plans Do Not Measure Completed Jobs

Meta's Muse can now place calls to US businesses for paid subscribers, TechCrunch reported November 12. Testing began in September. The reported plans start at $20 a month for 500M weekly tokens and extend to $100 a month for 3B weekly tokens. None of those figures establishes how many business calls a subscriber can complete.

That distinction matters if you are buying an assistant to make appointments or handle another telephone-based task. Tokens describe a subscription resource. A finished business interaction requires cooperation from the recipient and permission from the person represented. The reporting does not establish call-minute pricing or limits, and it does not promise successful bookings.

The useful purchasing question is therefore narrower than whether Muse can dial a number. A buyer needs to know what counts as a finished job, which commitments the assistant may make, and how the result can be checked without placing another call.

Token allowances are not telephone entitlements

The $20 starting price and 500M weekly allowance are concrete subscription facts in TechCrunch's reporting. They are not a conversion table between tokens and conversations. The same limitation applies to the $100 plan's 3B weekly tokens. A procurement document should keep those units separate rather than quietly treating a larger allowance as a larger bundle of completed calls.

A telephone interaction can fail even when the assistant has enough model capacity available. A business may hang up, decline to deal with an assistant, or require information the caller has not been authorized to provide. Those possibilities create a gap between access to the feature and useful work delivered. They should appear in a pilot's outcome categories rather than being dismissed as unusual exceptions.

Ask the vendor to clarify how calling is accounted for before using the subscription price in a cost comparison. Until the call terms are established, a monthly token plan supports only a partial budget. It does not supply the denominator for a cost-per-booking calculation or establish the cost of recovering an unfinished task.

Authorization belongs in the task definition

A request to contact a business should specify the permitted outcome, not merely the destination. For an appointment request, a buyer might authorize asking about availability while reserving the final booking decision for the person involved. That is a proposed operating boundary, not a claim about which controls Muse currently provides.

The receiving business also has its own expectations. Consent friction and hangups are relevant operational limits in the fact sheet, and a caller cannot solve them by consuming more tokens. A useful trial records whether the recipient accepted the interaction and whether the requested task reached a verifiable result. An assistant's account of the conversation should not automatically become proof that the business accepted a commitment.

TechCrunch also reports Meta's claim of more than 10M Muse users last month. That number is not a count of paid subscribers, and it says nothing by itself about calling outcomes. Keep general product reach out of the evidence column when deciding whether this particular workflow is ready for staff or customers.

The hidden cost is recovering uncertain outcomes

An incomplete call leaves work behind. Someone may have to check what was said, decide whether another attempt is appropriate, or contact the business directly. Without a clear completion definition, the assistant can appear productive while returning ambiguity to the user. That recovery effort belongs in a purchasing comparison even though the supplied reporting offers no measured recovery rate.

There is also a difference between a harmless inquiry and an action with consequences. Asking for opening hours creates a different authorization problem from accepting terms or making a reservation. A sensible trial starts with a bounded request and documents what the assistant must not decide. It should not infer permission from the broad instruction to handle a call.

A trial should also distinguish an inquiry that was answered from an action that was accepted. That distinction makes the results easier to interpret when the same feature is used for different tasks. The owner can review a successful information request without claiming that the assistant has demonstrated authority to make commitments. If the business response is unclear, the record should remain unresolved until a person verifies it. These are proposed operating rules for a buyer, not documented Muse controls or measured results from the rollout.

The missing call-minute terms are a commercial limitation, not evidence of a particular hidden charge. Buyers should neither assume unlimited calling nor invent a surcharge. The defensible position is to request the terms, preserve the uncertainty in the budget, and avoid promising a service level that the subscription numbers do not support.

What To Do About It

• Separate the allowances: Have the purchasing owner list the token entitlement apart from the unanswered call-pricing questions this week, using the reported starting plan of $20.
• Define completion: Have the workflow owner require a business-side confirmation before marking a trial booking finished, and retain the confirmation in the task record rather than relying only on Muse.
• Bound authorization: Have the person requesting the call state what may be discussed and what requires approval before the trial starts, with a written permission checklist for Muse.
• Record recovery work: Have the pilot owner log hangups and uncertain outcomes alongside any successful calls this week, without confusing the results with the reported user figure of 10M.

The Bottom Line

Muse's business calling gives paid US subscribers a new action channel, not a documented quantity of completed telephone work. The $20 starting plan is useful budget information only when kept separate from unknown calling terms and real completion evidence. Buyers should test recipient acceptance and authorization before depending on bookings. A token allowance cannot settle those questions.