Manus AI Pricing: What an Expiring Credit Balance Costs

Manus AI pricing starts at $0 for a free plan that hands you 300 credits a day, $20 a month for a Pro plan that starts at 4,000 credits, $40 a month for one that starts at 8,000, and $20 per seat per month for Team, with 17 percent off annual billing. Those are the numbers from Manus's own Help Center, checked on July 31, 2026. The number that decides your actual bill is none of them. It is the expiry rule attached to each balance.

Our position is that on a credit plan whose balance resets, the published price per month is the least useful figure on the page. What you pay is the price of the credits you use, and Manus states plainly that unused monthly credits do not roll over. That turns the purchase into a usage forecast, and Manus's own pages disagree about whether the product can even tell you what a task will cost before you run it. On Hacker News in December 2025, a commenter posting as mercurialsolo dismissed the product on exactly this point, writing that Manus had "shot themselves in the foot by sharing very limited usage credits". The complaint is not the sticker. It is the balance.

The short answer: Manus AI pricing is $0 / $20 / $40 per month and $20 per seat for Team, but because monthly credits reset to zero at the end of each cycle and Manus's own pages disagree about whether a pre-task cost estimate exists, the honest way to price it is your effective rate at partial use — at 50 percent utilisation the $20 plan costs $10 per 1,000 credits consumed, double its headline rate.

Last updated: July 31, 2026.

What Manus AI pricing actually costs today

Manus AI pricing has four published entry points: a free plan at $0 per month, two Pro plans starting at $20 and $40 per month, and a Team plan starting at $20 per seat per month. All three paid tiers carry a stated "17% discount with annual billing." Every figure below is quoted from Manus's Help Center article on current membership pricing, which carries an internal update stamp of March 16, 2026, and which we fetched on July 31, 2026.

Two things about that table deserve more attention than they usually get.

The first is the word "from." Manus writes "Starting from $20/month" and "Starting from 4,000 credits per month," which is the vendor telling you in advance that a tier is a range rather than a point. The same Help Center article notes that legacy Basic and Plus subscribers keep their old terms: "Existing member users will still auto-renew with unchanged prices." A pricing page that grandfathers old plans is a pricing page that has changed before, which is the first argument for pinning your numbers to a fetch date rather than to a memory.

The second is the arithmetic nobody prints. Divide price by credits and both Pro tiers land on the same unit rate.

Moving from the $20 plan to the $40 plan buys you exactly nothing on rate. It buys headroom. You are not paying more to get a better price per unit of work; you are paying more to lower the odds of running out, and, as the rest of this article shows, to raise the odds of forfeiting what you did not use. That single observation reframes the whole ladder. On most SaaS ladders the higher tier is a volume discount. On this ladder the higher tier is an insurance premium, and the insurance pays out in a currency that expires.

For a wider view of how per-unit meters behave once several of them run at once, our analysis of Workato pricing and counting the meters before the quote walks the same problem in an integration platform.

Five credit buckets, five different expiry clocks

Credit-based pricing usually implies a single wallet. Manus does not have one credit balance. It has five, they expire on five different schedules, and they are spent in a fixed order. Manus's own credits page states the order plainly: event credits are consumed first, then daily, then monthly, then add-on, then free. Understanding that order is the difference between a plan that behaves and a plan that quietly evaporates.

The daily bucket resets at 00:00 UTC and does not accumulate. The monthly bucket refreshes on the same calendar date each month, keyed to your subscription start date rather than to the first of the month, so a subscription that began on the 13th has a balance that dies on the 13th. On the cancellation article Manus is more explicit still: "Any unused credits remaining from monthly allocations are reset to 0 once the subscription cycle ends."

The spend order is, to be fair to Manus, the consumer-friendly one. Spending the fastest-expiring bucket first is exactly what you would design if you wanted customers to lose as little as possible. It is worth saying so, because most of this article is a criticism of the model and that particular design choice is not.

