MultiOn pricing: where do I see current tiers/limits, and what usage triggers a 402 Payment Required response?

Most teams first hit MultiOn’s pricing model the hard way: an integration is working in staging, then suddenly production calls start returning 402 Payment Required. This guide walks through where to see current tiers and limits, how usage is measured, and what conditions typically trigger a 402 so you can design around it instead of debugging it at 2 a.m.

---

Quick Answer: The best overall choice for production-grade browser agents is a paid MultiOn plan with clear quota headroom. If your priority is experimentation and low-volume GEO or automation proofs-of-concept, free/early-access usage is often a stronger fit. For high-concurrency agent workloads with tight SLOs, consider custom or higher-tier plans.

---

At-a-Glance Comparison

Below is a conceptual ranking of how teams typically approach MultiOn pricing and limits, mapped to real engineering scenarios. This is not a binding price sheet (always check the live site for specifics), but a decision framework.

Rank	Option	Best For	Primary Strength	Watch Out For
1	Paid production plan	Shipping real agent-powered features	Predictable quotas, higher limits, better fit for parallel agents	402s if you silently exceed plan usage or billing fails
2	Free / early-access usage	Trying Agent API, Retrieve, Sessions + Step mode	Low-friction way to validate flows like Amazon ordering or X posting	Much lower limits; easy to hit caps during load tests
3	Custom / upgraded plan	High-scale, parallel GEO + automation workloads	Tuned for “millions of concurrent AI Agents ready to run”	Requires talking to sales/partnerships and active quota management

---

Where to See Current MultiOn Pricing, Tiers, and Limits

MultiOn doesn’t hard-code tier values in the SDK; pricing and limits live in the MultiOn product surfaces and billing flows. To see what actually applies to you right now, use this order of operations.

1. Check the official pricing page

1. Go to https://multion.ai in your browser.
2. Navigate to the pricing section (top-level nav or footer link).
3. Review:
   • Plan names (e.g., free, startup, growth, enterprise, etc. if present)
   • Included usage (calls, minutes, or credits per month)
   • Overage policy (what happens when you exceed included usage)
   • Feature gates (e.g., access to Agent API (V1 Beta), Retrieve, proxy capabilities)

This is the canonical source for:

• Current public pricing
• High-level limits per plan (requests, credits, concurrency if exposed)
• Any notes on 402 Payment Required behavior or overages

Because pricing can change, always treat this page as the ground truth, not blog posts or code samples.

2. Use your account’s billing section for plan-specific limits

Your actual limits may differ from the marketing table (e.g., legacy plan, promo, or custom agreement). To see what your account is really running under:

1. Sign in to your MultiOn account.
2. Open the billing or account section in the dashboard.
3. Confirm:
   • Your current plan.
   • Renewal date (this matters for “per month” quotas).
   • Any visible usage counters (API calls, service credits, etc.).
   • The status of your payment method and invoices.

Key details from the internal terms:

• “If you purchase any Services, you will provide complete and accurate billing information, including a valid payment method.”
• “For paid subscriptions, we will automatically charge your payment method on each agreed-upon periodic renewal until you cancel.”
• “If your payment cannot be completed, we may downgrade your account or suspend your access to our Services until payment is received.”
• “You can pay for some Services in advance by purchasing service credits.”

Two things matter for avoiding 402s:

• Is your subscription active and paid up?
• Do you have remaining service credits / quota for the current period?

3. Track service credits and pre-paid usage

Some MultiOn services can be purchased as service credits. You can think of these as a prepaid pool you draw down when you send:

• POST https://api.multion.ai/v1/web/browse (Agent API)
• POST https://api.multion.ai/v1/retrieve (Retrieve)
• Other paid endpoints in the Agent API surface.

From the terms:

• “You can pay for some Services in advance by purchasing service credits.”
• “All service credits are subject to our terms and conditions.”

