Paying by the token is a good way to try a model. It is a harder way to run a business on one. As workloads move from prototypes to production, and from single requests to fleets of agents, two properties of token APIs start to matter more than the headline price: every unit of success is metered, and every account is rate limited.
Token pricing meters the work you want more of.
The workloads enterprises want to scale are token-hungry by design. Coding agents read whole repositories. Evaluation suites rerun thousands of prompts. Document pipelines process every page that arrives. Running more of them in parallel is the point, and with a token-metered API, more parallel work means a larger bill and a sooner encounter with the provider’s rate limit.
That combination makes planning awkward. Budgets swing with usage the team is trying to encourage, and throughput depends on a quota negotiated with someone else.
A dedicated endpoint: your hardware, your URL, your key.
InfraOptimal sells dedicated inference endpoints priced by time. You choose an endpoint for your model and get dedicated hardware, your own URL and a key. The capacity is yours to use. There is no token quota: your hardware sets the pace, so you can send as much parallel work as it can serve.
Optimized endpoints come first in the console. Each is a prepared configuration whose card shows its price, hardware, and measured throughput and agent capacity, so you can see what the machine handles before you start it. Start opens one confirmation with the model, hardware, price, expected ready time and spend limit. For a model that is not in the catalog, a custom endpoint takes a supported Hugging Face checkpoint and recommends hardware for the workload, and the API also accepts your own serving container.
Choose
One endpoint, one price
The price, hardware and measured capacity are shown before launch, with billing increments.
Run
No token quota
Dedicated hardware sets throughput. Parallel requests are limited by what it can serve, not by a meter.
Stop
Pay for the time used
Stop releases the hardware. With a dedicated key, the URL and key stay the same for the next start.
Budgets are set before the first request.
Capacity pricing makes cost a function of hardware and time, which is something a finance team can plan. The platform adds controls on top. Credit is a prepaid balance, and each launch holds the funds it may use. Through the API, an endpoint’s policy can cap its rate, its spend per run, its total budget, its runtime and the number of simultaneous requests it accepts.
The edges are handled explicitly too. Where a provider cannot report capacity in advance, the console says so, and a launch that gets no GPU before its startup deadline stops with nothing charged and its hold returned. A failed launch says in plain words whether the hardware was obtained, whether the engine started, what was charged and what to do next.
Start, use, stop, with the same key.
Each optimized endpoint can have one dedicated key for your application. The same key starts the endpoint, runs inference and stops it, and the URL and key stay the same every time. An application can start capacity when a job begins and stop it when the job ends. The dedicated key cannot change limits, prices or keys, delete the endpoint or launch anything else.
Idle time is your decision. An idle endpoint is not stopped by default; its owner gets a warning email after 15 to 30 idle minutes, naming the endpoint and its price, with a link to stop it. Stopping on idle is an option you can turn on.
Built for agent workloads.
Dedicated capacity fits agent swarms especially well, because agents are the workload most constrained by token quotas. Claude Code, Codex, OpenCode and Cursor connect over MCP, and MCP can do everything the console can: an agent can quote, launch and stop temporary endpoints itself, and it states its usage plan before it launches. Each optimized endpoint’s guidance gives the agent count it was measured with, so a team can keep the hardware busy instead of guessing.
Underneath the pricing is the optimization work. Optimized endpoints launch with a configuration measured against the original model, and teams that want a running endpoint tuned for their own traffic can arrange it with us, with their consent to measure it, under the same rule that keeps the original model as the reference.
Pay for the machine, use all of it, and stop it when you are done. That is a pricing model you can put in a plan.