Per-Request Pricing: Examples & Companies

What is it

Per-Request Pricing is a billing unit where customers are charged per request served — the generic meter for inference endpoints, search, scraping, and browser infrastructure. Whatever the product does — answer a search, scrape a page, run a model, write a memory — the request is the countable thing that crosses the API boundary, and the bill is request volume times a published rate.

The purest living expression is Linkup — a web search API with no seats and no tiers, just $0.005 per standard search and $0.05 per deep search, plus an x402 mode that bills a flat $0.01 per request in USDC on Base with no account at all. MultiOn once priced one web action as one request just as cleanly, before its unit economics unraveled (a cautionary tale below).

Because the per-request price is almost always sub-cent, vendors quote per 1,000 to stay legible: Exa lists its Search API at $7 per 1,000 requests (about $0.007 a call), You.com meters Search at $5.00 per 1,000 calls, Browserbase prices Search overage at $7 per 1,000 requests, and Cohere bills its Rerank API at $2 per 1,000 queries. The headline unit shrinks to a readable figure while the meter underneath stays strictly one-per-call.

The recurring tension is that requests vary wildly in cost to serve. A cached lookup and an exhaustive research run are both “one request,” so nearly every mature per-request rate card layers something on top — effort modes, feature multipliers, request-size bands, or success-only metering. How those layers work is the real story of this unit, and it’s the difference between a $7 headline and a bill several times larger.

How it works

The base formula is bill = requests × rate. The design work is in the levers vendors stack on it to keep one meter honest when requests aren’t uniform in cost:

Worked example — agent search budget. An agent product on Linkup runs 100,000 standard searches a month at $0.005 each: $500. Upgrade every call to sourced-answer output at $0.006 and the same volume costs $600. Route 5% of traffic (5,000 calls) to deep search at $0.05 and that slice alone adds $250 — half the original budget for one-twentieth of the volume. The formula never changed; the per-request rate did, by mode.

Worked example — multiplier math. On ZenRows, the Universal Scraper API meters per 1,000 successful requests with multipliers of 5x for JavaScript rendering, 10x for premium proxies, and 25x for both. A 50,000-request job against a protected, JS-heavy target therefore consumes the balance of a 1,250,000-plain-request job. Failed and retried calls don’t draw down the balance at all — but HTTP 404/410 responses count as successful completions, a detail worth reading twice before pointing a crawler at dead links.

Worked example — quota ladder instead of a rate. Mem0 never publishes a per-request price. Instead, each tier carries two request quotas: add requests scale 10,000 → 50,000 → 200,000 → 500,000 and retrieval requests 1,000 → 5,000 → 20,000 → 50,000 across Hobby (free), Starter ($19), Growth ($79), and Pro ($249). The lever buyers actually pull is the tier, not the meter. Helicone (10,000 free requests/month on the Hobby tier, then usage-based overage) and Portkey (Production at $49/month for 100,000 logged requests, then $9 per additional 100K up to 3M) run the same quota-first pattern. For how these meters get counted in the first place, see the tracking and metering usage events guide.

Companies using this

42 in-corpus companies meter requests, making it one of the most widely shared billing units in the corpus. The cluster spans five categories — search APIs (SerpApi, Tavily, Linkup, You.com, Exa), web data and scraping (Bright Data, Oxylabs, ZenRows, ScraperAPI), browser and agent infrastructure (Browserbase, MultiOn), LLM observability and memory (Helicone, Portkey, PromptLayer, Mem0), and inference or serving platforms where requests ride alongside tokens (Cohere, Baseten, Groq, Fireworks AI, DeepInfra, Replicate, Perplexity).

Patterns observed

• Per-1k quoting is the house style. Exa ($7/1k Search requests), You.com ($5.00/1k Search calls), Browserbase ($7/1k Search, $1/1k Fetch, $4–$7/1k Extract), Bright Data ($1.50/1k Web Unlocker results), Cohere ($2/1k Rerank queries), and Twelve Labs ($4/1k search queries) all normalize sub-cent request prices into per-1,000 figures. The meter is per-request; only the display unit is scaled.

• Effort bands absorb cost variance without abandoning the unit. You.com prices Research requests at $12 / $50 / $100 / $450 per 1,000 by effort tier (lite → exhaustive), Linkup charges 10x for deep search over standard, Exa splits Search ($7/1k) from Deep Search ($12–15/1k) and an Agent endpoint that runs $0.025 to $2.00 per run by fixed-effort mode, and SerpApi prices enterprise overage by speed mode ($7.50 / $15 / $30 per 1,000 on-demand). The request stays the unit; the band prices what’s behind it.

• Multiplier systems are the scraping category’s answer to the same problem. ZenRows and ScraperAPI both charge heavy requests more while keeping one balance, scaling by rendering, proxy class, and target difficulty. Qodo applies the identical idea to model choice: most LLM requests cost 1 credit, Grok 4 costs 4, and Claude Opus costs 5 — the request stays the unit while the model behind it sets the weight.

