Patient limit orders
Rest an order at your target price and let the market come to you. The one retention exception, scoped and scrubbed.
A market order pays whatever the auction clears right now. A patient order says something different: run this request whenever the market clears within my limit, and until then, wait. It is a resting limit bid on inference, the demand curve the spot market cannot express. Idle overnight capacity finds the buyers who were willing to wait for it.
How an order rests and fills
You place the order with POST /v1/orders (or placeOrder in the SDK): the request body, a model class, a limit price in USD, and an expiry. The limit amount is prepaid as escrow through the normal x402 flow, and the order rests. A matcher cron watches the book; when a live quote crosses your limit, the order fills. The match test is conservative: the worst-case charge at the crossing quote must fit inside your limit, so you can never be billed past what you escrowed.
The fill runs at the market, not at your limit. You are charged the actual metered cost at the cleared prices, and the difference between your escrowed limit and that charge refunds at epoch close, the same path that refunds per-request overage. Cancel a resting order and the entire escrow refunds. Either way the books balance against the single deposit you made at placement.
Fills are non-streaming in V1, because you are offline by design. The result is stored, and you read it back with GET /v1/orders/:id, which walks the order through its states: funding, resting, filled, expired. One fill per order.
The retention exception
The router's default is zero retention: prompt and reply bodies never touch disk. A patient order is the one deliberate exception, because it must be: the router cannot dispatch your request at 3 a.m. without holding the prompt until then. The exception is scoped as tightly as the job allows. The prompt lives exactly as long as it has work to do, and is scrubbed in the same database transaction that closes the order, whether that close is a fill, a cancel, or an expiry. The stored result then waits for you inside a 24-hour pickup window and is swept by the matcher once the window passes. Economics columns persist forever; content does not.
order_token next to the order id if polling or cancellation will happen in another process.Patient orders pair with forward locks, which freeze today's cleared price for a token budget you spend later; both surface the market's core primitive, a receipted price for a unit of inference, as something you can trade against. The SDK's market making section covers both.
- router/src/orders.ts escrow, the matcher, and the scrub-on-close retention contract