API Pricing: Subscription vs Pay Per Request

Choose pay-per-request API pricing when usage is irregular, the buyer is software, and each request has a clear value and cost. Choose a subscription when usage is predictable, the buyer needs invoices or team administration, and a recurring commitment creates value for both sides. Support both when individual agents and larger organizations use the same service.

The pricing label is not the decision by itself. Model request cost, support cost, payment fees, failure and refund rates, usage distribution, and the price a buyer will accept before selecting a billing path.

Quick Decision Table

Dimension	Pay per request	Subscription	Hybrid
Best buyer	Agent, script, occasional developer	Team, company, frequent user	Mixed customer base
Best usage	Irregular or low-frequency	Predictable and repeated	Long tail plus high-volume accounts
Cost certainty for buyer	Low unless the client sets budgets	High within plan limits	High for subscribers, exact for occasional calls
Revenue predictability	Follows usage	Recurs until cancellation	Recurring base plus usage revenue
Billing work	Metering and per-call payment or ledger	Accounts, plans, invoices, limits, and lifecycle events	Both systems plus one authorization model
Request latency	May include a payment round trip or settlement	Usually checked against prepaid entitlement	Depends on buyer path
Identity	Can be wallet- or request-based	Usually account and organization based	Supports both
Main risk	Too little volume or too much payment friction	Heavy users exceed the price’s cost assumptions	Duplicated rules and inconsistent entitlements

When Pay Per Request Wins

Pay per request fits a service with a discrete unit of work: one model call, browser task, document conversion, code analysis, quote, image, or sandbox job.

It is strongest when:

• the buyer cannot predict monthly usage;
• the client is an agent that can respond to price programmatically;
• a request is valuable enough to absorb payment processing time and fees;
• the operator can estimate or cap the cost of each request;
• buyers do not need seats, invoices, negotiated terms, or a shared account;
• the service can return a receipt tied to one result.

Per-request pricing still needs operations. The service must prevent duplicate charges, track payment state, handle a paid request that fails, support refunds or credits where promised, and reconcile the payment to the delivered job.

When Subscription Wins

A subscription fits repeated usage where the buyer values budget certainty and the seller can estimate the distribution of usage across accounts.

It is strongest when:

• teams need shared access and permissions;
• procurement needs card billing, invoices, tax records, or a contract;
• the product has recurring value beyond raw request volume;
• usage limits and overage rules can be explained before purchase;
• customer support and retention justify maintaining account state;
• the seller has enough usage history to avoid systematically underpricing heavy accounts.

Subscriptions do not remove metering. Even an unlimited plan needs abuse controls, capacity planning, and a way to know whether a small group of accounts consumes most of the infrastructure.

Calculate the Break-Even Point

Start with contribution margin per account, not competitor plan names.

For pay per request:

monthly margin
= request count × (price per request - variable cost per request)
- payment fees
- support and refund cost

For a subscription:

monthly margin
= plan price
- included usage × variable cost per unit
- payment fees
- account support cost

The break-even request count for a buyer is approximately:

subscription price / pay-per-request price

If a plan costs $100 and the same work costs $0.02 per request, the simple buyer break-even is 5,000 requests per month. That is a hypothetical example, not a Tangle price. The seller’s break-even must also include compute, model tokens, storage, network calls, payment fees, retries, and support.

Use percentiles rather than the average account. At minimum, calculate monthly requests and contribution margin for the median, 90th percentile, and maximum active account. Averages can hide a small number of accounts that make an apparently profitable subscription lose money.

Price the Unit Buyers Understand

The best billing unit matches the result the buyer is trying to purchase.

Service	Clearer unit	Risky unit
Model routing	input and output tokens, or completed response	internal routing attempts
Browser automation	completed task with a defined time limit	every browser action
Sandbox compute	second, minute, or reserved capacity	opaque credits with no conversion
Code analysis	repository or bounded changed-file run	every internal model call
Document processing	page, document, or extracted field set	background worker time