What the order cannot fix is the size mismatch between buckets. Daily credits are small and die nightly. Monthly credits are large and die on one date a month. Add-on credits, which are the only paid balance that survives a cycle boundary, sit fourth in line and are reached only once the monthly allowance is spent. That ordering is sensible on its own terms, and it is also why a top-up does not protect a monthly balance: buying more credits never rescues the ones already ticking down. The two balances are not fungible in the direction you would want.

That is the mechanism this whole article is about, so it is worth restating in one line: on Manus, the balance you paid for on a subscription has a deadline, and the deadline is not negotiable by usage patterns.

Where Manus's own pages disagree about expiry

Three Manus-published pages describe add-on credit expiry, and they do not say the same thing. This is not a gotcha; it is the single most important thing a procurement reader can take away from this article, because it determines whether a top-up purchase is an asset or a rental.

"Never expire" and "become inactive if the subscription lapses" are different promises. Under the first, an add-on purchase is money in a wallet you own. Under the second, it is money in a wallet that locks the moment you stop paying rent on the wallet. A finance team that reads the docs page and books add-on credits as a prepaid asset is working from a different contract than a finance team that reads the cancellation article.

We are not asserting which page is binding. We could not read Manus's Terms of Service — it renders client-side and returned no policy text to either a plain fetch or a browser-user-agent fetch on July 31, 2026, and the browser tier of our fetch ladder was unavailable at the time of writing. That is precisely why this belongs in the order form rather than in a blog post's conclusion: ask Manus to confirm in writing, on the order form, what happens to purchased add-on credits if the subscription lapses or downgrades. A vendor whose own pages disagree will usually answer that question quickly, and the answer becomes the contract.

Accountants have a word for the revenue a seller keeps when prepaid value goes unredeemed — breakage — and how it is recognised is a question for your controller and your auditor, not for us. We raise the term only so the right person inside your company knows to ask.

What a task costs, and whether you can forecast it

Manus publishes example task costs, and they are useful anchors. On its credits page it gives three: a data analysis task at 200 credits and about 15 minutes, a website design-and-deployment task at 360 credits and about 25 minutes, and a complex app development task at 900 credits and about 80 minutes. Priced at the $5.00 per 1,000 rate derived above, that is $1.00, $1.80 and $4.50 of subscription value per task.

Read as a rate card those numbers look cheap, and for a lot of work they are. Read as a budget they fall apart, because none of them is a price. They are illustrations of what particular tasks happened to cost. Manus says as much: the credits a task consumes depend on "the intricacy of the assigned task," and consumption is driven by three underlying meters: LLM tokens, virtual machines, and third-party APIs.

Whether you can see a task's cost before you run it is the question that should shape your purchasing approach, and here Manus's pages give two different answers.

That is the second time in this article that two Manus-published pages describe the same mechanism differently, and the pattern is worth naming: the product documentation describes the product as the team intends it, and the Help Center describes it as support has to explain it. When those diverge, the Help Center is usually the one written after a customer complained.

We are not in a position to referee it. We have not run a paid Manus subscription, so we have not seen the dashboard. What we can say is what a buyer should do with a disagreement like this: open a trial account, look for the estimate before signing, and treat its absence or presence as a factual question you answer yourself rather than one either page settles. If the estimate exists and is accurate, most of the forecasting problem in this article softens considerably. If it does not, the Help Center's answer stands, and in procurement language that reads: the seller cannot quote the unit quantity the buyer is being asked to pre-purchase.

The same documentation page also lists usage tooling that matters here: "Alerts: Get notified when your credit balance is running low" and "Spending Insights: Understand which types of tasks consume the most credits." Both are the right primitives. Neither is described with a threshold you can configure or a scope you can set per team on that page, so their usefulness for a budget owner is exactly what you should test in the trial.

There is one meaningful mitigation, and Manus states it: "Credits are only consumed during active task processing. Completed tasks and the storage or deployment of their outputs do not consume any credits." So an idle account does not bleed. The meter is genuinely tied to work being done, which is more than can be said for seat-based models where an unused licence bills identically to a used one.

