Inference Forwards

E. Kamran and V.M. Teixeira, October 2026

1Introduction§

This paper introduces a new kind of contract, the Inference Forward: a take-or-pay claim on a fixed quantity of inference, on a specified model, delivered during a dated window at a price agreed in advance, intended as the primitive on which a forward market in inference can be built. Because it is written in units of model output rather than hardware time, any operator able to run the model to specification can supply it. We describe the contract, explain what determines its price, and set out how Token House, the exchange we are building, proposes to list it.

2Inference Market Basics§

Inference is bought in two main ways today. A GPU rental gives the buyer a machine for a period of time, paid per GPU-hour, and leaves the buyer to turn that time into output. A real-time API sells the output directly, per input and output token, with an answer within seconds. Only open-weight models can be bought both ways; a closed model, whose weights are not published, is sold solely through its owner's API or approved provider.

For the purposes of this paper, we will follow one model throughout: GLM-5.3-Flash, an open-weight model released by Z.ai in August 2026 whose FP8 weights fit on a single eight-GPU node.¹

A team that wants to run it can rent an 8× H100 node for about $22 per hour,² and pays that whether the node produces ten million tokens or none. Alternatively, it can call an API at Z.ai's list price of $0.15 per million input tokens and $0.50 per million output tokens, which most of the model's other providers match.³ If the work can wait, it can use a batch endpoint instead. The only one for GLM-5.3-Flash on OpenRouter is 20% cheaper than real time,⁴ while the largest labs charge half price for batch on their own models, with completion targeted within 24 hours. OpenAI and Anthropic cancel whatever is unfinished at that point and charge only for completed requests, so the buyer's only remedy for a missed deadline is not paying for work that was never done.⁵

2.1What's Missing§

Neither product is a standard claim on future inference. A buyer cannot lock in next week's inference at today's price except by negotiating with a single provider, and an operator expecting idle capacity next Tuesday has nowhere to sell its output in advance. There is no forward price for inference, and spot prices vary widely: on 5 October 2026, 33 providers on OpenRouter served GLM-5.3-Flash at output prices ranging from $0.25 to $1.00 per million tokens,³ each with varying input costs, latency, uptime and throughput.

Existing products address parts of this. Batch APIs trade latency for a discount set by the provider. Provisioned-throughput products on the major clouds reserve future capacity, but from one provider, in its own capacity unit, and generally without the right to transfer. GPU forward markets reserve hardware time, which is a forward on the production input rather than the output. Decentralised networks such as Akash, io.net and Bittensor give idle hardware other outlets, but each has its own terms and onboarding, so capacity cannot move between them quickly. None creates a provider-neutral claim on model inference that different sellers can fulfil interchangeably.

3The Problem§

Supply that cannot be stored and demand that does not need serving immediately should meet at a discount. They cannot, because there is no unit both sides can trade in and no place where a price can form.

3.1Perishable Supply§

A GPU-hour that goes unused is lost, while the operator's costs (rent, depreciation, financing, power) are almost entirely fixed. Any sale of idle capacity above its marginal running cost contributes towards those costs. Yet an operator expecting idle hours overnight can only rent out the hardware, discount its API and undercut its own daytime customers, or leave the capacity unsold. Unlike a merchant generator in a power market, it has no open market to sell spare output into at short notice, and it cannot sell the output of those hours in advance at a known price.

3.2Flexible Demand§

A chat reply needs an answer within a second; a nightly classification job over the day's call-centre transcripts only needs to finish by morning. Outside best-effort batch, buyers pay for real-time availability whether they need it or not.

Delay tolerance has physical value. During decoding, a GPU reads the model weights once per step, and every request in the batch receives a token from that read. If each request runs more slowly, more requests share each read and the GPU produces more tokens per hour. In one published benchmark of a mixture-of-experts model on H100s, raising concurrency from 60 to 360 requests increased output throughput 2.8-fold while each request slowed only from about 65 to 48 tokens per second.⁶ The gain depends on the workload: with 16,000-token prompts, throughput did not rise at all. A queue known in advance can also be sorted so that requests sharing a prompt prefix reuse the cache. Delay tolerance lowers the cost of production, but apart from best-effort batch there is no way to buy it.

3.3The Wrong Unit§

