Control what your company spends on AI.
Amprix puts every AI request your company makes behind one set of rules. Budgets and model access per team, spend you can see as it happens, and models you can change at will.
Most companies find out what they spent on AI when the invoice lands.
Provider keys spread across teams faster than anyone tracks them. The money is gone before the number is visible, and the decisions are a month old.
-
Keys are scattered
Every team holds its own provider key. There is no single place to see what the company is spending or to change it.
-
Attribution arrives late
An invoice gives you one total. It does not tell you which team, which application, or which model produced it.
-
Budgets are advisory
A ceiling that nothing enforces at the request path is a number people agree to and then exceed.
-
Switching is a project
Provider SDKs are wired into applications. Moving traffic to a cheaper model becomes an engineering ticket, so it never happens.
Built for companies running AI in several teams at once, with nobody whose job it is to build these controls and enforce them.
One place where AI spend is set, enforced, and visible.
Amprix sits between your applications and the model providers you use, and every request passes through it. It runs as a single deployment that belongs to you, in your own cloud or on an instance dedicated to you. There is no shared service in the middle and no other customer's traffic beside yours.
-
Hard budgets
Set a spend ceiling per key or per team. A request over the ceiling is refused before it reaches a provider. Enforcement, rather than reporting after the fact.
-
A key for every team
Issue a separate key per team, application, or environment. Each carries its own budget, its own limits, and the list of models it is allowed to call. Revoke one without touching the rest.
-
Rate limits
Cap requests per minute on any key, so one runaway loop cannot drain a month of budget overnight.
-
Routing with fallbacks
Put several models behind one name and set the order they are tried. When a provider fails or throttles you, traffic moves to the next one without an incident.
-
Model switching as config
Applications call one endpoint and one model name. Which model actually serves that name is a line of configuration. Moving from a frontier model to an open one ships nothing to your clients.
-
Spend you can see
Every request is metered by key, team, model, and day. A weekly report renders as a single page, and the full spend log exports to CSV.
What changes once it is running.
Amprix does not change what your teams build. It changes what the person who owns the budget can see and act on. Nothing below is a projection. All three follow from routing every request through one place instead of through a separate provider key for each team.
-
Attribution
TodayOne invoice total, arriving a month late.
With AmprixSpend broken out by team, by application, and by model, for whatever period you are looking at.
-
The ceiling
TodayA ceiling nobody can enforce.
With AmprixA limit applied at the moment of the request, so passing it takes a deliberate decision to raise it.
-
Changing models
TodayA cheaper model waits on engineering time.
With AmprixMoving traffic to a less expensive model is a change to configuration.
One endpoint in front of the providers you use.
Amprix speaks the OpenAI-compatible API. If your team already calls that API, the client libraries keep working and what changes is where they point.
-
Point your applications at it
For most clients the change is a base URL and a key. No new SDK, no rewrite of the calls your team already made.
-
Set the policy
Issue a key per team with a budget, rate limits, and the models that key is permitted to reach.
-
Watch spend and move traffic
Spend is visible per team and per model as it happens. When a cheaper model clears your quality bar, you move traffic to it yourself.
Built to survive a security review.
Every item here is implemented, and most of them are re-checked by an automated suite on every run. The security document says which ones a test cannot prove on its own and lists what is not in place yet, because a document that hides its gaps is worth nothing. We send it before you ask.
-
Single tenant by design
One deployment serves one customer. There is no shared control plane, no pooled database, and no cross-customer surface, because there is no multi-tenancy to get wrong.
-
Metadata only
Amprix records token counts, costs, models, and latency. Prompt and response bodies are not stored, and the system does not inspect or modify the content of your requests.
-
No third party in the path
Amprix adds nobody to your request path. The only external party your data reaches is the model provider your own routing policy names.
-
TLS everywhere, admin behind an allowlist
Traffic is served over TLS. The administrative surface is restricted by source address at the edge, and inference stays authenticated by virtual key.
-
Separated privileges
A team key cannot mint other keys and cannot read organization-wide spend. Both attempts are refused rather than quietly allowed.
-
A tested restore, not a documented one
Each deployment backs up on a schedule, and every dump is read back before it counts as a backup. The restore path was exercised by destroying the database outright and bringing it back. Spend totals, team records, and keys issued before the destruction all came back intact and still authenticated.
Start with a free thirty minute read of your AI spend.
Tell us roughly what you are spending today and who owns that budget. We will walk through what your current spend looks like and where Amprix would change it. Nothing to prepare on your side.
- Which providers you use, and whether spend sits on one company card or many.
- Whether anyone can currently answer which team spent what.
- What you would want capped first, if you could cap anything.