Manus's own optimisation guidance quietly confirms where the variance lives. Its advice is to group related questions into one task, keep instructions "clear, concise, and direct," and stop resubmitting variations, because "repeatedly asking variations of the same question can exhaust credits unnecessarily." Every one of those is a prompt-quality lever. Which means the variance in your bill is substantially a function of how well your people write instructions, a skill distribution you cannot read off a pricing page and cannot forecast for a team you have not yet trained.

This is where the honest limit on our side belongs: we have not run a paid Manus subscription and measured credit burn across a month, so every figure in this article is derived from Manus's published numbers rather than from our own metering. Where we compute, we show the arithmetic so you can check it.

The Half-Use Price: costing the plan you will not finish

Here is the framework we would use, and it takes one line of arithmetic. Call it the Half-Use Price: the effective cost per 1,000 credits you actually consume, assuming you use half of what you bought. It is deliberately pessimistic, and that is the point. The headline rate assumes a perfect forecast, and a perfect forecast is the thing the Help Center says the product cannot help you make.

Effective rate = plan price ÷ (credits actually used ÷ 1,000).

On the $20 Pro plan with 4,000 credits:

The shape matters more than any single row. The effective rate is a hyperbola: it is flat and boring near full utilisation and it explodes as usage falls. A team that uses 90 percent of its balance pays $5.56 per 1,000. A team that uses 30 percent pays $16.67. Same plan, same invoice, triple the real cost of work.

Run the same table on the $40 tier and the answer is identical in shape, because the unit rate is identical: 4,000 credits used out of 8,000 is $10.00 per 1,000, exactly what half-use costs on the smaller plan. Upgrading does not protect you from the forfeiture curve. It moves you further up it, because a bigger balance is a bigger thing to leave unused.

Annual billing complicates this in a way the 17 percent discount disguises. Annual billing cuts the effective monthly rate from $5.00 to $4.15 per 1,000, which is real money. It does not change the monthly refresh: Manus refreshes credits monthly for annual subscribers too, on the same calendar date. So an annual contract is not one forecast. It is twelve. You take the discount and you accept twelve separate opportunities to forfeit a balance, locked in for a year. If your usage is seasonal, that trade is worse than 17 percent looks.

The decision rule we would give a buyer is short. Compute the Half-Use Price. If you would not sign at that number, do not sign at the headline number, because the only thing standing between the two is a forecast that, on the Help Center's account, the product cannot produce for you.

Over-buy or under-buy: both paths, priced

AI agent pricing built on credits makes every purchase a bet in one of two directions, and the two directions do not cost the same, which is why buyers drift one way.

If you over-buy, the cost is quiet and deferred. Nothing breaks. Work completes. At the cycle boundary the surplus is reset to zero and the loss shows up nowhere except in an effective-rate calculation that nothing in the billing flow requires anyone to run. It is a cost with no owner and no alert.

If you under-buy, the cost is loud and immediate. A task stops. Someone is blocked. Somebody expenses a top-up, or upgrades the plan mid-cycle — and Manus handles a mid-cycle upgrade for web subscribers by issuing "the credits for the difference between the two plans based on the remaining time of your current plan," while it states that "Downgrades do not take effect immediately" and land only at the next renewal. Notice the asymmetry in that pair: going up is same-day, going down waits for the boundary. That is a standard SaaS convention rather than anything unique to Manus, but on a plan whose balance expires it means the correction for over-buying is slower than the correction for under-buying.

The prorated upgrade is also billing-channel specific, and this is worth checking before you rely on it. Manus scopes that proration to subscriptions taken through Stripe. The same Help Center article describes a different path for app-store billing: an Apple upgrade is handled as a refund of the old plan and a charge at the full price of the new one, and a Google Play upgrade requires paying the full price of the new plan. If your team subscribed through a phone, the cheap-correction argument below is weaker than it looks on the web.