Hardware markets and indices measure an input to inference, GPU hours, not the product. You don't pay for petrol in drilling-hours. The same hour on different chips, memory, interconnects and runtimes produces very different amounts of output, while usage is uniform: tokens in and tokens out on a given model. Moreover, an index tied to a single hardware type is exposed to model improvements, hardware advances, kernel efficiencies and other forces that can decouple the hardware rental price from the cost of the inference it is meant to proxy. A buyer hedging inference costs against it is left with basis risk: if a new runtime doubles throughput on the same GPU, inference costs halve while the rental index does not move. A tradeable claim has to be written in that output unit, tied to the model that is consumed by the end user, with a defined method for converting hardware into it.

3.4Fragmentation§

Without a standard claim, each forward trade is a bilateral negotiation. Spare capacity has no order book to sit in and no public forward price forms, which rules out benchmarks and derivatives, since they need a reference price that no single party can easily move. Whilst inference is consumed like a commodity, the agreements behave like real estate.

4Comparison with the Electricity Market§

Power is generated in very different ways and cannot be stored economically at scale, yet buyers trade a standard unit, the megawatt-hour, without regard to which generator produced it. That unit trades on several timescales: forwards months ahead, a day-ahead auction, intraday trading up to gate closure, and a balancing market in which the system operator buys short-notice capacity to cover generators that fail to deliver. In many markets the day-ahead price became the main reference rate, in part because it is where most buyers and sellers trade.

Inference can use the same structure: one unit, several delivery terms, a reference price, and a short-notice market that covers failed delivery. The analogy has one key limit: a token on one model is not interchangeable with a token on another, so liquidity must be divided by model.

5The Inference Forward§

5.1Definition§

An Inference Forward is a contract to:

Deliver Q token-equivalents of model M during window W, under delivery type D, at price P.

The contract is fixed at trade and physically delivered. The buyer pays a fixed price for the full quantity, used or not, and so fixes its inference cost in advance. The seller receives that price and must deliver every valid request, bearing whatever delivery costs, whether it serves the work on its own hardware or buys it at spot. The instrument is built to be fungible with other contracts bearing the same parameters, making it both tradable and transferable.

5.2Parameters§

Each forward is defined by nine parameters, which together specify a contract series:

Two contracts with identical parameters are interchangeable whoever delivers them and on whatever hardware, provided the venue can verify that the specified model ran and can replace a seller that fails.

5.3Unit of Account§

Input and output tokens are combined into a single quantity, the token-equivalent (TE) :

$TE = Q_{out} + w \cdot Q_{in}$

w is a contractual convention, fixed for the life of each series so that one TE always means the same thing. Contracts should set w to replicate the economics of the next best spot inference provider that can be sourced to minimise pricing difference, should a seller who failed to provide inference be required to source the work elsewhere.

5.4Delivery Types§

Under Batch delivery, the buyer submits the whole workload before the window opens, and the seller may schedule it freely provided every valid request is completed by the time the window closes. Under On-Demand delivery, the buyer submits requests during the window, up to a stated rate, and each must be answered within a stated turnaround, which can be as short as a real-time API's. How far ahead a contract is traded (its tenor) is a separate parameter, so either type can be bought a day, a month, or a year before delivery.

For example, a day-ahead Batch contract might cover 50M TE of GLM-5.3-Flash, submitted before midnight and delivered by midnight the following day, at $0.20 per million TE. A next-day On-Demand contract might cover 5M TE drawn at up to 100,000 TE per minute between 14:00 and 15:00, each request answered within 30 seconds, at $0.40.

5.5Take-or-Pay§

Balance not submitted by the deadline expires and the seller is paid for it, because it committed capacity for the window. The seller may then resell any capacity the expired balance no longer needs, so the cost of over-buying falls on the buyer, who can instead sell the surplus. Take-or-pay is what makes the contract an attractive proposition for the sellers. Without it, the seller would be writing a free option on its capacity, without guaranteeing their revenues.

5.6Deliver-or-Replace§

A forward claim is only worth holding if it is delivered, and only interchangeable if it does not matter which seller stands behind it. The seller's obligation is therefore to deliver or replace: if it cannot serve a valid request itself, it must source the inference elsewhere at its own cost, so the buyer receives what it paid for at the contract price. If replacement proves impossible, the undelivered balance is refunded at the contract price.

