← All guides · Selling to AI agents

Pricing Tiers for API and Corpus Access: What Actually Varies Between Them

Part 6 of Selling to AI agents · 1,599 words · published 2026-08-02 · updated 2026-08-02 · Markdown variant

The axes that actually distinguish one pricing tier from another for a machine buyer — rate limits, content scope, deliverables and license grant — and how ChangeGamer structures its own four tiers around deliverable and license, not gated content.

Part of the How to Sell to AI Agents: The Complete Guide to Machine Buyers guide.

A pricing tier for a machine buyer can vary on five axes, and picking which of them actually move between your tiers — rather than defaulting to "more of everything" at each price point — is the real design decision. This is the tiering companion to how to sell to AI agents, the pillar for this cluster: that guide covers discovering, evaluating, authorizing and paying; this article is about what should differ once a buyer has picked a tier to pay for.

The five axes a tier can vary on

A tier ladder for API or corpus access can differentiate buyers along rate limit, content/corpus scope, SLA, license grant, or deliverable timing — and a coherent ladder does not need to vary all five. Treat each as an independent knob, not a bundle that automatically moves together:

• Rate limit. Requests per minute, per day, or a token/credit budget consumed per call. This is the axis most API pricing pages default to, because it maps directly to infrastructure cost — but it is only relevant if your system actually enforces per-key limits. Advertising a rate-limit tier your infrastructure does not enforce is worse than not offering the axis at all.
• Content or corpus scope. Which resources, endpoints, or slices of a dataset a key can reach. A "basic" tier that unlocks three endpoints and a "pro" tier that unlocks all of them is scope-based tiering, and it is the most legible axis to a buyer comparing offers, because it is a yes/no question per resource.
• SLA. Uptime commitments, response-time guarantees, and support channel — a support ticket queue versus a named contact. This axis matters most to buyers with their own uptime commitments downstream, and it is close to meaningless to a one-shot agent buyer that just needs the data once.
• License grant. What the buyer is legally permitted to do with what they receive — internal use only, AI training, commercial embedding, redistribution. This axis is easy to overlook because it costs the seller nothing incremental to grant, but it is frequently the axis a buyer with a legal department cares about most, and gating on it alone (without touching content or rate limit) is a legitimate, low-infrastructure-cost way to build a tier ladder.
• Deliverable timing and form. Instant self-serve key versus an emailed file within a business day versus a pull-on-demand endpoint. A buyer evaluating whether a purchase can complete inside one session needs this as much as the price.

None of these axes is mandatory, and a tier that varies only license grant — leaving rate limit, scope and SLA untouched — is still a real tier, provided the license difference is legally meaningful and clearly stated. What is not defensible is a tier ladder that implies a difference on an axis your system does not actually enforce.

How a buyer finds out what a tier includes before paying

A machine buyer compares tiers by fetching a structured catalog, not by reading a pricing page written in prose — the mechanism, the field list, and the build-time guarantee that keep that catalog honest are covered in full in machine-readable pricing pages and are not repeated here. The short version relevant to tier design: whatever axes you pick from the list above have to show up as discrete, parseable fields in that catalog — a rate_limit field if you vary rate limit, a license field if you vary license grant — or the axis is invisible to the buyer deciding whether to pay, regardless of how real the difference is on your side.

ChangeGamer's own tiers: what changes, and what stays constant

ChangeGamer runs four paid tiers, and as of this writing all four unlock the identical premium resource set — they differ in deliverable and license grant, not in gated content or rate limit. That is worth stating plainly because it runs against the default assumption that a higher tier means more access to more things:

The premium resource set every tier unlocks — data-formats, json-api, autonomous-operations — and the full deliverable and license wording for each tier live in access and pricing for crawlers; this article is not restating that reference, only naming the design pattern it embodies: gate on deliverable and license, hold content and rate limit constant. That is a deliberate, defensible structure for a seller whose marginal cost of serving one more premium resource to an already-paying key is close to zero, and whose real differentiator is what the buyer is legally allowed to do with the material, not how much of it they can see.

It is also worth naming what this structure does not do. ChangeGamer's worker does not implement per-key rate limiting on top of the tier check today — a gap already documented in issuing API keys to AI agents automatically — so rate limit is not an axis in play here at all, by omission rather than design. A seller copying this deliverable-and-license pattern should decide deliberately whether rate limit belongs in their own ladder, not assume its absence here is a recommendation.

Same rank, different billing: corpus vs. corpus_annual

Two tiers can occupy the same access rank while differing in price and renewal cadence, and ChangeGamer's own tier table is a working example: corpus and corpus_annual both rank 2 in TIER_RANK, tied with each other and below enterprise at rank 3, with starter at rank 1 (src/data/tiers.ts). A key minted under either tier passes the exact same tierAllows() check against gated resources — the annual tier is not a lesser or provisional version of the one-time Corpus license sitting between it and Enterprise. What the annual tier buys instead is a standing renewal: the full corpus file is re-sent at each yearly renewal so it always reflects the current premium resource set, where the one-time Corpus license's license grant covers only the corpus version delivered at the moment of purchase. Do not model a recurring tier as automatically "above" a one-time tier of similar price on an access ladder — check the rank table, not the interval, to know where a tier actually sits.

The fail-safe default: unresolved tiers fall down, never up

A tier-resolution function should treat every unrecognized or missing value as the lowest tier it grants, and ChangeGamer's own resolver is a concrete, copyable example of that principle. resolveTier() maps a Stripe payment-link id to a tier via a fixed lookup table; for any value that is not a string, does not match the expected plink_ pattern, or is not present in the map, it returns starter — never an error, never a higher tier, never a refusal to mint (worker/tiers.ts). The same floor applies downstream: tierRank() in src/data/tiers.ts returns the starter rank for any tier value that is absent or not one of the four known tiers, so a legacy key entry with no tier field, or a future tier name introduced before this code is updated, resolves to the bottom of the ladder rather than an undefined or elevated one.

This is a general lesson worth copying regardless of your own tier names: a resolver that fails toward the cheapest, least-privileged tier turns a mapping bug into an under-grant a support ticket can fix, rather than an over-grant that quietly leaks paid content to buyers who did not pay for it. The alternative — defaulting an unknown tier to the highest rank, or throwing an error that blocks legitimate access entirely — is worse in both directions: one leaks access, the other breaks a paying customer's key on a code path they had nothing to do with.

What this means for designing your own tiers

Pick your axes deliberately before you pick your prices. If your marginal cost per served request is near zero and your real differentiator is legal risk, a license-grant ladder — internal use, training use, commercial embedding, redistribution — costs you nothing incremental to offer and maps cleanly onto what a buyer with counsel actually asks. If your marginal cost scales with traffic, rate limit is the more honest axis, but only if you actually enforce it; publishing a rate-limit column your infrastructure does not check is a claim you cannot back. Keep tiers with identical access rank but different billing cadence explicit about which one they are — do not let a higher sticker price imply a higher rank without checking. And whatever resolution logic maps a purchase to a tier, make its failure mode point down: an unrecognized value should cost a buyer nothing they already paid for, not hand out something they did not. The exact mechanism buyers use to discover which axes your tiers vary on before they pay — the JSON catalog, its field list, and the build-time check that keeps it honest — is covered in machine-readable pricing pages; how the tier gets attached to a key at mint time is covered in issuing API keys to AI agents automatically.

#pricing #tiers #monetization #licensing #agents #api-keys