Put the two together and you get a ratchet. The pain of under-buying is felt by a named person on a deadline. The pain of over-buying is felt by a budget line. Organisations reliably optimise against the first. A Hacker News commenter posting as benoau put the seller's side of it in June 2026, arguing that AI credits expire because vendors "make the least money off you if you actually use your full quota". That is a stranger's opinion rather than evidence of intent, and we present it as such. It does name the equilibrium correctly.

Academic work on tariff choice found the same behaviour long before AI agent pricing existed. In Paying Not to Go to the Gym, published in the American Economic Review in 2006, Stefano DellaVigna and Ulrike Malmendier reported that "overconfident agents overestimate attendance as well as the cancellation probability of automatically renewed contracts," and documented members paying over $17 per expected visit while a $10 per-visit option sat next to it. Substitute credits for gym visits and the structure is unchanged: people buy the plan that matches their intentions rather than their behaviour, and auto-renewal keeps them there.

What the daily reset quietly forbids

The free plan's 300 daily refresh credits look generous multiplied out: 300 a day is roughly 9,000 a month, more than twice the 4,000 on the entry Pro plan. Two published rules dismantle that arithmetic. First, daily credits cannot be banked — Manus states that unused daily credits "will disappear at the reset time," and the reset lands at 00:00 UTC. Second, the free tier has a ceiling on the whole bucket: "The monthly consumption limit for daily refresh credits for free users is set to 1,500 credits; paid users have no limit." So the real free allowance is 1,500 credits a month, not 9,000, and it arrives in 300-credit daily slices that cannot be combined.

That converts a budget question into a capability question. Manus's own example of a complex app development task costs 900 credits. A 300-credit daily ceiling cannot fund it, no matter how many days you save, because there is no saving. Setting aside the free plan's separate feature restrictions, which limit it to Chat Mode and Manus 1.6 Lite in Agent Mode rather than the full Agent range, the expiry rule alone puts a hard ceiling on the size of any single piece of work the free tier can complete.

The UTC detail is small and practical. If your team is in Los Angeles, the daily bucket dies at 4 p.m. local in winter and 5 p.m. in summer. Somebody starting a long task at half past three on a January afternoon is not working against the clock they think they are. It is the kind of detail that tends not to reach a runbook until it has cost someone a deadline.

For a broader treatment of what happens when the unit of billing is defined by the vendor rather than by the buyer, our piece on who defines a resolution in chatbot pricing covers the same structural problem in a different market.

Refunds: what comes back, and what does not

Manus publishes a credit refund policy, and it is more specific than most. It draws the line at fault. Credits come back when the platform failed; on that article's account they do not come back when the outcome merely disappointed you, though a second Manus page complicates even that, as this section goes on to show.

Two of those rows carry most of the risk. "Ambiguous, contradictory, or incomplete" instructions covers a very large share of real agent failures, and it is the buyer's side of the line. So does the third-party row: an agent that browses the web for you inherits every flaky site it visits, and Manus places that risk on you. Between them they mean the practical refund rate on a messy month will be low even where the work was genuinely wasted.

There is a third disagreement between Manus pages here, smaller than the expiry one but the same shape. The refund-policy article excludes "subjective dissatisfaction" outright, while the article describing how to apply for a credits refund says Manus supports refunds where users "are not satisfied with the results generated by Manus" and lists "Unsatisfactory Outputs" as a qualifying category. If output quality is your main refund exposure, that is the sentence to get confirmed in writing before you rely on either version.

The process adds a real operational requirement: a refund request needs "a shareable link to the conversation where the problem occurred," and without it "we will be unable to locate and verify the issue." If credits matter to your budget, someone has to keep those links. That is a small governance habit with a direct financial return, and it is exactly the sort of thing that never happens unless it is assigned to a named person.

Team seats and the shared pool

The Team plan starts at $20 per seat per month and adds SSO, data privacy controls and team analytics on top of the Pro feature set. Manus's product documentation says Team and Enterprise plans "include shared credit pools that all team members can access" without publishing a number on that page, and the Help Center pricing article does not state a Team credit allowance either. On July 31, 2026 we could not find a Manus-published Team credit figure, so we are not printing one. Third-party articles quote figures; none of them is the vendor.

