Early on, when we were designing how plans would work, we spent several weeks assuming we would gate model access the way almost every other AI gateway does. Frontier models behind the higher plans, cheaper or older models on free. It is a completely reasonable structure, and we were deep into designing around it before someone asked a question that stopped the conversation cold: what happens when a team wants to evaluate whether a new model is worth switching to? The answer, under the plan-gates-models structure, is that they upgrade first, then test. Which means the decision to spend more is made before the data that would justify it is available.
We kept turning that over and couldn't find a way to make it feel right. So we made a different choice: every plan, including free, gets the full catalog. What plans unlock is the management layer, budget allocations, audit logs, spend analytics, invoices. The model is never the thing being controlled. The controls are.
We also run several free models at no cost. No balance required. A new account can run real inference from the first minute.
There is one real cost to this design that we do not want to paper over. If something goes wrong while you are on the free plan, a runaway integration, an unexpected cost spike, the tools you would want to diagnose it are on the paid plans. The audit log that would show you which key, which endpoint, which time window drove the spend is a team-plan feature. We believe teams running anything in production should be on a paid plan before they need those tools, because the alternative is discovering the need for them at the worst possible moment.
The question of what a spend limit actually means
Sometime in the design process we started drawing a distinction that turned out to matter more than we expected: the difference between a notification and a refusal.
A billing alert is a notification. It tells you that a threshold was crossed. It fires after the meter ran, by definition, because metered billing accrues before it is reported. If your alert is set at $500 and something goes wrong at midnight, the alert fires when you are asleep. By morning the charge is real and the meter is still running.
A spending cap in the request path is a refusal. When the limit is hit, the next call is declined before it reaches the provider. The meter stops. The exposure at the moment you set the cap is the maximum possible exposure, not a threshold for notification.
Most AI providers offer the first mechanism. Some call it a spend control. It is not. One is a receipt service, and the other is a wall.
We built walls. Every workspace has a configurable limit that enforces as a hard refusal. And because the product runs on prepaid credits, there is a second ceiling underneath all of it: you cannot spend what you have not loaded. The two together mean the worst-case financial exposure from any key or workspace is bounded before the request is made, not discovered in the invoice.
Here is the real tradeoff, and it is worth naming directly. A wall that is set too low will refuse legitimate traffic. If a product ships and usage grows faster than anticipated, the cap that was correctly sized for testing will break a production service in the middle of the night, with no warning before it happens. The request fails and the users see an error. We have had that conversation with teams, and it is not comfortable. The discipline the design requires is not complicated, caps need to be reviewed as products grow but it is real and it does not go away.
The alternative is a notification model where nothing is ever refused and the protection is whoever checks their email first. That has a known failure mode too. We think the bounded operational risk is easier to recover from than an uncapped financial one, but that is a judgment call, and we would rather you make it knowingly than be surprised by either side of it.
What we learned when we tried to unify the billing for text and images
Most frontier models today accept images. They all process images alongside text. Documents, screenshots, photographs, diagrams. It is the frontier now, not a specialty tier.
The standard path for adding image capability to an existing text integration is to add a second integration. Separate key, separate account, separate invoice. Some gateways route across both cleanly, but reconciliation is still the customer's problem.
We put everything on one balance. Text, images, different providers, same key, same credit pool. It simplifies administration significantly, but the more interesting effect showed up when we started watching how teams actually used it.
A pipeline that begins handling image inputs costs more per request than the same pipeline on text, and the difference is not small. If that change is visible in one account, the spend signal is immediate and clear. A line goes up; you investigate. If the same spend is spread across two accounts, the aggregate picture can look unremarkable even when one piece of it has changed substantially. We had not fully anticipated how much the unified view would matter for teams monitoring cost in real time, and it became one of the things we heard about most in early conversations.
One thing this design does create is a single point of failure for the balance. If credits run low and are not replenished, every integration on the account stops simultaneously, text and image, all providers. Separate accounts would fail independently; a shared balance takes everything down at once. Workspace-level caps help contain it, because you can run multiple workspaces with independent ceilings off a shared pool, but the shared balance is still the common dependency. For teams running multiple unrelated products on the same account, that is worth thinking through.
Where other gateways are genuinely better, stated plainly
OpenRouter has a capability we do not: they can send a single prompt to multiple models simultaneously, collect the outputs, and synthesise them into one response. For applications that need to compare model reasoning or reduce reliance on any single model being correct, that is a real and useful feature. We do not have it. If that is your use case, OpenRouter is the right tool.
Requesty has invested specifically in European data residency controls. If your procurement process requires a guarantee that inference stays within EU infrastructure, Requesty has built preset configurations for exactly that. It is worth evaluating directly.
LiteLLM can run entirely on your own infrastructure. If your company policy requires owning the full stack, or if the cost of a managed service is not justified at your current scale, LiteLLM is where to start.
What the design is actually for
AI infrastructure tends to grow faster than the controls around it. It starts light, a developer key, a prototype, costs so low they barely register. Then something ships, usage grows, and the moment you want to understand what is happening or impose limits, you discover the controls were not built in. They have to be retrofitted around a system that was not designed for them, and that is expensive.
The decisions that determine how hard that retrofit is are made very early, usually before anyone is thinking about them as governance decisions at all. Whether a key has a ceiling or just an alert. Whether spend is visible by team and project or only in aggregate. Whether a compromised credential can run indefinitely or hits a limit that was set months earlier.
We spent a long time on those questions, and we built the product around the answers we arrived at. Hard caps that refuse rather than notify. Credits that create a natural ceiling before any workspace limit is applied. Plans that scale the management tooling, not the model access. All modalities through one balance, because the spend signal matters more than the administrative simplicity of separate accounts.
The tradeoffs are real. A cap misconfigured will break a service. A balance that runs dry takes every integration down at once. The controls that matter most cost money to unlock. We think those are the right tradeoffs because the alternative, unlimited exposure, notification-after-the-fact, no common view across modalities, has a failure mode that is harder to come back from.
But you should know what you are choosing, and we would rather tell you now.
Relixr routes across Anthropic, OpenAI, xAI, Google, DeepSeek, Nvidia, and community models. One endpoint, one key. Plans start free. View the model catalog or compare plans.