For engineering and platform leads whose applications call more than one AI provider
An AI gateway that writes one record for each request it serves or refuses
Postrouter is an AI inference gateway in development: a server that sits between an application and its model providers. Its code today replays recorded traffic on a developer's machine; it is not a hosted service and there is nothing to sign up for.
Tell us what your gateway leaves out
Please leave out keys, prompts and customer data. Mail to this address goes to the project inbox and is read there. A reply may be written with the help of software.
Where it stands
- What this page says about the code comes from reading the source on 11 October 2026. The code was not run for this page.
- There is no hosted service, no sign-up and no key to request. The project's own documentation describes the server as local only and not deployed.
- Receipts are unsigned. Charging a retried request once and reconciling against a provider's invoice are specified and not built.
- No team has been asked about this, and nothing is for sale.
Checked
What the code does today
- A record for every request
- Each request gets one receipt record, whether it was served or refused. The record holds a receipt id, the request id, the tenant, the endpoint, the latency, the token counts as the provider reported them, and SHA-256 hashes of the request and response bytes. One gap seen in the reading: a stream the caller abandons part-way appears to get no record.
- The id goes back to the caller
- The receipt id is returned in a response header. The record itself is written to the operator's log or trace file.
- Routing by hard constraints
- Endpoints that fail a hard constraint, such as health or a data-retention rule, are filtered out. The first eligible endpoint is used; cost and latency are not weighed yet.
- Rate limits per tenant
- A token bucket with a fair queue per tenant limits the rate of requests.
What is not built
- Signed receipts
- The records are unsigned. The signing library is a skeleton.
- Fetching a receipt
- A caller gets the id only. There is no route that returns the record.
- Live providers
- The server answers from recorded exchanges. It does not call a model provider.
- Fallbacks, retries, budgets, redaction
- None is in the running server. There is rate limiting, not a spend budget, and no detection or masking of personal data.
- Metering and billing
- There is no charging code. Charging a retried request once, and reconciling usage against a provider's invoice, are specified and not built.
The question we are asking
Existing gateways already document routing, fallbacks, retries, timeouts, budgets and redaction. On the public pages of seven of them, read on 11 October 2026, we found none that documents a signed receipt for each request, protection against a retried request being charged twice, or reconciliation against the provider's invoice. Signed receipts are documented by a third-party plugin and two smaller products.
Postrouter has not built those three either. Before it does, we want to know whether duplicate charges, charges for cancelled streams or invoice mismatches have cost your team money, and whether you need a receipt that a third party can check.