When internal cost and buyer value use different units, expose the buyer-facing unit and meter the internal cost separately. Do not force customers to understand your infrastructure architecture to predict a bill.

x402 for Per-Request Payments

x402 gives a paid HTTP endpoint a standard challenge and retry flow. The server returns 402 Payment Required, the client signs a payment payload, and the server verifies and settles it before returning the resource.

In x402 v2, the main headers are PAYMENT-REQUIRED, PAYMENT-SIGNATURE, and PAYMENT-RESPONSE. That path can reduce account and API-key work for wallet-based buyers, but it adds wallet policy, settlement, idempotency, receipt, and failure-state requirements.

Use x402 when those tradeoffs fit the buyer. Do not add it to a human team product merely because HTTP 402 is available.

Tangle Blueprint Pricing Primitives

Tangle’s public Blueprint repository separates pricing from job execution. At commit 00c3cae, the pricing engine defines three models:

PAY_ONCE = 0;
SUBSCRIPTION = 1;
EVENT_DRIVEN = 2;

The pricing engine source calculates model-specific quotes. The separate blueprint-x402 crate exposes paid HTTP jobs and converts verified payments into the runner’s job-call stream.

This separation is useful because payment methods can converge on the same service handler:

x402 payment ------\
                    -> authorization -> job router -> job handler -> receipt
subscription ------/

The handler should receive the same typed job whether the buyer paid for one request or used a subscription entitlement. Authentication, payment, and job execution remain separate decisions.

Current implementation details to plan around include:

• x402 jobs are disabled until an operator explicitly enables a paid access policy;
• restricted paid jobs require both payment and the configured caller policy;
• the x402 quote registry is in memory, so outstanding quotes do not survive a process restart;
• operators configure accepted tokens, conversion rates, quote lifetime, and markup;
• pricing configuration is not a full customer billing system with invoices, refunds, tax, and subscription lifecycle management.

How to Support Both Without Duplicating the Product

Keep one entitlement result between billing and execution:

authorize(request) -> {
  customer_or_wallet,
  service,
  limits,
  payment_or_plan_reference,
  idempotency_key
}

The pay-per-request path creates that result from a settled payment. The subscription path creates it from an active account, plan, and usage allowance. The downstream job router consumes the same shape.

This avoids two common failures:

1. Different customers receive different service behavior because each billing path has its own handler.
2. A payment check accidentally becomes an authorization check for private data or administrative actions.

Before You Publish Prices

Answer these questions with current measurements:

1. What is the variable cost distribution for one successful request?
2. How much do retries, failures, and abandoned jobs add?
3. What are monthly requests per active account at the median, 90th percentile, and maximum?
4. Which buyers require invoices, refunds, purchase orders, or service commitments?
5. How long does payment add to the request path on every supported network?
6. Can the service prove which result belongs to each charge?
7. What happens when payment succeeds but execution fails?
8. What limit protects the seller from one heavy subscription account?
9. What budget protects an autonomous buyer from repeated calls?
10. Which price and policy changes require notice to existing customers?

If these values are unknown, launch with a capped pilot and collect them before promising unlimited usage or permanent unit prices.

FAQ

Is pay per request cheaper than a subscription?

It depends on usage. Divide the subscription price by the per-request price to estimate the buyer’s request-count break-even, then include overages, fees, and any minimum commitment.

Which model is better for AI agents?

Pay per request often fits agents because software can inspect a price and buy one capability without a conventional account. Subscriptions fit long-running agents with predictable usage or teams that need centralized budgets and administration.

Can one API support both models?

Yes. Convert a settled payment or an active subscription into the same entitlement record, then route both to the same job handler.

What should a subscription include?

State the billing interval, included usage, overage price, concurrency, rate limit, support level, cancellation timing, refund policy, and what happens to unused allowance.

What should a pay-per-request response include?

Return or retain the amount, asset, recipient, network, settlement reference, idempotency key, job identifier, and result evidence needed to reconcile the charge with the work.