A venue must make that obligation credible, typically by holding security from sellers. This can be done either through requiring sellers to provide collateral, or by requiring sellers to provide a funded API key for the same model they are selling capacity for. The commitment still has limits: correlated outages, or failures larger than a seller's security, can end in a refund rather than delivery. Even so, the buyer exchanges the flexibility of best-effort batch for a firm commitment and a known price.

6Pricing the Forward§

6.1Scheduling Freedom§

The price of a forward depends on how much scheduling freedom the buyer gives up. A Batch buyer hands over the whole queue in advance, so the seller can pack requests densely, group shared prefixes, and choose when and on what hardware each runs. An On-Demand buyer keeps control of timing, so the seller must hold capacity ready for requests that may not arrive, and the tighter the turnaround, the more capacity sits waiting. A real-time API buyer gives up nothing and pays spot. Appendix C formalises this as a pricing band, bounded below by sellers' delivery costs and above by the cost of replicating delivery at real-time spot.

Taking spot as $0.50 per million TE, a day-ahead Batch contract might clear around $0.20 and a next-day On-Demand contract around $0.40, where the seller gains a known load to plan around. An On-Demand contract with a very tight turnaround can clear above spot, because a spot API is best-effort and rate-limited while the contract obliges the seller to keep capacity available. Unlike a volume discount, which can only capture part of the provider's margin, the Batch discount comes from maximising utilisation within a window to lower the cost of production.

6.2The Operator Floor§

An 8× H100 node at $22 per hour must sustain about 12,200 TE per second to break even at $0.50, and about 30,600 at $0.20 (Appendix A). Because node cost is fixed, the floor falls in proportion to throughput: a node that just breaks even at $0.50 on interactive traffic breaks even at about $0.18 if relaxed latency lets it produce 2.8 times as many tokens, as in the benchmark above.

Furthermore, because the contract is written in TE, slower hardware can sell it too, provided it can hold the model and meet the service standard. An 8× RTX PRO 6000 node costs about 24% less per hour than an 8× H100 and needs that much less throughput to break even (Appendix A). Batch, where per-request speed hardly matters, is where such hardware will likely compete best. Expanding the available supply in this way pushes the clearing price towards the lowest floor in the market. For idle capacity the floor is lower still, since only the marginal running cost needs covering.

6.3What Spreads Reveal§

Because the forwards differ only in their parameters, the price difference between two otherwise identical contracts reveals what the market pays for the parameter that differs. The Batch vs. On-Demand spread prices advance submission, the spread between short and long windows prices scheduling room, and the spread to spot prices scheduling freedom and advance commitment together. These readings are only as reliable as the markets are liquid, but no such measurement exists today, because providers bundle all of these parameters into a single price, preventing price discovery.

7Benchmarking Supply§

Inference providers quote per million TE; GPU owners think in dollars per GPU-hour. Benchmarking converts one into the other, measuring the throughput each combination of model, hardware, runtime and delivery type can deliver per GPU-hour. Every ask can then be placed on a single book in the buyer's unit.

Benchmarking should assume the most demanding workload the envelope permits, so real workloads can only do better. Once a request is submitted, its input length and output ceiling are known, the bound on the capacity it needs tightens, and the surplus can be sold again. Unsubmitted balance is never assumed to be easier than worst case, so submitting late gains nothing. This release works fully for Batch, where the whole queue is known before the window, and hardly at all for On-Demand, which is one reason Batch is the cheapest delivery type.

8Token House§

Token House is an inference exchange: a venue for buying and selling inference, and in time the contracts written on it. Its first product is the Inference Forward. As the market deepens, we intend to list the instruments described under Further Applications: cash-settled contracts, perpetual futures and options.

The name is inspired by Tokenhouse Yard in the City of London. In the seventeenth century there was too little official small change for everyday trade, so the City's tradesmen issued their own farthing tokens, which were coined and handed out from a house in the yard. Inference is in a similar position. It is already bought and sold in tokens, but the instruments for trading it forward have not been built, and Token House is where we intend to build them.

