An API (application programming interface) may serve two buyers with opposite billing needs. One is a procurement team that wants an invoice, a spending limit, and a predictable monthly bill. The other is a software agent that may call your endpoint once today, twenty times tomorrow, and never again next week. The same subscription-versus-pay-per-request decision cannot serve those buyers equally well.
Subscription vs pay-per-request API pricing is a product decision shaped by request variance, buyer controls, support cost, and unit economics. A subscription sells predictable access or capacity over a period. Pay-per-request pricing charges for each accepted unit of work. Choose from p50 and p95 usage, retry rate, support cost, buyer controls, and unit economics.
Choose pay per request when usage is irregular and each request has a clear value. Choose a subscription when usage is predictable and administration is part of the product. Support both when agent calls and organizational usage need separate budgets, entitlements, and routing rules. Use the buyer break-even formula and seller cost ledger before publishing the price, because a low-looking unit price can be expensive to operate and a cheap subscription can be unattractive to a buyer with sparse usage.
The terms behind the pricing choice
An API is a network interface that lets one program request a defined operation from another program. An API request is not always a completed result. It can be rejected, accepted for background processing, retried, or completed later, so the pricing rule needs to say which event creates a charge.
A subscription is a recurring entitlement. The buyer pays for a period, quota, concurrency limit, or support level, and the seller decides what happens when the buyer exceeds it. The entitlement might be a monthly request allowance, priority execution, or access to a named model.
Pay per request means the bill is tied to an accepted unit of work. The unit could be an HTTP call, a job submission, a token range, a minute of execution, or an output artifact. The contract needs to define the unit precisely enough that a retry does not become an accidental second purchase.
x402 is an HTTP payment protocol. In the usual flow, a server returns HTTP 402 with payment requirements, a client signs a payment, and the server or a facilitator verifies the payment before the integration settles and fulfills the request. A facilitator is the service that checks a signed payment and can submit or complete settlement on the payment network. The current x402 flow describes the 402, signed retry, verification, settlement, and response sequence.
Tangle is a protocol for registering and coordinating services run by independent operators. A Blueprint is the deployable definition of one such service, including its jobs and operating rules. An operator is the service or organization that runs a Blueprint instance. A runtime is the process that loads the Blueprint, receives work, and produces results.
An agent profile is the declared behavior and permissions for an agent, such as which tools it may call, which budget it can spend, and which data it can access. A router is the component that chooses which endpoint or provider should receive a request. A trace is the chronological record of the request, payment, tool calls, retries, and result. An evaluation is a repeatable test of whether the agent or service produced an acceptable outcome. These terms matter because pricing changes all four records: the profile needs a spending rule, the router needs a price-aware choice, the trace needs payment state, and the evaluation needs to distinguish paid from completed.
An attestation is signed evidence from a trusted execution environment about the software or hardware that ran. A verified measurement can support a higher-priced confidentiality tier, but it does not turn a subscription into a quality guarantee. The Tangle TEE documentation describes attestation-backed execution as a separate capability.
Start with usage, not tiers
Build the first table from monthly volume, p50 and p95 usage, retries, execution time, and support cost rather than plan names. Record requests per buyer per month, request size, execution time, failure rate, support contacts, and the percentage of requests that are retried. The average is not enough. A sample buyer with 100 requests in one month and zero in the next may have the same average as a sample buyer with 50 requests every month, while needing a completely different product.
| Buyer pattern | Subscription pressure | Pay-per-request pressure | Main risk |
|---|---|---|---|
| Predictable daily batch | Strong | Moderate | The quota is too low during a seasonal spike |
| Occasional agent calls | Weak | Strong | Minimum subscription makes the service uneconomic |
| Large team with procurement | Strong | Weak | Finance needs invoices and account controls |
| Multiple short-lived agents | Weak | Strong | Each agent needs its own budget and identity |
| High-variance research workload | Mixed | Strong at first | A request price may be hard to predict |
| Confidential or priority execution | Strong for a tier | Possible surcharge | The buyer needs proof that the extra value exists |
Look at the tail as well as the center. If the sample p50 buyer sends 400 requests but the sample p95 buyer sends 30,000, a single included quota will either strand the light users or expose the seller to unlimited heavy usage. P50 means the median, or the middle observed buyer. P95 means the level that 95 percent of observed buyers do not exceed.
A simple break-even calculation
For a sample plan, suppose a service offers a 100-dollar monthly subscription and charges 0.03 dollars per request for a usage-based plan. Ignoring discounts and overages, the arithmetic break-even is:
sample subscription price / request price
= 100 / 0.03
= 3,333.33 requests per monthA sample buyer below roughly 3,334 requests pays less with usage-based billing. A sample buyer above that level pays less with the subscription. That is only the buyer’s arithmetic. The seller still needs to include compute, storage, payment fees, support, failed work, refunds, and the cost of keeping capacity available.
Now add a concrete workload. In this sample workload, 500 requests costs 15 dollars. In this sample workload, 5,000 requests costs 150 dollars. In this sample, the subscription saves the heavy user 50 dollars before any overage rule, while the light user avoids committing 100 dollars for capacity it did not use. The sample decision is concrete: 500 requests costs 15 dollars; 5,000 requests costs 150 dollars.
The seller’s calculation needs a different ledger:
gross contribution
= collected revenue
- execution cost
- payment and settlement fees
- support and account cost
- expected refunds and failed workIn this sample margin ledger, one request consumes 0.006 dollars of compute and the provider charges 0.03 dollars, so the sample raw request contribution is 0.024 dollars before fixed costs. If an x402 payment costs more to settle than the request itself, batching or a minimum charge may be necessary. If a subscription buyer sends a sudden burst, reserved capacity and queueing can erase the apparent margin.
Do not hide those effects in a vague “fair use” clause. State the included quota, overage unit, concurrency limit, maximum input, and behavior when the quota is exhausted. The buyer is choosing how much capacity to reserve and how much usage uncertainty to carry.
Tangle’s protocol models have a narrower scope
Tangle’s public pricing model distinguishes PayOnce, Subscription, and EventDriven service billing. PayOnce means a user pays up front when creating a service. Subscription means the service owner funds escrow and periodic billing. EventDriven means the job submitter pays per job. Those are protocol-level payment models. Invoices, seats, taxation, customer support, and cancellation screens remain application responsibilities.
This distinction prevents a common category error. A Tangle service can use the Subscription model for operator or service-level billing while the product exposes monthly plans to customers through its own account system. Conversely, a product can use pay-per-request customer pricing while its underlying service uses a different protocol model. The Tangle pricing and payments guide explains the current protocol models and their funding responsibilities.
An x402 route is another boundary. Tangle’s current gateway supports a per-job price map and can be configured with public-paid or restricted-paid invocation. The route can return a price for discovery, return 402 when payment is missing, and return 202 Accepted after a valid payment is settled and the job is enqueued. 202 means accepted for processing; it does not mean the result is ready. The Tangle x402 runner guide documents the health, price, payment, and authorization dry-run endpoints.
The customer promise should separate acceptance from completion: charge for an accepted invocation, then poll or receive the result under a stated completion policy. Use synchronous “pay and receive a result immediately” wording only when the runtime completes the job before responding.
A hybrid model needs one entitlement path
A hybrid product can give organizations a subscription and let software agents pay only for accepted invocations. Keep entitlement and payment decisions in one trace keyed by account and idempotency key while preserving their separate billing rules.
An illustrative authorization boundary might look like this. This TypeScript is application pseudocode, not a public Tangle SDK method.
type RequestContext = {
accountId: string
agentProfileId?: string
idempotencyKey: string
requestedUnits: number
}
type ChargeDecision =
| { mode: 'subscription'; remainingUnits: number }
| { mode: 'pay-per-request'; amount: string; paymentId: string }
| { mode: 'reject'; reason: string }
function authorize(context: RequestContext): ChargeDecision {
if (hasRemainingEntitlement(context.accountId, context.requestedUnits)) {
return {
mode: 'subscription',
remainingUnits: remainingAfterReservation(context)
}
}
return createOrRecoverPayment(context)
}The important properties are the reservation and the idempotency key. An idempotency key is a stable request token that tells the service a retry belongs to an earlier attempt. Reserve subscription units before dispatching work, and make a repeated request with the same key return the original decision. Otherwise a network timeout can make one user pay twice or consume the same quota twice.
The trace should record the decision alongside the final result:
| Trace event | Example fact |
|---|---|
| Request received | Account, agent profile, request identifier |
| Entitlement checked | 120 units available before reservation |
| Charge selected | Subscription reservation or x402 payment |
| Work accepted | Runtime queued job 7842 |
| Work completed | Result hash and completion timestamp |
| Usage settled | 1 unit consumed or payment reference attached |
An evaluation should test the whole sequence. One test can check that a subscription request consumes exactly one reserved unit. Another can send the same idempotency key after a simulated timeout. Another can verify that a 402 payment followed by an accepted 202 is not reported as a completed result. Pricing is part of observable behavior, not a wrapper around the API.
How to choose the product boundary
Choose a subscription when the buyer values continuity. That includes stable access, team administration, invoice terms, reserved capacity, a support relationship, or predictable budgeting. The plan should name the entitlement that creates that value; a request-price discount alone is not enough.
Choose pay per request when the buyer values optionality. That includes one-off automation, dynamic routing, short-lived agents, experimentation, or workloads whose volume cannot be forecast. x402 is particularly useful when the payer is software and an HTTP 402 response can carry the information needed for the next signed payment.
Choose a hybrid when the customer populations are real and distinct. Do not create a second payment path merely because it sounds flexible. Each path adds retries, reconciliation, support cases, and tests. The hybrid is justified when the subscription solves organizational needs that a wallet cannot solve and the per-request path solves machine-to-machine usage that a monthly contract cannot.
Failure cases to price explicitly
Retries are the first failure case. If the server completes work but the client misses the response, the retry must be able to find the original result. Charge on a stable acceptance event, use an idempotency key, and document whether a failed execution is refunded or retried at no charge.
Quota exhaustion is the second. A subscription can reject new work, permit overages, or downgrade priority. Those behaviors change the product, so they belong in the plan description and in automated tests.
Usage spikes are the third. A pay-per-request seller can exhaust one operator’s capacity when a router sends a sudden burst. Set concurrency and rate limits, and ensure that the agent profile contains a budget and a maximum request size. The router should choose an allowed endpoint using current price and capacity, not choose the cheapest endpoint and discover its limits after payment.
Refunds and settlement failures need their own records. An on-chain payment that settles is not automatically a successful computation. A subscription invoice that is paid is not evidence that every included request completed. Keep payment identifiers, job identifiers, result identifiers, and refund decisions linked in the trace.
Finally, confidentiality can change the price. If a workload runs in a trusted execution environment and produces an attestation, that evidence may justify a separate tier. The attestation still needs an independent checker, a policy for acceptable measurements, and a response to missing or stale evidence. Do not charge for a security property that the buyer cannot inspect.
A practical launch sequence
Start with one measurable unit of work. Publish its input limits, completion state, retry behavior, and price. Collect at least a small real usage sample before setting included quotas, and report the p50, p95, and maximum observed usage rather than only the average.
Next, implement one payment ledger that can represent both entitlement reservations and per-request payments. Link every charge to an idempotency key and every result to a job identifier. Add an evaluation for duplicate requests, missing results, quota exhaustion, and payment acceptance without completion.
Test the route an agent will use. For x402, verify the 402 response, signed retry, settlement response, and asynchronous status path. For subscriptions, verify quota reservation, invoice state, cancellation, and overage behavior. For both, inspect the trace after a timeout rather than assuming the client saw the last response.
The pay-per-request pricing guide covers the wei-to-token calculation behind one request. The x402 payment guide covers the HTTP challenge and settlement boundary.
Choose commitment or optionality
Subscription vs pay-per-request API pricing is a choice between commitment and optionality. The subscription earns its place by providing predictable capacity, administration, or support. Pay per request earns its place by making irregular usage easy to start and easy to stop.
A durable implementation treats billing as part of the service state: the request has an identity, the charge has a clear trigger, the runtime reports acceptance separately from completion, and the trace makes reconciliation possible. Once those facts are explicit, offering both models is a manageable product choice rather than a pair of disconnected price pages.
Is a subscription always cheaper for heavy users?
No. Compare the included quota, overage price, concurrency limit, support cost, and burst behavior. A low monthly price can become expensive if heavy usage is charged through punitive overages.
Is pay per request the same as x402?
No. Pay per request is a pricing rule. x402 is one protocol for communicating and settling an HTTP payment. A service can charge per request through another billing system, and an x402 route can represent a job that completes asynchronously.
Should a subscription request still have an idempotency key?
Yes. The key prevents a timeout or retry from consuming the same entitlement twice and helps the client find the original result.
Does Tangle’s Subscription model create customer SaaS subscriptions?
Not by itself. It describes a protocol-level funding model for a service. Customer plans, seats, invoices, taxes, cancellation, and support remain application responsibilities.
When should a machine agent use a subscription?
Use one when the agent has predictable recurring volume, needs reserved capacity, or operates inside an account with a budget administrator. Use pay per request when its demand is sparse or it needs to select among providers dynamically. For the operator-selection and accountability boundary that follows pricing, continue with on-chain RFQ job quotes.