• Success-only metering is becoming table stakes where failure is common. SerpApi bills only fully successful searches — blocked, errored, and CAPTCHA’d responses are free — Oxylabs doesn’t charge for 5xx/6xx scraper attempts, ZenRows draws balance only on successful results, and Linkup deducts no credit when a request errors. In scraping and search, where block rates are a fact of life, charging per delivered result rather than per attempt is now a competitive requirement.

• Quota gates outnumber published rates. Many vendors use requests as tier boundaries rather than priced units: Helicone’s 10K free requests, Portkey’s 100K-log allotment, OpenRouter’s 1M free BYOK requests per month (then a 5% fee), and GitHub Copilot’s premium-request allowances that became AI Credits at $0.01 each. The request is the meter even when no per-request price appears on the page.

• Read and write requests are splitting into separate meters. Mem0 prices add requests and retrieval requests on independent quota ladders, and Pinecone separates read units from write units entirely. Once a platform’s read and write costs diverge, a single undifferentiated request meter stops working — the same pressure that pushes vendors from a flat request price toward request-size pricing.

Counterexamples & variants

The cautionary tale is MultiOn. Its Agent API defined one request as roughly one action taken on a webpage — an honest unit, but one whose unit economics never stabilized: the price halved from $0.08 to $0.04 within about five weeks of public beta, a Premium tier needed a $50,000/year minimum to make the lower $0.025 rate viable, and an extraction-only Retrieve endpoint had to be split out at $0.01 because lumping it with full agent actions overpriced it. MultiOn pivoted to consumer in December 2024 (rebranded Please) and the API wound down — a reminder that per-request pricing only works when the vendor actually knows what a request costs to serve.

The second counterexample is the databases that outgrew the unit. Pinecone nominally lists requests as a meter, but its real units are read units and write units: a query consumes roughly 1 RU per GB of namespace size (minimum 0.25 RU), and a write consumes 1 WU per KB (minimum 5 WU per request). Two identical API calls against differently-sized indexes cost wildly different amounts — the “request” survives only as a minimum-charge floor. turbopuffer made the same move explicit by pricing queries per unit of data scanned, then cutting that base rate from $5 to $1 per petabyte in February 2026 — an up-to-94% reduction for large namespaces. When request cost scales with state size rather than call count, vendors migrate to request-size pricing and the flat per-request model quietly dies.

The third group is the inference platforms — OpenAI, Groq, Fireworks AI, Google Gemini, Baseten, DeepInfra, Replicate — which record requests but run their economics on tokens or compute seconds; the request count is incidental, and those vendors belong to the token-based pricing story. The interesting hybrid is Perplexity’s Sonar API, which charges per-token rates plus a per-request search fee ($5–$14 per 1,000 requests depending on search-context depth, e.g. $10 per 1,000 medium-context on Sonar Pro) — the request fee prices the retrieval work that tokens can’t see, the mirror image of a database charging by state size.

What this means for buyers vs vendors

For buyers

Start by finding out what one request actually costs for your workload, not the headline rate. The published number is usually the cheapest request on the card: on ZenRows a protected JS-heavy target costs 25x the plain rate, on You.com an exhaustive Research call costs 37x a lite one, on Exa returning more than 10 results adds a per-additional-result surcharge, and on Pinecone the same query gets more expensive as your index grows.

Ask three questions in procurement. First, which request types and multipliers will my traffic actually hit — the effort mode, the render flag, the proxy class? Second, are failed requests billed? On SerpApi, Oxylabs, and Linkup they aren’t; on most inference and search APIs they are, and retries at scale can quietly double a bill. Third, is there a budget cap or alert — like Upstash’s hard monthly ceiling that rate-limits pay-as-you-go databases with email alerts at 70% and 90% of budget — or does the meter run unbounded until you notice?

Then model your real request mix before committing to a tier. Quota-gated plans like Mem0’s punish misestimating which of the two request meters — reads or writes — you’ll exhaust first, and a plan that’s generous on adds can strangle you on retrievals. Our pricing calculator hub lets you sketch a monthly bill from request volume, effort mix, and included quotas before you sign, and the choosing the right usage metric guide covers when a raw request count is even the right thing to be paying for.

For vendors

Per-request pricing earns you the fastest quote-to-forecast path in usage-based pricing — a developer can budget in seconds and a request count is trivial to explain — but only if your cost to serve a request is roughly uniform. When it isn’t, the corpus shows three proven ways to keep the unit rather than abandon it: effort bands (You.com, Linkup, Exa), feature multipliers on a single balance (ZenRows, ScraperAPI), and read/write meter splits (Mem0, Pinecone).

If you’re in a category with real failure rates, bill successful requests only. Charge-on-success is now the trust baseline in web data, and billing for blocked attempts reads as a red flag to any buyer who has compared rate cards. In search and agent APIs the same logic holds — agents retry constantly, and surprise charges for their failures erode confidence fast.

Above all, price the unit before you launch it, not after: MultiOn’s scramble to reprice in production preceded its wind-down, and it is what discovering your serving cost too late looks like. The tracking and metering usage events guide covers the pipeline you’ll need to count requests defensibly, and the pricing calculator hub is a fast way to pressure-test whether your proposed rate survives a realistic request mix before it hits a customer’s invoice.

Explore this theme in the knowledge graph →