Token House will launch in three stages. V0 offers bilateral trading by request for quote (RFQ); V0.5 introduces day-ahead Batch series listed every hour, whose contracts cannot yet be transferred; and V1 enables transfer for the series with the deepest liquidity. The dispatcher and the standby market go live with V0.5.

8.1Architecture§

From V0.5, every trade passes through the same three steps. Buyers and sellers trade bilaterally through RFQ or on the order book for listed series. The dispatcher delivers matched work through sellers' workers, and each completed request is verified and charged to the buyer's prepaid balance. If a seller falls behind, its work goes to replacement.

8.2RFQ Platform§

In V0, a buyer or a seller posts a request specifying the contract parameters (model, quantity, window, delivery type and envelope), and the other side responds with quotes. Accepted trades use the Inference Forward's terms, but delivery is bilateral: the seller serves the work directly, and there is no dispatcher or standby market behind it.

Each seller states the replacement method: a funded API account that replaces failed work, a cash settlement of the replacement cost, or no guarantee, under which failed work is simply refunded.

RFQ continues after listings begin, for requirements that do not fit a standard series. A general contract invites fragmentation, so Token House keeps the schema general and the listings few, and lets recurring RFQ demand decide what is listed next. The first listing follows once there are repeat buyers and sellers with a proven delivery record.

8.3First Listing§

The first listed series will be day-ahead Batch, with a new 24-hour window opening every hour, so that buyers can hand over a queue at whatever time suits their workload. Batch goes first because the full queue is known before execution, which is where density, cache reuse and capacity release are largest and the economic case is easiest to test. Only open-weight models will be listed at first, since they can be pinned by hash and checked against a reference deployment.

While a series is thin, orders are matched continuously: buyers take the best ask or rest a limit order, and each trade settles at its own price. Once no single seller is pivotal, meaning demand can be met without any one seller's capacity, the series moves to a uniform-price auction at the gate, the trading cut-off before each window. Buyers submit bids, sellers submit offers, and every matched trade settles at the single price where supply meets demand. As in power markets, this rewards sellers for offering at cost, since the cheapest capacity earns the gap between its cost and the clearing price. One window reaches its gate each hour, so the auctions run in sequence, and sellers can offer capacity left unsold, or released during delivery, into the next gate.

In V0.5, balances cannot be transferred: a buyer either submits its workload or lets the balance expire. In V1, transfer is enabled for the series with the deepest liquidity, so a buyer who has over-bought can sell the surplus before the submission deadline. We expect these to be the 00Z and 12Z windows, which open during off-peak hours in North America and Europe (00Z) and in Asia (12Z).

8.4Dispatch and Verification§

The dispatcher turns a matched contract into delivered work. It collects the buyers' submitted queues, splits them into small packets and routes them to sellers' workers in line with each seller's sold capacity. It is also what makes contracts interchangeable. Buyers never deal with a particular seller: submitted work goes into a common pool and is routed across all sellers in the series, so each contract is a claim on the pool rather than on whoever sold it. Because packets are small, a seller that falls behind their target throughput is identified early, and its unstarted work can be handled by the fallback mechanisms before the window is at risk.

Verification runs through the same path. It has to confirm that the specified build ran, that every accepted request was completed, and that tokens were counted correctly. The dispatcher inserts seeded challenge requests and compares the answers with a reference deployment at the envelope's precision, within a stated tolerance; it also samples completed requests for recomputation and logs input and output token counts. This gives statistical rather than cryptographic assurance. To protect buyers' prompts and data from being visible to whichever seller serves them, trusted execution environments (TEEs), which run the model inside an attested hardware enclave, will be supported.

Settlement follows each request. Its maximum cost is pre-authorised against the buyer's balance at dispatch, and only the TE actually consumed is drawn down when it completes.

8.5Standby Market§

The standby market is where the dispatcher buys short-notice capacity when a seller falls behind. It trades the same contract in its shortest-tenor form: On-Demand delivery, bought during the window. Like the balancing market in electricity, it exists to cover failed delivery rather than to serve buyers directly.

Standby sellers are qualified GPU owners and providers with spare capacity, benchmarked in the same way as primary sellers, which makes standby the merchant market for short-notice capacity that inference currently lacks. They post standing asks, and the dispatcher buys from them on the failing seller's account. The market gives GPU providers a non-committal way to participate in the exchange. A deeper standby market lowers the cost of replacement, which in turn eventually lowers the security sellers must post.

