Double billing on retries
Timeouts make clients retry, and you pay for the same work twice.
Idempotency
Retry freely, get billed once
Networks drop, workers restart, queues redeliver. Add an Idempotency-Key header to each logical request and usage for that key is recorded once, however many times you retry.
Metered once
per idempotency key
Account-scoped
no cross-account collisions
One header
Idempotency-Key
The problem
What is slowing you down today
Fear of retrying
Without idempotency, teams avoid retries and accept failures instead.
Queue redelivery
At-least-once delivery means at-least-once billing, unless you guard against it.
Capabilities
Everything you need, nothing you don't
The header
Send Idempotency-Key: <unique string> with POST /api/ainf/inference. If you cannot set headers, an idempotency_key field in the JSON body is accepted.
Metered once
The usage event for a given key is recorded once. Later requests with the same key are not metered again.
Namespaced to your account
Keys are combined with your account on our side, so your keys can never collide with, or suppress, another customer's usage.
Works with fail-over
Fail-over happens inside one request, so it never creates a second metered event.
Pairs with the cache
An identical retry inside the cache window is also served from cache and priced at zero.
Optional
Without the header, each successful request is metered on its own.
Use cases
What teams run on it
01
HTTP client retries
Generate the key once per logical request and reuse it on every retry.
02
Queue consumers
Use the message id as the key so redelivery is not metered twice.
03
Batch jobs
Use a stable id per item, such as a SKU or document id plus a job id.
04
Agent steps
Key each step by run id and step number.
How it works
From sign-up to production
- 1
Generate a key
Create a unique string per logical operation, such as a UUID or a stable job and item id.
- 2
Send it every time
Include the same Idempotency-Key on the first attempt and every retry.
- 3
Use a new key for new work
A different prompt or a new operation gets a fresh key.
Control
Built so you stay in charge
Keys you control
API keys are shown once at creation and stored only as a hash. Revoke any key instantly from Settings.
Spend you can see
Every request carries its own receipt: tokens in, tokens out, latency and price. Nothing is billed that you cannot trace.
Limits you set
Per-account rate limits and a free monthly allowance keep experiments safe before they become production.
Data you decide on
You choose exactly what you send. Repeat prompts can be served from your cache, and cache hits are never billed.
For developers
One endpoint. Every model.
Send a prompt and a capability, or name a model. One bearer key, one small JSON body, and a full receipt on every response.
curl https://YOUR-DOMAIN/api/ainf/inference \
-H "Authorization: Bearer $AI_INFERENCE_KEY" \
-H "Content-Type: application/json" \
-H "Idempotency-Key: order-1042" \
-d '{"prompt":"Summarise this ticket in one line","capability":"chat"}'Questions, answered
Does a retry return the original response?
The retry is processed normally and returns a response. What the key controls is metering: usage for that key is recorded once. An identical prompt inside the cache window is also served from cache.
What should I use as the key?
Anything unique to the logical operation: a UUID generated before the first attempt, a queue message id, or a job id plus an item id.
Can I reuse a key for different prompts?
Do not. Use a fresh key for every new piece of work so each one is metered correctly.
Is the key visible to anyone else?
No. It is namespaced to your account and stored only in hashed form as part of the usage record.
Make every retry safe
Add one header and stop worrying about double metering.