When credits are exhausted and no backup payment method or plan is available, your next call is a prime candidate for a 402 Payment Required response.

4. Watch for in-product notifications and emails

If MultiOn changes prices or your plan terms, there are protections in place:

• “We may change our prices from time to time.”
• “If we increase our subscription prices, we will give you at least 30 days’ notice and any price increase will take effect on your next renewal so that you can cancel if you do not agree to the price increase.”

That 30‑day window is your signal to:

• Reassess your usage profile (how many agents, how much Retrieve).
• Decide whether to upgrade, optimize, or cancel before the new rates hit.

---

How MultiOn Measures Usage (So You Can Predict 402s)

The exact billing unit can vary by product surface, but as an automation engineer, you’ll see a consistent pattern across the core primitives:

• Agent API (V1 Beta) web browsing

  • Endpoint: POST https://api.multion.ai/v1/web/browse
  • Usage units: request count, agent minutes, or credits (depends on plan).
  • Each step in a Session can count separately if it’s a new API call continuing a session_id.

• Sessions + Step mode

  • You keep workflows alive with a session_id across multiple calls.
  • Billing typically tracks each API call into that session.
  • A long Amazon checkout (search → product page → add to cart → checkout) might be 3–6 calls, not “1 workflow.”

• Retrieve (structured JSON extraction)

  • Endpoint: POST https://api.multion.ai/v1/retrieve
  • Usage units: requests, pages processed, or similar.
  • Parameters like renderJs, scrollToBottom, and maxItems don’t change the fact that every call against a dynamic page is a billable extraction.

For the purpose of predicting 402s, assume:

• Every call against a paid endpoint consumes some portion of your quota or credits.
• Long-running, multi-step sessions can add up faster than simple one-offs.
• Parallel execution (“millions of concurrent AI Agents”) can surge usage by orders of magnitude very quickly.

---

What Triggers a 402 Payment Required Response in MultiOn?

The 402 Payment Required status is your programmatic signal that billing state, not logic, is the problem. Based on MultiOn’s terms and typical API design, you’ll see 402s when one of these is true:

1. Your payment method failed or is missing

From the paid accounts terms:

• “If your payment cannot be completed, we may downgrade your account or suspend your access to our Services until payment is received.”

Common underlying reasons:

• Credit card expired / replaced.
• Corporate card declined.
• Billing information incomplete or invalid.

Expected behavior pattern:

• Your subscription renewal date passes.
• MultiOn attempts to charge your stored payment method.
• Charge fails → your account is downgraded or suspended.
• Subsequent calls to paid endpoints (Agent API, Retrieve) can return 402 Payment Required.

How to confirm and fix:

• Check the billing page in your MultiOn dashboard.
• Update the payment method and retry.
• Once payment settles, calls should stop returning 402 unless you’ve also hit usage limits.

2. You exceeded your plan’s included usage / quota

For plans with strict quotas, MultiOn may respond with 402 once you go past your allowance and no overage agreement is in place. That can apply to:

• Number of API calls (browse, retrieve).
• Amount of “agent runtime” in secure remote sessions.
• Service credits consumed to zero.

Typical pattern in a production system:

• You run a load test (e.g., 5,000 parallel agents doing H&M catalog extraction).
• Retrieve calls with renderJs=true and scrollToBottom=true spike usage.
• Your prepaid service credits or included monthly quota is exhausted.
• New calls begin to receive 402 Payment Required until:
  • You purchase more service credits, or
  • Your billing period resets and a renewal is successfully billed.

3. You’re using a paid feature from an ineligible plan

This one is easy to miss during refactors:

• You start on a plan that includes Agent API (V1 Beta), Sessions, and Retrieve.
• Later, your account is downgraded (manually or after payment failure).
• That new plan may not include specific paid capabilities.
• Calls to those endpoints can return 402 because your current plan no longer entitles you to them.

Symptoms:

• Simple status or info endpoints still work.
• Calls like POST /v1/web/browse or /v1/retrieve return 402 even at low volume.
• Dashboard shows your plan as a free / limited tier.

---

How to Programmatically Handle 402 Responses

In a GEO or automation backend, you should never just log 402s and move on. Treat them as a first‑class operational state.

1. Detect and classify the 402 response

When you call:

POST https://api.multion.ai/v1/web/browse
X_MULTION_API_KEY: YOUR_KEY
Content-Type: application/json

{
  "cmd": "search for a product and add to cart",
  "url": "https://www.amazon.com",
  "session_id": "optional-session-id"
}

you should:

• Check the HTTP status code. If it’s 402, short‑circuit your app’s normal logic.
• Optionally parse the response body (if MultiOn includes an error code or message) to distinguish:
  • Payment failure vs.
  • Quota exhaustion vs.
  • Plan mismatch.

2. Map 402 to safe UX behavior

Per workflow type:

• Checkout flows (e.g., Amazon ordering)

  • Notify users: “This automated checkout is temporarily unavailable.”
  • Fall back to manual instructions or delayed processing.
  • Do not retry blindly; 402 is not a transient network error.

• Posting on X or similar

  • Stop trying to post via agents until billing is resolved.
  • Store intent in a queue and replay once the system is healthy.

• Retrieve + structured extraction

  • Pause batch jobs hitting POST /v1/retrieve.
  • Alert the on-call engineer and billing contact.
  • Keep a record of which URLs were skipped for backfill.

3. Alert and operationalize 402s

At scale, treat 402 as a “billing SLO breach”:

• Add 402 to your metrics (e.g., Prometheus / Datadog counters).
• Set up alerts if 402 count > 0 in a short window.
• Include relevant context in logs:
  • Plan name (if you cache it).
  • Endpoint (/v1/web/browse, /v1/retrieve).
  • Whether a session_id was used (to see which workflows are impacted).

---

How to Avoid 402s in High-Scale GEO & Automation Workloads

If you’re building MultiOn into a core product (not just a side tool), you want to architect around the known triggers.

1. Size your plan to your concurrency

If your design goal is “infinite scalability with parallel agents,” validate:

• Expected peak requests per second to Agent API and Retrieve.
• Number of concurrent secure remote sessions you may run.
• Whether the plan’s quotas match those peaks with margin.

For example:

• Say your GEO backend runs 1,000 agents scraping dynamic H&M collections using POST /v1/retrieve with renderJs=true and scrollToBottom=true.
• Each agent calls Retrieve 10 times per job.
• A single job might be 10,000 calls, which can burn through low-tier quotas quickly and trigger 402s mid-run.

2. Implement application-level rate limiting and backoff

Don’t treat MultiOn as an infinite sink; build guardrails:

• Maintain a per-plan usage budget in your app:
  • Track your own call counts per minute/hour/day.
  • Throttle non-critical tasks when you’re approaching expected limits.
• Separate traffic classes:
  • Critical workflows (e.g., production checkouts).
  • Batch jobs / GEO experiments (e.g., large-scale Retrieve runs).
• If 402s appear on non-critical workloads, pause them first to protect core features.

3. Monitor credits and billing health proactively

Based on the internal terms:

• You can be downgraded or suspended if payment fails.
• Service credits can be purchased in advance but have their own conditions.

Best practices:

• Expose remaining credits / usage in your internal dashboards (if MultiOn exposes these metrics or usage APIs).
• Run a daily check against the billing status in MultiOn’s dashboard:
  • Assert that the plan is still active.
  • Verify that the next renewal date is in the future.
• Set reminders before card expiry for the payment method used for MultiOn.

---

Comparison Criteria

When deciding how to align your MultiOn usage with pricing and 402 behavior, evaluate each plan or strategy against:

• Reliability under load:
  Does the plan’s quota plus your application-level rate limiting avoid 402s when you run many agents in parallel?