8.6Replacement and Security§

Token House enforces the delivery obligation through a fixed sequence:

When the dispatcher detects a lagging seller, its unstarted work goes first to other matched sellers, then to the standby market, and then to a real-time API account that each seller keeps funded with an outside provider. Anything still undelivered is refunded at the contract price.

The buyer never pays beyond the initially agreed contract price regardless of how the work has been delivered. Any cost above that price falls on the failing seller and is drawn from performance security posted in advance, sized to the cost of replacing its outstanding obligations at real-time prices. Requirements fall as a seller builds a delivery record. The detailed collateral methodology is still being designed.

8.7The Index§

Once volume is sufficient, Token House intends to publish the Token House Inference Rate: the clearing price at each gate, reported separately for each series. For series still matched continuously, the rate is the volume-weighted average of trades in the hour before the gate. Unlike hardware indices, it would measure the price of inference itself. This will serve as the reference rate for future inference derivatives built on top.

9Further Applications§

The Inference Forwards and initial Token House mechanics represent the core primitive building blocks to build out the financialisation of AI. The following further applications highlight additions to the contracts that allow for greater flexibility and scale as the market matures.

Options. Once there is a forward curve with depth, the right to buy inference at a fixed price without the obligation becomes worth pricing.

Cash-settled contracts. Once the index carries enough volume to serve as a benchmark, enterprises could hedge inference costs directly without moving any workload.

Perpetual futures. Once the Token House Inference Rate can support cash settlement, a perpetual future on it would give a hedge that never expires, kept in line with the index by periodic funding payments.

Multi-model contracts. Once more than one build is benchmarked within a class, "any qualifying model in class X" can become a parameter, and its spread against a named build prices the right to substitute. This also allows for continuous upgrades as new models are released, making longer-tenor contracts possible.

The physical contract comes first. Each step towards cash settlement and options moves closer to regulated territory and will be taken deliberately.

10Appendices§

AOperator Floor§

$\text{Required TE/s} = \frac{\text{Node cost per hour}}{\text{Price per million TE} \times 10^{-6} \times 3600}$

Throughput is aggregate across all requests on the node and assumes full utilisation; at 70% utilisation it must be about 43% higher. Node prices are $2.75 per GPU-hour for H100, close to the Silicon Data index,² and $2.09 for RTX PRO 6000, between two published medians.⁷ Listed H100 on-demand medians are higher, around $3.25,⁸ which would raise the H100 figures by about 18%.

BExample Listing§

Token House sets w from the ratio of input to output prices across the model's providers on OpenRouter. For GLM-5.3-Flash, 27 of 35 endpoints, including Z.ai's own, price input at exactly 0.30 times output,³ so w = 0.30 and the price per TE equals the output-token price.

CPricing the Forward§

This appendix sets out the pricing argument behind the main text. Prices are per TE. $F_0(\theta,T)$ is the forward price agreed at time 0 for delivery at time $T$ under terms $\theta$ (delivery type, service standard, envelope and window); it is the $P$ of the contract definition. $S_T(\theta)$ is the price at $T$ of inference delivered under the same terms, and $S^{RT}_T$ the real-time API price. $\mathbb{Q}$ and $\mathbb{P}$ are the risk-neutral and physical measures, and $r$ is the risk-free rate. We treat delivery as occurring at a single time $T$; for windows of a day or less the error is small, and the timing choice within longer windows is handled in C.4.

C.1Value at Inception§

The long position pays $F_0$ and receives inference worth $S_T(\theta)$. Its value at inception is

$V_0 = e^{-rT}\,\mathbb{E}^{\mathbb{Q}}_0\big[S_T(\theta) - F_0\big] = 0 \quad\Rightarrow\quad F_0(\theta,T) = \mathbb{E}^{\mathbb{Q}}_0\big[S_T(\theta)\big].$

If the buyer prepays at trade, the amount paid is $e^{-rT}F_0$. At day-ahead tenors the difference is negligible: at a 4.5% rate, one day of discounting is about 0.01%.

