Infinite tokens for a finite time
Some AI work is bounded in time and unbounded in tokens: a model to improve, an evaluation campaign, a launch, a backlog to process. For that work, counting tokens is the wrong unit. infinitetokens reserves training clusters and inference for one scope of work, on your own endpoint, for 3, 6, 9 or 12 months. You pay for the platform and the term, never per token. This article explains the idea, what is in a reservation, and when it does not fit.
The problem: bounded work, unbounded tokens
Think of the work a model team does in a quarter. It tunes a model on new data. It runs a human-feedback campaign. It evaluates a dozen variants against a test suite, then evaluates them again after a fix. It generates synthetic data to fill a gap. It prepares a product launch and needs to know that the endpoint will hold.
The scope of that work is known. Everyone can say when it starts and roughly when it ends. What nobody can say is how many tokens it will use. The honest answer is "as many as the experiments need", and the experiments change as the results come in.
A per-token meter turns that uncertainty into a budget fight. Each new run needs sign-off. Each retry is a cost. The team slows down, or the finance team sees a number it did not plan for.
The idea: infinite tokens, for a finite time
infinitetokens takes the opposite approach. The time is finite and agreed. The tokens inside that time are not counted.
You bring a scope of work. We reserve platform capacity for it: training clusters and inference, on your own endpoint, for the length of the work. You are billed for the platform and the term. What you send through it is not metered.
Our short test for fit is a single sentence: if the work is bounded and the tokens are not, it fits.
What is in a reservation
Your own endpoint
Your work is served at an address named for your organisation: <company>.infinitetokens.ai. Your pipelines, harnesses and tools point at that one address.
Reserved capacity, not shared capacity
Capacity is held for you. It is not given to someone else when demand rises elsewhere on the platform. That matters for work that must run around the clock, such as a long training run or an evaluation that has to finish before a release.
Training and inference on one platform
The platform covers both sides of model engineering and serving. Training clusters are for building and improving a model. Inference is for serving it: running evaluations, generating data, answering production traffic. Having both on one reservation means the model you improve and the endpoint you test it on are in the same place, agreed in the same contract.
Your choice of open models
We run open-weight models on open-source serving engines. The models your work needs are chosen with you. Open weights matter here: you can improve the model, evaluate it and serve it without asking a model lab for permission.
Isolation from other customers
Your workload is separated from other customers. For model work this is a practical matter: results should not be affected by someone else's burst, and your data should not sit beside theirs.
Examples of scopes that fit
These are examples, not a definition. Any organisation with a known scope and a known duration can use it.
- Improving a model. Reinforcement learning from human feedback (RLHF), fine-tuning and distillation data. These workloads run many experiments and trials in parallel, so tokens are consumed far faster than a budget forecast usually allows.
- Evaluation and red-teaming campaigns. A suite is run against many variants, often several times, and the useful answer is the one you get after the fifth pass, not the first.
- Agent and product launches. A launch needs guaranteed headroom for the weeks around it. Reserved capacity gives you that without buying a permanent fleet.
- Bulk processing. Document backlogs, code migrations and data labelling are large, finite jobs. The input is known; the token count is not.
- Research programmes. Many experiments in parallel, over a fixed period, with results that decide what happens next.
How a term works
The term is fixed: 3, 6, 9 or 12 months. Which one fits depends on the work.
| Term | Typically suits |
|---|---|
| 3 months | A single campaign, an evaluation round, a launch window, a backlog |
| 6 months | A model improvement cycle with more than one iteration |
| 9 months | A programme that spans a product release and the work after it |
| 12 months | A standing research or model-engineering function |
Treat the table as a starting point. The scope, capacity, models, term and endpoint are all agreed with you.
At the end of the term you have two choices: extend it, or hand the capacity back. Nothing is left running that you did not agree to.
How we size it
Sizing is where reserved capacity succeeds or fails. We do not guess. The same method that sizes our shared platform sizes your reservation:
- Describe the work. The scope, the models, how many things run at the same time, and how the work moves through a day.
- Measure. Our benchmark harness replays real agent sessions against an endpoint at rising concurrency and finds the knee: the load at which speed starts to fall.
- Size to a floor. We size users and sessions per GPU so that nine in ten requests stay above an agreed speed floor.
- Reserve. We set inference capacity aside for the agreed term, and the training clusters your scope needs.
The detail is on our technology page. The principle is that capacity is a measurement, not a promise made before testing.
An illustration
This example is hypothetical and has no figures, on purpose.
Imagine a team that must improve a model's behaviour before a launch date. The plan has three phases: collect human feedback on outputs, tune the model, and evaluate the result against a fixed suite. Each phase feeds the next, and each can be repeated if the results disappoint.
On a metered API, the team estimates tokens for one pass, multiplies by the number of passes it hopes to need, and adds a margin. The estimate is wrong the first time the evaluation shows a regression, because the fix means another round of everything. Someone has to ask for more budget in the middle of the critical path.
On an infinitetokens reservation, the team and MIRASTACK LABS agree the term, the models and the capacity at the start. The team reruns the evaluation as often as it needs. The only date that matters is the end of the term, and the team can see it from day one. If the work runs long, the term can be extended.
How this compares with the other ways to buy
Choose the unit that matches the work.
- A pass for one developer (endlesstokens) is right for individual use.
- Seats for a workforce (unlimitedtokens) is right when many people use models every day and the need is steady. The unit is the person.
- A reserved endpoint (infinitetokens) is right when a scope of work needs a large, guaranteed block of capacity for a fixed time. The unit is the term.
- An AI factory (AI Factory) is right when the capacity must sit in your own data centre, on your own domain. The unit is the site.
A metered API is still the right tool for occasional use, and for the frontier proprietary models that only their labs offer. We do not resell those.
When infinitetokens is not the right fit
We would rather say this plainly.
- The work has no end date. An open-ended need is better served by seats or by an AI factory.
- Use is occasional. Reserved capacity that sits idle is not good value. Use a pass or a metered API.
- You need a proprietary model. Reserved capacity here is for open-weight models.
- The data cannot leave your site. If the capacity must sit inside your own walls, the right answer is an AI factory and not a hosted endpoint.
What you do next
Send us the scope of work in a few lines: what you want to build or run, which models, how many things run in parallel, and the dates that matter. We will propose a reservation: capacity, models, term and endpoint. We will tell you if another option fits better.
Talk to us
Talk to us or write to hello@mirastacklabs.ai. You can read the offer in short form on the infinitetokens page.