Pricing & demand

You set prices; the marketplace does not intervene in them. What it does is route — and routing has rules you can play well. This page connects the mechanics to the decisions: what to charge, how traffic follows price and measurement, and how to grow a listing deliberately.

How price steers routing#

Default routing, for a request that states no preference, orders a model's eligible endpoints by provider-reported capacity first, then health, then a load balance across them with a strong preference for lower prompt price: an endpoint at half the price is tried about four times as often. The order is deterministic for a given request, so the preference compounds over volume — on equal health and capacity, cheaper earns more traffic.

Customers can override the order (sort: "price", the :floor suffix, max_price ceilings) or ignore it (:nitro, :free, pinned providers) — a meaningful slice of traffic asks explicitly for cheapest or fastest. The two ways to be routed more, then:

1. Be cheaper — the balance shifts roughly with the square of the price ratio.
2. Be better — healthier tiers are preferred before price is even consulted, and customers sorting by throughput or time to first token go where the measurements are.

Price and quality are not in opposition here; they are two columns in one table the customer reads. A cheap endpoint with poor measurements wins the traffic that asked for cheap and little else.

What to charge, and in which units#

Prices are per unit, published as exact decimal strings, and the listed price is the billed price — customers pay it, you receive it minus the platform share. A price is an entry of type, unit and cost_usd on the modality that meters it, and only a request-scoped price sits at the entry root. The units you can price:

A legacy web_search per search declaration is accepted for compatibility, but searches are not counted at settlement. Its rate is neither charged nor published; omit the entry until search usage can be metered.

Choose the unit your service actually bills. Per-image and per-video-second tariffs can carry explicit conditions for supported settings. A linear megapixel tariff is also valid for images; it is not a universal conversion for token prices, non-linear area tiers or video duration.

Input text and image token tariffs require distinct measurements. Do not charge a combined token total again after charging its text/image components. Missing usage is unknown, not zero.

A completion entry has one applicable billing basis. Declaring both image and megapixel for the same type and qualifiers does not establish two additive charges. Use the entry’s ordered overrides for conditional rates: the last matching override wins. The gateway freezes the selected rate for reservation, settlement and recovery, and refuses a declared tariff it cannot safely reserve or meter.

For a linear megapixel tariff, a 512×512 image consumes 0.262144 units. The meter retains fractional megapixels; it does not round the area up to a whole unit.

A discount reduces the rate, and the charge is rounded once. discount_to_user multiplies every price you declare, so a published rate can carry more decimals than the 24 a charge is settled at; what a request pays is that rate times the units it consumed, floored once at that boundary. The rate is never rounded before the unit count multiplies it, whichever unit meters the request. The catalogue discount applies across every model without editing the document. The larger of the endpoint and catalogue discounts determines provider gross before the platform cut. A site promotion can lower the customer price further; the marketplace funds only that extra difference.

A synthesis is billed on the text, not on the audio. The marketplace counts the characters of the request itself, so the charge is settled before your endpoint answers and a caller can price a synthesis exactly from the text they are about to send. A dedicated synthesis has no unit for the seconds it produces: a price per second already covers a second of audio decoded from a request or carried in a chat reply's own speech, and a synthesis endpoint returns neither — its output second is your engine's pacing rather than anything the caller chose, so two callers submitting the same sentence would pay different amounts for the same work. Seconds produced are measured where the container states them exactly and published as a figure beside the charge.

A speech entry declares no rate per token. A synthesis records no token, so a prompt or completion rate per token on it would be a published price nothing is ever charged at, which reads on the marketplace as a free rail: the speech output carries one entry, completion per character, and nothing else. An entry that serves text as well keeps its real token prices on its text modalities, which apply to its text requests.

A cache lifetime priced apart is a unit of its own. ttl_seconds on a cache_write entry names the lifetime its rate buys. The catalogue publishes the entry carrying no lifetime as input_cache_write and the one buying an hour as input_cache_write_1h, so a customer comparing endpoints reads two prices rather than one figure whose meaning turns on a qualifier they cannot see. A lifetime the public wire has no field for is left out of the published prices rather than shown without the qualifier that selects it, which would read as the price of every write.