A shared pool changes the forfeiture arithmetic in both directions, and the direction depends entirely on how similar your users are.

Pooling helps when usage is uneven and uncorrelated. One analyst's heavy week offsets another's quiet week, and the aggregate lands closer to the mean than any individual would. That is straightforward risk-pooling, and it is a real argument for the Team tier over a stack of individual Pro seats.

Pooling hurts in two specific cases. First, when usage is correlated, with everyone quiet in August and everyone busy at quarter end, pooling does not smooth anything and the whole pool expires together. Second, when the pool has no internal accounting, a shared balance means no team can see what it consumed, so the effective rate cannot be computed per team and the over-buy has, again, no owner. Seat-level attribution inside a shared pool is the thing to ask about in the demo, and "team analytics" on a feature list is not the same as per-team chargeback.

If per-seat and per-pool cost attribution is the crux of your decision rather than a detail, our analysis of what one agent run bills on Relevance AI works through the run-level version of the same accounting problem.

Three cycles at the floor: how to size the plan

Given that credit consumption is hard to forecast from a standing start, and that Manus's own pages disagree about whether the product will estimate it for you, the sizing procedure follows from the structure. We call it three cycles at the floor, and it is four steps.

Step one: start on the smallest paid plan you can tolerate, not the one that matches your ambition. The forfeiture curve punishes over-buying, and for subscriptions taken on the web the correction for under-buying is same-day, because Manus issues prorated difference credits on a mid-cycle upgrade. The cheap error is the recoverable one. Check first that your billing channel gives you that proration, because Manus describes the app-store paths differently.

This is measurement, not forecasting, and the distinction is the point. Nobody is asking you to predict what a task will cost. You are being asked to observe what a month of your own work costs, three times, before committing to a size.

Step two: measure for three full cycles, not one. One month tells you almost nothing about a workload with a monthly rhythm. Three cycles will show you whether your consumption has a quarter-end shape, a holiday trough, or a step change when a new team starts using it.

Step three: compute the Half-Use Price on your real numbers at the end of each cycle. Divide what you paid by the credits you actually consumed. If that number is comfortably under your alternative, whether that is running the same work through a general model API or having a person do it, the plan is working. If it is not, the plan is not too expensive; it is the wrong size.

Step four: size up only when two consecutive cycles hit the ceiling, and prefer add-on credits over a tier upgrade if, and only if, you have written confirmation of what happens to add-on credits when a subscription lapses. Until that confirmation exists, a tier upgrade is the more conservative instrument, because the terms on a monthly allowance are the ones Manus states most clearly and most consistently.

Sizing on measured burn rather than on a plan comparison chart is the whole discipline. The chart is designed by the seller; the burn rate belongs to you.

So is Manus worth the money? On the published numbers the honest answer is conditional, and the condition is utilisation. A team that reliably consumes most of its balance is buying agent work at a few dollars a task, which is defensible against almost any alternative. A team that consumes a quarter of it is paying four times that rate for the same work, and would be better served by a smaller plan, a pay-as-you-go model API, or no subscription at all. The plan does not decide which team you are. Three cycles of measurement does.

Corporate finance teams are working through exactly this shift across their whole AI portfolio, not just one vendor. CNBC's May 2026 segment on the trade-off between tokens and headcount is a useful long-form look at how budget owners are framing the question.

Ten things to put in the order form before you sign

These are the questions whose answers we could not resolve from Manus's public pages, plus the ones whose published answers are worth converting into contract language. None of them requires a lawyer to ask.

Item three is the one buyers skip and should not. A credit is a unit of the vendor's cost, not a unit of your work, and the mapping between them is set by the vendor. The 2025 edition of the Stanford HAI AI Index Report found that "the inference cost for a system performing at the level of GPT-3.5 dropped over 280-fold between November 2022 and October 2024." If the cost of the underlying work falls that fast while the credit price stays fixed, the value of a credit is a policy choice, not a constant. A newer 2026 edition of the same report has since been published and its headline takeaways do not restate that figure, so treat the 280-fold number as describing the 2022–2024 window specifically rather than as a current rate of decline.