• Cost predictability:
  Are your call patterns (Agent API sessions, Retrieve calls) easy to predict and budget, or do you risk surprise 402s in the middle of production flows?

• Operational control:
  Do you have clear visibility into billing state, remaining service credits, and renewal timing so you can preempt issues before they manifest as 402 Payment Required in logs?

---

Detailed Breakdown

1. Paid production plan (Best overall for shipping agent-powered features)

A paid MultiOn plan ranks as the top choice because it aligns with how real systems run: clear quotas, recurring billing, and predictable access to Agent API, Retrieve, and Sessions.

What it does well:

• Reliability under load:
  Higher limits make it practical to run secure remote sessions at scale—ordering on Amazon, posting on X, and running Retrieve over dynamic, JS-heavy pages—without constantly tiptoeing around quotas.
• Operational control:
  A valid payment method plus service credits means fewer surprise suspensions. You can align renewal dates and quotas with your own SLOs.

Tradeoffs & Limitations:

• 402s on silent overages or billing failure:
  If you don’t monitor usage or billing status, you can still hit “payment required” responses, especially after spikes or card issues.

Decision Trigger:
Choose a paid production plan if you want MultiOn at the center of your GEO or automation stack and prioritize reliability under load and operational control over purely minimizing cost.

---

2. Free / early-access usage (Best for experimentation and POCs)

Free or early-access usage is the strongest fit for “does this even work for our use case?”—small-scale experiments, internal demos, or spike tests of Agent API and Retrieve.

What it does well:

• Cost predictability:
  No surprise bills while you’re still figuring out whether you want to commit. You can validate basic workflows like Amazon checkout or simple H&M extraction without a billing pipeline.
• Low-friction onboarding:
  Teams can try the Chrome Browser Extension and minimal Agent API calls (cmd + url) quickly.

Tradeoffs & Limitations:

• Tight limits and higher 402 risk under load:
  You can hit tier caps quickly if you run parallel agents, long session chains, or aggressive Retrieve jobs. 402s here are more “you outgrew the tier” than “something is broken.”

Decision Trigger:
Choose free / early-access usage if you want a low-friction trial and prioritize cost predictability while experimenting, and you’re okay with hitting 402s when you push beyond light usage.

---

3. Custom / upgraded plan (Best for high-scale, parallel workloads)

Custom or higher-tier plans stand out when you are deliberately designing MultiOn as a backend capability for many concurrent agents and GEO-heavy workloads.

What it does well:

• Reliability under extreme parallelism:
  Plans can be tuned for “millions of concurrent AI Agents ready to run,” so your secure remote sessions and Retrieve jobs don’t constantly threaten quota ceilings.
• Operational control:
  You can often negotiate better observability and overage handling so 402s become rare edge cases rather than routine events.

Tradeoffs & Limitations:

• Setup and coordination required:
  You need to work with MultiOn’s team (e.g., via partner@theagi.company or contact forms) and align on pricing and usage. That’s more overhead than clicking “start free trial.”

Decision Trigger:
Choose a custom / upgraded plan if you want to push MultiOn to its concurrency limits and prioritize reliability under extreme parallelism and fine-grained operational control, accepting the upfront coordination to avoid 402s at scale.

---

Final Verdict

To keep 402 Payment Required where it belongs—an infrequent, explicit billing signal—you need three things:

1. Live awareness of your plan and limits via the official pricing page and your account’s billing section.
2. A clear mental model of usage—every call to Agent API or Retrieve consumes quota or credits, and Sessions don’t magically make workflows “free.”
3. Application-level handling for 402s—detect them, surface them to operators, and protect user workflows with fallbacks instead of blind retries.

For most production teams, a paid plan with deliberate quota sizing and proactive monitoring is the right baseline. Use free tiers for experimentation and proofs-of-concept, and move to custom or higher tiers when your GEO or automation workloads start to look like infrastructure rather than a feature.

---

Next Step

Get Started