A semantic LLM router with the gateway built in. Your product calls one endpoint. We check spend before every call and check every answer before it returns.
https://api.apiaccesspoint.com/v1/invoke“Reply to a customer who cannot find their invoices in their account.”
A captured sample. Tier and reason only: no vendor names or provider prices.
A real call to the real endpoint, with no key or signup. Under the answer is the gateway's receipt: how it read the request, what each tier would cost and what it chose.
Pick one and send it. What comes back is a real call to the real endpoint, with the gateway’s own account of what it decided underneath.
The key behind this page is held to $2 a day, one origin, one capability and the cheapest tier, by the same pre-flight check that governs a paying tenant. When the day’s budget runs out the page says so and shows a trace captured earlier, rather than quietly becoming something else.
Each request is classified, matched to a model tier and effort, and checked before it returns. Six stages run inside one API call.
text.summarizeread as data · lowcapped to minimal by the key's ceilingchecked: passpriced at 199 user tokens
The industry splits this work into layers that make different decisions. A2 runs the gateway and the router in one endpoint. The providers run the models.
| API Access Point · one endpoint | The providers | ||
|---|---|---|---|
| Gateway | Semantic router | Model provider | |
| What it decides | Who may call, and how much they may spend | Which model tier and effort serve this request | How the model runs on its own hardware |
| What it reads | API key, calling domain, balance, rate limits | The request's domain, task type and complexity, and the capability's policy | Its own load and capacity |
| What it owns | Provider credentials, domain grants, spend and rate limits | The tier choice and the answer check | Inference |
| What you see | User tokens charged and the balance left | The receipt: how it was read, what each tier would cost, what ran and how it graded | Nothing. A2 holds the provider accounts. |
An AI gateway decides how a request reaches a backend. A semantic router decides which model should serve it. A2 makes both decisions before the provider is called.
Hard limits remove options before anything is ranked. What survives goes to the least effort that meets the goal.
Domain grantCapability ceilingBalance checkA request outside its limits is refused or capped before any provider is called.How the controls work →
Web apps, mobile apps and background workers call the same HTTPS endpoint. There is no SDK or vendor kit to install.
A capability is set in the console, so a change is live without a deploy.
The key only works from the domains you grant.
Spend is checked at the door, so busy never quietly turns expensive.
curl -X POST https://api.apiaccesspoint.com/v1/invoke \ -H "Authorization: Bearer $A2_KEY" \ -H "Origin: https://app.yourproduct.com" \ -H "Content-Type: application/json" \ -d '{ "capability": "text.summarize", "prompt": "Summarise the attached incident report." }' # One address. What serves it can change behind it # without a release on your side.
Add -H "X-A2-Trace: 1" to any call to get the decision receipt.
How the machinery works, the trade-offs it makes, and the parts that are not built yet. Written for somebody who intends to check.
Bring one workflow and a rough monthly volume. You leave with a model mix, a failover order, a cost boundary and an integration path.