Rewrites for every vendor
Changing models should not mean changing your whole client layer.
Migration
Switch over in an afternoon
If your app already sends chat-style requests over HTTP, moving is mostly configuration. Change the base URL, swap in your key, and map your message text into the prompt field.
Base URL change
plus a small body mapping
Familiar parameters
temperature and max_tokens carry over
Instant upgrades
routing, fail-over and caching included
The problem
What is slowing you down today
Fail-over you wrote yourself
Your retry-and-switch code is the least tested part of your stack.
No price per call
Your current setup reports tokens, but not what each call actually cost.
Capabilities
Everything you need, nothing you don't
Point at a new base URL
Send requests to https://<your-host>/api/ainf/inference instead of your current completion endpoint.
Keep the bearer header
Authorization: Bearer <key> works the same way. Only the key value changes.
Map messages to prompt
Join your system and user message text into a single prompt string. Most integrations do this in one helper function.
Same parameter names
temperature and max_tokens keep their familiar names and meaning.
Model names become ids or capabilities
Replace hard-coded model names with a catalog model_id, or drop them and send a capability.
Read the new result
Your text is in result.response; usage is in result.input_tokens, output_tokens and total_tokens; the price is in result.price_micros.
Use cases
What teams run on it
01
Single-turn features
Summaries, rewrites and extraction move over with almost no change.
02
Multi-turn chat
Serialise the conversation into the prompt in a consistent format.
03
Batch jobs
Add an Idempotency-Key per item so restarts are metered once.
04
Gradual rollout
Send a share of traffic to the new endpoint behind a flag and compare.
How it works
From sign-up to production
- 1
Swap URL and key
Update configuration to the new endpoint and bearer key.
- 2
Adapt the body and parsing
Build prompt from your messages; read result.response and usage fields.
- 3
Remove what you no longer need
Retire your own fail-over and caching code once traffic is stable.
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
Is the request format identical to what I use now?
It is close but not identical. The auth header, temperature and max_tokens carry over; your message text goes into a single prompt field.
Do I need to change my HTTP client?
No. Any client that can send JSON over HTTPS works, including the one you already use, once pointed at the new base URL.
Can I keep using a specific model?
Yes. Find it in the catalog and pass its model_id.
How do I test before switching?
Run your real prompts in the playground, then route a small share of traffic to the new endpoint.
Bring your app over this afternoon
Change a URL, map one field, and gain routing, fail-over and caching.