A conditional rate is published under its condition. An entry's overrides, and an entry carrying a utc_start/utc_end window, reach the catalogue as pricing.overrides: each a price beside the prompt-length threshold or UTC window that selects it. The scalar price beside them stays what a request matching no condition pays. A condition the public wire carries no field for keeps its price out of the catalogue entirely, because a conditional rate shown without its condition quotes a price most requests are never charged.

A token-rail tier is charged on prompt_tokens and nothing else. A prompt_tokens condition on a text entry is resolved twice for every request: the credit hold reads the prompt estimate it reserves against, and the settlement reads the prompt count your endpoint reported, which is the count the charge is taken over. Recovery of a request the marketplace did not settle inline resolves the tier from that same reported count, frozen with your entries, so a generation costs what it would have cost inline. A reply that reports no prompt count is charged your entry's own price rather than a tier, because a threshold nothing measured is unknown and not met. A condition on any other quantity is never evaluated on the token rails, so a tier declared on one is a rate nothing is ever charged at — state a rate you mean to be paid through prompt_tokens or through the rendering settings the image and video rails resolve when they quote a render.

Three rules from the contract, restated as pricing advice:

• Price every unit you consume. A unit you bill without a published price is recorded as unpriced and flagged for review — into nobody's favour, including yours.
• "0" is a real price, and it is not the same declaration as is_free. A zero is billed as a zero; is_free bills every unit you price at zero whatever you wrote beside it, and it is what :free routes to. Free tiers are a legitimate way to earn measurement samples and trust early.
• Scalar prices have public history. The model page charts changes in supported per-unit rates. Conditional, windowed, or ambiguous native media tariffs have no scalar chart value; inspect the structured image endpoint pricing for those declarations.

A cache example, because it is the highest-leverage pricing decision: an endpoint at $0.40 /M completion and $0.037 /M cached-prompt serves a customer whose 4 000-token system prompt repeats every call. Their cost collapses on your endpoint; the headline price did not have to move at all. If your engine has a prefix cache, declaring cached_prompt is close to free money.

Being found and trusted#

Traffic follows more than price:

• Measurement earns trust. Uptime, time to first token, throughput and tool-call success fill in as samples arrive, and absent figures read as "unknown", not "zero". Serve well and the numbers arrive on their own.
• Benchmarks attach to your endpoint. Scores are per endpoint — the same weights at a different quantization answer differently — and grading is mechanical. If you serve a quantization, its score is yours; declare the quantization so the comparison is honest.
• Capacity reporting earns routing. A live heimdall.live_capacity counter puts your free slots ahead of endpoints that report nothing. Implement it honestly; see operating.
• Declarations are filters. zdr, hipaa, data-collection policy, quantization, supported parameters — customers exclude on all of them, and an undeclared value never passes a guarantee-seeking filter. Declaring honestly widens your eligible traffic; over-declaring eventually meets the measurements — and a zdr declaration wins zdr-only traffic only after marketplace review approves it.
• Metadata sells. Description, Hugging Face link, tags, datacenter countries — the fields a browser compares you with. The exact-case hugging_face_id rule matters: a wrong-cased id links to nothing.

Growing a listing#

• Version deliberately. A rebuild is a new id under the original author, grouped by its base_model into a family. List the new version alongside the old, give the old one a deprecation_date and a runway, and let customers move.
• Multiple endpoints are allowed. Two quantizations of one model are one id and two endpoints, told apart by the quantization field, not two ids — a cheap int4 and a faithful bf16 are two rows a customer can choose between under the same model. A second id is for different weights, never for a different build of the same ones.
• Watch your earnings per model. The dashboard's per-model breakdown, read against the public rankings, tells you where your traffic comes from and what to serve more of.
• Beware the race to the bottom. The four-times rule cuts both ways; so does health. An endpoint that wins on price and loses the measurements keeps only the traffic that asked for cheap — and that traffic leaves for the next cent down.

The money, end to end#

The chain, specified fully in Listing your models: every generation you serve — the platform's own probes included — records gross, the platform share (10% by default) and your net, at your listed prices, in exact arithmetic. Each UTC month closes into a statement, and payouts go out as USDC on Ethereum mainnet to a deposit-proven wallet. Your listed price is exactly what the market compares — customers pay no deposit fees on top.