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

Most teams find MultiOn pricing straightforward once they know where to look and what the platform considers “paid usage.” The key signals live in two places: the public pricing page (for high-level tiers and limits) and your API responses (for real‑time usage enforcement, including 402 Payment Required).

Below I’ll walk through how to see current tiers/limits, how usage is enforced at the API level, and what typically triggers a 402 in production.

Note: MultiOn pricing, billing, and limits can change over time. Always defer to the live docs and dashboard for the latest terms. This guide explains how to find and interpret them, not to restate them verbatim.

Where to see current MultiOn pricing tiers and limits

You have three main views into pricing and limits:

Public pricing page – high-level tiers and inclusions
Dashboard / account billing – your plan, quota, and usage
API‑level responses – real‑time enforcement (including 402 Payment Required)

1. Public pricing page (current tiers, high‑level limits)

Start with the pricing page on the MultiOn site:

Open https://multion.ai in a browser.
Navigate to the Pricing section (usually linked in the top nav or footer).

From here you can typically see:

Plan names (e.g., Free/Starter, Pro, Enterprise)
Included usage (e.g., number of agent runs, Retrieve calls, or similar units)
Overage or pay‑as‑you‑go terms where applicable
Feature access by plan:
- Agent API (V1 Beta) usage
- Retrieve function access
- Sessions + Step mode limits
- Parallel agents / concurrency caps

Use this page to decide which tier maps to how you plan to run browser‑operating AI agents:

High‑volume Amazon checkout flows → look for higher concurrency and usage.
Data‑heavy H&M catalog extraction using Retrieve → look for limits tied to extraction calls or page renders.
Frequent social posting (e.g., posting on X) → check how many browser sessions / steps are included.

2. Dashboard or account billing (your specific limits)

Once you’ve picked a plan, the dashboard is the source of truth for your current limits.

Typical items you’ll see in a dashboard/billing area include:

Current plan (name and renewal interval)
Usage to date (e.g., calls, sessions, or credits used in the current period)
Remaining quota before you hit a hard stop or overage
Billing details – payment method, invoices, next renewal date

This matches the billing model outlined in the terms:

You provide complete and accurate billing information.
For paid subscriptions, your payment method is charged automatically on each renewal until you cancel.
If payment cannot be completed, MultiOn may downgrade or suspend your account until payment is received.

If you’re driving agents from CI/CD or a backend worker pool, set up an internal alert when:

Your usage approaches a defined percentage of quota (e.g., 80–90%).
You receive API responses signaling quota exhaustion or payment issues.

3. API responses and headers (real‑time enforcement)

The most precise indication of your current status is what the API tells you at request time.

When you call endpoints like:

POST https://api.multion.ai/v1/web/browse (Agent API V1 Beta)
Retrieve endpoints for structured JSON extraction

…you should watch for:

HTTP status codes (especially 4xx for client/usage issues)
Error payloads describing the problem
Any rate‑limit or quota headers (if exposed), which tell you remaining allowance

A healthy, authorized call with adequate quota runs the requested browser workflow and returns:

A session_id you can reuse in Sessions + Step mode for continuity (e.g., Amazon add‑to‑cart → checkout).
Output content (HTML snapshot, state, or structured JSON from Retrieve).

If you’re over quota or payment‑blocked, you’ll start seeing 402 Payment Required or similar enforcement responses.

What a 402 Payment Required means in MultiOn

Within MultiOn, 402 Payment Required is a first‑class signal that the platform expects payment before it will continue executing your requests at the current level of usage.

You’ll see it in contexts like:

You’ve exceeded your included quota on a tier and don’t have credits or a pay‑as‑you‑go configuration in place.
Your payment method failed, and your account is now in a suspended or downgraded state.
You’re on a trial or promotional tier and have passed whatever usage threshold that trial allows.

The terms make this logic explicit:

If your payment cannot be completed, MultiOn may downgrade your account or suspend your access to Services until payment is received.
Some Services can be paid in advance via service credits, which are consumed as you use the platform.
Payments are non‑refundable except where required by law.

Typical triggers for 402 in real workloads

From an implementation standpoint, patterns that often trigger 402 include:

Unbounded parallelization without plan alignment
Example: you spin up “infinite scalability with parallel agents” in code—hundreds or thousands of concurrent calls to POST /v1/web/browse—without increasing your plan or buying service credits. Once your included quota is exhausted, subsequent requests can return 402.
Long‑running test suites promoted to production volume
Example: you start with a light harness—maybe a handful of Amazon or X workflows—and later expand to a 24/7 automation cluster without updating billing. The usage curve spikes and you hit an enforced limit.
Forgotten or expired payment method
Example: card on file expires. The next scheduled renewal fails. MultiOn attempts to bill, fails, and your account transitions into a state where further paid usage returns 402 until the payment method is updated.
Over‑usage on fixed‑credit models
Example: you pre‑purchase service credits, run a large Retrieve‑heavy scrape (e.g., full H&M catalog with renderJs=true and scrollToBottom=true), and consume credits faster than expected. Another batch of calls crosses the credit boundary and starts returning 402.