Zero value at inception is a statement about market value, not about any one seller. An operator whose cost of delivery is below $F_0$ earns a margin on every contract, and that margin is what brings supply to the market.

C.2No Cost of Carry§

For a storable asset, cash-and-carry arbitrage fixes $F_0 = S_0 e^{(r+u-y)T}$, where $u$ is the storage cost and $y$ the convenience yield. Inference cannot be bought today and held until delivery, so the arbitrage is unavailable and $F_0$ is not tied to today's spot price. As in electricity, the forward price is a forecast plus a premium:

$F_0(\theta,T) = \mathbb{E}^{\mathbb{P}}_0\big[S_T(\theta)\big] - \pi_0(\theta,T).$

The first term reflects the expected path of spot. If inference prices fall at a rate $\delta$, then $\mathbb{E}^{\mathbb{P}}_0[S_T] \approx S_0 e^{-\delta T}$ and the forward curve slopes downward in $T$. The second is the risk premium, whose sign depends on which side hedges more: operators selling perishable capacity forward push $\pi$ above zero, and buyers seeking cost certainty push it below. In electricity, the premium has been found to depend on the variance and skewness of spot prices.⁹ Neither $\delta$ nor $\pi$ can be estimated without a traded forward, which is why a forward curve would carry information that spot prices do not.

C.3The Pricing Band§

Two arguments bound $F_0$.

Upper bound: replication. A seller can always meet its obligation by buying real-time inference at delivery, as the delivery obligation requires. If the series' $w$ matches the input-to-output price ratio of the replacement provider, the cost per TE is exactly $S^{RT}_T$, whatever the buyer's mix of input and output tokens. For any terms that real-time supply can satisfy, $S_T(\theta) \le S^{RT}_T$, and so $F_0(\theta,T) \le \mathbb{E}^{\mathbb{Q}}_0[S^{RT}_T]$. The bound fails only when real-time supply is itself rationed by rate limits or outages, which is when an On-Demand contract with a tight turnaround can clear above spot.

Lower bound: cost. No seller accepts less than its cost of delivery. For a node with hourly cost $H$ that sustains $X(\theta)$ TE per second under terms $\theta$, the cost per TE is $c(\theta) = H/\big(3600\,X(\theta)\big)$, as in Appendix A. For dedicated capacity $H$ is the full hourly cost; for capacity that would otherwise sit idle, it is only the marginal running cost. With competition among benchmarked sellers, spot cannot settle below the cheapest seller's cost, giving

$\mathbb{E}^{\mathbb{Q}}_0\Big[\min_i c_{i,T}(\theta)\Big] \;\le\; F_0(\theta,T) \;\le\; \mathbb{E}^{\mathbb{Q}}_0\big[S^{RT}_T\big].$

The upper bound is an arbitrage bound. The lower bound is an equilibrium condition, since a seller could in principle sell below cost.

C.4Delivery Terms as Timing Options§

Where a contract clears within the band depends on who holds the right to choose when work runs. Under Batch delivery the seller holds it, scheduling the queue at the cheapest time and on the cheapest available hardware, much as the seller of a bond future chooses which bond to deliver. This raises $X(\theta)$ and pushes Batch towards the lower bound. Under On-Demand delivery the buyer holds it: requests can arrive at any time up to the rate cap, so the seller must reserve capacity for the peak rate rather than the average. The contract resembles a take-or-pay swing contract in gas or power, in which the total quantity is fixed and the buyer controls timing.

For two contracts on the same model and window,

$F_0(\text{On-Demand}) - F_0(\text{Batch}) = \Lambda(\theta) \ge 0,$

where $\Lambda$ is the value of the timing right passed from seller to buyer. The direction of the other parameter effects follows from the same reasoning:

Each row is a spread the market can observe once both contracts trade.

C.5Failure and Wrong-Way Risk§

Let $D$ be the fraction of the balance refunded after replacement fails. On that fraction the buyer receives nothing and pays nothing, so

If failures are independent of spot, $F_0$ is unchanged. Failures are more likely when demand is high and spot is expensive, however, so the covariance is positive and the buyer pays less than expected spot to compensate. Mechanisms that make replacement reliable, such as seller security and standby supply, reduce $D$ in exactly those states, which is why deeper security and standby markets let forwards trade closer to expected spot.

References§