Item ten sits slightly outside the pricing conversation and belongs in it anyway. An autonomous agent that browses, calls APIs and deploys sites is touching systems on your behalf, and the credit meter is silent about which ones. Our earlier analysis of governing AI connectors and MCP server security sets out what to establish about that reach before the first task runs.

Where an expiring balance meets governance

The reason an expiring credit balance is hard to manage is not that the terms are hidden. Manus publishes them. It is that the number is unusually easy to leave unowned. The person who runs the tasks does not see the effective rate; the person who sees the invoice does not see the tasks; and while Manus documents low-balance alerts and spending insights, an expiry is not a threshold, so the reset itself is the one moment in the cycle with no natural trigger behind it.

That is the layer LeapForce builds. Our Model Routing product holds budgets in dollars rather than tokens, hierarchical and with chargeback, so an AI spend has an owner and a ceiling expressed in the unit finance actually manages. Our Observability and Audit layer records what ran and what was refused, which is what makes a per-team effective rate computable at all. And our approach to the gateway rollout is deliberately sequenced — Observe first. Enforce second. Optimize third. — because you cannot set a sensible cap on a workload you have not yet measured, which is the same conclusion the three-cycles-at-the-floor procedure reaches from the buyer's side.

To be plain about the limit: LeapForce does not resell Manus credits, does not make an expiring balance non-expiring, and cannot change what a Manus task costs. What it changes is whether the spend has an owner, a budget in dollars, and a record.

Honest limits: what we could not verify

This article is built on published vendor documents and arithmetic derived from them. Several things in it are genuinely uncertain, and the useful version of this piece says which.

We could not read Manus's interactive pricing page or its Terms of Service. Both render client-side; a direct fetch and a browser-user-agent fetch both returned page shells with no pricing or policy text on July 31, 2026, and the browser tier of our fetch ladder was unavailable at the time of writing. Every price and every credit rule quoted here therefore comes from Manus's Help Center and product documentation, which are server-rendered, rather than from the marketing page a buyer would see. If those disagree, the marketing page and the contract win.

Third-party articles quote a higher Pro tier and specific Team credit numbers that we could not confirm on a Manus-published page. We have left them out rather than repeat them. Several vendors in this market repriced during 2026 while third-party summaries kept quoting old rates; treat any figure without a fetch date, including ours after a few months, as stale.

We could not find a published answer to what happens when a balance runs out mid-task. Manus documents that credits are consumed during active processing and that hitting a resource limit is not refundable, but we found no page stating whether a running task pauses, fails, or partially delivers when the balance reaches zero. For a plan sized close to actual usage, that is a material unknown, which is why it is question five on the order-form list.

We have not run a paid Manus subscription. No number in this article is our own measurement of credit burn. Where we compute, we show the inputs.

Our field voices skew technical. Reddit was not reachable through our fetch ladder, so the practitioner comments quoted here come from Hacker News, whose readership is more technical than the general buyer of an autonomous agent. Read them as directional, not representative.

Ownership changed recently. CNBC reported, in a story published late on December 29, 2025 and updated the following day, that Meta acquired Manus, and that "Manus will continue operating its subscription service after the acquisition, with no deal terms disclosed." We take no view on what that means for future pricing. We note only that a prepaid balance on any platform is a claim on a going concern, and the strength of that claim is a reasonable thing to ask about when ownership has recently changed.

The framework in this article is untested at scale. The Half-Use Price is arithmetic, not research; three cycles at the floor is a procedure we would follow, not one we have benchmarked across a population of buyers. Both are offered as reasoning you can check, not as findings.

Ready to Govern Your AI?

Talk to LeapForce — one controlled layer for every AI tool, connector, model, and agent.