How to detect and handle 402 Payment Required in code

Treat 402 as a hard stop for paid usage and handle it explicitly.

1. Detect 402 from your HTTP client

Example in pseudo‑Node:

import axios from "axios";

async function runAgentStep(sessionId?: string) {
  try {
    const res = await axios.post(
      "https://api.multion.ai/v1/web/browse",
      {
        url: "https://www.amazon.com",
        cmd: "search for 'usb c charger' and add the top result to cart",
        session_id: sessionId,
      },
      {
        headers: {
          "X_MULTION_API_KEY": process.env.MULTION_API_KEY!,
          "Content-Type": "application/json",
        },
      },
    );

    return res.data; // includes session_id for continuity
  } catch (err: any) {
    if (axios.isAxiosError(err) && err.response) {
      if (err.response.status === 402) {
        // MultiOn is telling you payment or credits are required.
        throw new Error("MultiOn 402 Payment Required: check plan, credits, or billing method.");
      }
    }
    throw err;
  }
}

2. Add operational handling around 402

When you detect 402:

Stop retrying automatically. This is not a transient network issue; it’s a billing/limit state.
Alert your team. Pipe this into your monitoring stack (PagerDuty/Slack/etc.) with:
- The tenant/app affected
- The endpoint called (e.g., /v1/web/browse)
- A correlation ID or request metadata for debugging
Check your MultiOn dashboard. Look at:
- Current plan and whether your subscription is active
- Credits remaining (if applicable)
- Any indications of payment failure

3. Decide the right user-facing behavior

For applications that embed MultiOn:

Internal tools / backoffice systems:
Show an explicit message: “Automation backend is currently paused due to MultiOn billing limits. Please contact the platform team.”
End‑user‑facing apps:
Fail the request with a clear but generic message (“Automation temporarily unavailable”), and internally log that the root cause was a 402 from MultiOn.

How service credits interact with 402

MultiOn allows some Services to be prepaid via service credits. These credits behave like a fuel tank:

When credits are available, your usage consumes them as you run agents and Retrieve flows.
Once credits are exhausted:
- If you have a fallback paid subscription with a valid payment method, usage may continue on that subscription.
- If you don’t, or if payment fails, MultiOn can return 402 Payment Required for additional requests.

To avoid unexpected 402s in high‑volume builds:

Monitor credit balance. Treat your credit pool like any other resource quota.
Align concurrency with balance. If you’re launching “millions of concurrent AI Agents,” ensure your credits are sized for peak load, not just the average.

How plan changes and cancellations affect limits

From the terms:

Price changes: If MultiOn increases subscription prices, you get at least 30 days’ notice, and the new price applies at the next renewal. You can cancel if you don’t agree with the new price.
Cancellation: You can cancel at any time, but:
- Payments are non‑refundable (except where local law requires).
- Once canceled or downgraded, you may lose access to higher limits.
Post‑cancellation: If you keep your automation code running without a compatible plan:
- Expect 402 Payment Required or other access errors once the existing period or credits end.

For teams moving from evaluation to production:

Audit your workflows: Count how many Agent API calls a full run generates (e.g., an Amazon purchase flow might be 3–8 step calls with session_id continuity).
Multiply by concurrency: Factor in how many users or jobs you run in parallel.
Pick a plan + credits that comfortably covers this profile, with headroom.

Practical checklist for staying ahead of 402 Payment Required

To keep your browser‑operating agents and Retrieve flows running smoothly:

Before launch
- Review the MultiOn pricing page for current tiers and limits.
- Map your expected call volume and concurrency to a specific plan.
- Decide whether you need service credits for bursty workloads.
During integration
- Implement explicit checks for 402 Payment Required in your HTTP client.
- Add monitoring and alerts on 4xx responses, especially 402 and any quota–related error payloads.
In production
- Watch your dashboard for usage against quota.
- Keep your payment method current to avoid silent failures at renewal.
- If you plan a one‑off spike (e.g., large Retrieve job across many pages), pre‑purchase credits or temporarily increase your plan.

Summary

You see current tiers and limits on the public pricing page and inside your account’s dashboard/billing view.
MultiOn enforces usage at the API layer; a 402 Payment Required means your request is blocked until you resolve billing or quota (plan upgrade, credits, or payment method).
Handle 402 explicitly in your code, treat it as a billing/limits signal (not a transient error), and use dashboard metrics plus service credits to keep your Agent API and Retrieve workloads running without surprise stops.

To start building against the current pricing model and see how limits behave with your actual workflows, you can sign up and integrate directly with the Agent API and Retrieve, then monitor the responses and dashboard as you scale.

Next Step

Get Started