Baseten Pricing 2026: Costs, GPUs and Token Rates
Oct 31, 202615 min read
Because Baseten bills Model APIs per million tokens and dedicated GPU deployments per minute, the same model can cost very different amounts depending on how busy you keep it.
Baseten's an inference platform: it hosts models and serves them to your application over an API, whether that application is a chat interface or a workflow built in a tool like Activepieces.
A single call shows the scale. At Baseten's rates:
Baseten pricing: every current plan and rate
- A call with 10,000 input tokens and 1,000 output tokens on DeepSeek V4 Flash costs $0.0013 for input plus $0.00026 for output, about $0.0016 per run, which means you can treat cost as negligible in your API call volume decisions.
- The same call on DeepSeek V4 Pro costs about $0.017, roughly eleven times more, so you'll want to use Pro only for queries where the quality difference justifies spending eleven times as much.
| Billing route | Price | Inclusions | Limits |
|---|---|---|---|
| Model API: DeepSeek V4 Flash | $0.13 in / $0.028 cached / $0.26 out per 1M tokens | Shared hosted endpoint, pay per token | Rate limits not stated on the page; contact sales |
| Model API: DeepSeek V4 Pro | $1.32 / $0.132 / $3.96 per 1M | Same | Same |
| Model API: GLM 5.3 Fast | $2.10 / $0.21 / $6.60 per 1M | Same | Same |
| Model API: Nemotron 3 Ultra | $0.60 / $0.12 / $2.40 per 1M | Same | Same |
| Dedicated deployment | Per minute, by GPU type | Your own replicas of a model | Minimums and scaling terms decide the real bill |
Read the table and the split is plain: token pricing is transparent, while dedicated pricing depends on choices the rate card can't make for you. The next two subsections take each in turn.
Model API rates per million tokens
At $0.13 input, $0.028 cached and $0.26 output per million tokens, DeepSeek V4 Flash is the cheapest. Output costs only twice input here, so long answers hurt less than on any other listed model.
DeepSeek V4 Pro charges $1.32, $0.132 and $3.96, so output is three times input and a chatty workload costs far more than its prompt size suggests.
Pricing by model:
- GLM 5.3 Fast sits at $2.10, $0.21 and $6.60, the most expensive of the four per token.
- Nemotron 3 Ultra charges $0.60, $0.12 and $2.40, which makes output four times input, the widest gap in the set.
- Cached input is the lever: on V4 Pro and GLM 5.3 Fast it's one tenth of the input rate, so a long, repeated system prompt is nearly free after the first call.
- On Flash and Nemotron the discount is closer to 80%, still worth designing for.
Dedicated GPU rates per minute
When requests stop arriving, the meter keeps running: dedicated deployments charge for GPU minutes, not tokens. That's where utilisation matters.
VentureBeat reports that typical enterprise GPUs run at about 5% utilisation. At that level, you pay for twenty minutes of hardware to get one minute of work, so the effective per-token cost is twenty times what a fully busy GPU would imply.
Knowing the per-minute figure for each GPU type gets you only half of the calculation. The other half is how many minutes your replicas sit idle, which the following sections work through against the per-token rates above.
If you are running this arithmetic for your own team, see what the same workload costs on Activepieces.
Real monthly bill for one workload
For a ticket summariser at 50,000 requests a day, the Model API and a scale-to-zero GPU land about $30 apart per month. An always-on GPU costs roughly $1,000 more, because most of that extra money buys idle minutes.
Take a support-ticket summariser:
- The volume is 50,000 requests a day, or 1.5 million a month.
- Each request sends 1,500 input tokens and returns 200 output tokens.
- Every rate below is my assumption, not Baseten's rate card: $0.60 per million input tokens, $2.00 per million output tokens, and $4.00 per GPU-hour.
- Swap in your own numbers, because the conclusion moves with them.
Model API bill
Start with input: 1.5 million requests × 1,500 tokens, or 2,250 million tokens. At $0.60 per million that's $1,350. Output is 300 million tokens at $2.00 per million, or $600.
The total is $1,950 a month. Idle cost is zero, since you pay per token and nothing else, so a quiet weekend costs nothing. The risk is on the other side: the bill scales linearly, so doubling traffic doubles it.
Dedicated GPU bill, always-on versus scale-to-zero
Assume one GPU handles a summary in about one second with batching. That's 50,000 seconds of work a day, or about 14 hours of a 24-hour day. The replica is busy 58% of the time and idle for the other 10 hours.
Run the GPU always-on and billing comes to 730 hours × $4.00, or $2,920 a month. Ten idle hours a day is $1,217 of that, paid for a GPU doing nothing.
That's not unusual: VentureBeat reports 79% of companies say their GPUs sit idle at least half the time. So even a 58% busy replica is better than many, and still loses to the per-token bill.
When traffic stops, scale-to-zero stops billing. Assume 16 billed hours a day, the 14 busy hours plus two hours of warm-up and idle timeout. That's 480 hours × $4.00, or $1,920 a month, with $240 of it idle.
The catch is cold starts. I assume a two-minute model load, so the first ticket after a quiet spell waits that long, and a summariser behind a live agent screen will notice.
| Ticket summariser, 50,000 requests/day | Monthly cost | Idle cost | Latency risk |
|---|---|---|---|
| Model API | $1,950 | $0 | Low; no model load on your side |
| Always-on GPU | $2,920 | $1,217 | Lowest; the replica is always warm |
| Scale-to-zero GPU | $1,920 | $240 | Highest; about two minutes on the first request after idle |
Scale-to-zero wins by $30, which is noise next to a rate change or a traffic spike. The decision is really between paying for tokens and paying for minutes, and the minutes only win when you keep the replica busy well past 58%.
If that summariser is one step in a larger ticket-triage process, Activepieces can call the Baseten endpoint from an HTTP step, and the run is the meter: 1 credit per flow run, whether triage is the two-step workaround or a ten-step flow with separate checks.
Zapier bills per task, so every extra step you add for reliability raises that bill; here it doesn't. Baseten's token or minute charges stay on Baseten's invoice either way.
Hidden costs and limits Baseten users hit
You will not find three things on the rate card: replica time billed while idle, latency paid on cold starts, and plan limits that cap how far you can scale. Each moves the break-even point you just saw.
Baseten idle replica costs and autoscaling settings
If a replica is running, it is billing, whether or not it serves a request. Two settings decide how many such minutes you buy: the minimum replica count and the scale-down delay.
If the minimum is above zero, you pay for that floor around the clock, including nights and weekends.
Leave the scale-down delay long and the same thing happens more quietly, because the replica lingers after traffic drops and bills while doing nothing. Set the delay for your worst traffic spike and you've bought idle time for every ordinary day.
Read your autoscaling settings as a line item, not a tuning detail.
Baseten cold starts versus always-on GPU replicas
Scale to zero and the idle bill goes, but the cold start comes back: the time to provision a GPU and load the weights before it can answer the first request. Larger models take longer.
The cost lands in user-facing latency, or in a minimum replica you keep warm to avoid it, which puts the idle bill back. You're choosing between paying in dollars and paying in waiting.
Plotted as monthly dollars against GPU utilisation, the always-on H100 line is flat because the replica bills regardless of traffic. The per-token API line rises with usage, and the point where they cross is break-even.
Keeping a replica warm to dodge cold starts is a decision to sit on the flat line.
Whichever setting you change, it either lifts that flat line or pushes the crossing to the right, so the break-even you calculate from the rate card is a best case.
Baseten Model APIs rate limits and plan caps
Billing per token does not mean unlimited use: Baseten also throttles Model APIs. Request and token rate limits apply, and a workload that bursts can hit them before it comes near a budget ceiling.
You may have to move to dedicated GPUs for capacity reasons, not cost reasons, and then pay the flat line at low utilisation.
On dedicated deployments there are ceilings of their own, on concurrency and on how many replicas you can scale to. Access to particular GPU types can also depend on your plan.
Check the limits for your tier before you size a workload, because a cap you discover in production becomes an unplanned migration.
For enterprise features such as network isolation, compliance commitments and higher capacity, Baseten goes through sales, and I treat any tier I can't price without a call as an unknown. Before committing, ask in writing for:
- the minimum commitment on each plan
- the rate limits and concurrency caps that apply to you
- which GPU types your plan can reach
- any fees for the enterprise features you need
Leave an unpriced line item unasked and it can change the comparison as much as the GPU rate does.
Worth checking against a plan that does not meter every step: one credit covers a whole run on Activepieces.
Baseten versus Modal, Together AI and Fireworks
If your traffic is steady on a dedicated model, Baseten suits it; if it is bursty custom code, Modal does. Together AI and Fireworks are usually the better fit when per-token serverless access to a popular open model is all you need.
I've left published GPU rates out of this comparison. They change often and differ by GPU, and a rate quoted without a verified check date would mislead you. The billing mechanics are what stay stable, and they decide the bill.
| Vendor | What you pay for | Idle behaviour |
|---|---|---|
| Baseten | Per token on Model APIs; per minute of GPU time on dedicated deployments | Dedicated deployments can scale to zero, but a replica minimum above zero bills while idle |
| Modal | Compute time on your own code, metered finely | Built around scaling to zero, so idle containers stop billing |
| Together AI | Per token on serverless models; time-based billing on dedicated endpoints | Serverless has no idle cost; dedicated endpoints bill while they exist |
| Fireworks | Per token on serverless models; GPU-time billing on on-demand deployments | Serverless has no idle cost; on-demand deployments bill while they run |
Look across the rows and all four share the same split: a per-token path with no idle cost and a GPU-time path where idle time is yours. The rivals differ mostly in how they package the second path.
So the rate card matters less than how many hours your GPU sits waiting.
Who suits whom:
- Baseten is a good fit if you run one model, often a custom or fine-tuned one, at steady load. The dedicated GPU is paid for either way, so high utilisation is what makes it cheap. At low utilisation, the minimum replica and cold-start behaviour from the previous section start to dominate.
- Modal is the cheaper choice when traffic arrives in bursts and you can tolerate a cold start. You pay for work done rather than for a warm replica, and your own code, not just a model, can run on it. The cost is that you own more of the engineering.
- Together AI and Fireworks are the cheaper choice for a standard open-weight model at low or uneven volume. Per-token pricing has no replica to keep warm, so a quiet week costs almost nothing. Both also sell dedicated capacity, so you can compare them with Baseten on the same utilisation maths.
Before you rely on a free credit or a minimum, check each pricing page, because these vary by vendor and change often. Treat a credit as a way to measure your real utilisation, not as a discount to build the budget on.
Be most careful with enterprise options. All four will move you to committed or private capacity through a sales conversation.
Until a quote exists you can't model that tier, so run your break-even on the published self-serve path and treat any negotiated price as an upside you haven't yet seen.
What Activepieces does about this
Activepieces can't change Baseten's rate card, but it can put the utilisation figure in front of you, which is the number the break-even depends on.
A flow can
- call a Baseten Model API or a dedicated endpoint through the HTTP integration
- read the token counts the response returns
- write each run to a table or sheet
A scheduled flow can then total the day's spend and message you when it drifts from the projection you built.
Most teams only find out that a replica was 20% busy when the invoice arrives, and a logged flow lets you see it within a day.
It also helps you raise utilisation, which is the only thing that makes the dedicated route pay. Work that nobody is waiting on, such as overnight ticket summaries or backfills, doesn't need to arrive one request at a time.
A schedule trigger can collect it and send it in one window, so a scale-to-zero replica does its busy hours back to back and then shuts down.
For the cold start, a flow can branch on the first response, wait with a delay step and retry, so a two-minute model load becomes a handled case instead of a failed call.
Branching can also send small or urgent requests to the per-token Model API and batch the rest to your own GPU.
On cost, the orchestration layer shouldn't add a second meter to the bill you're trying to understand. Activepieces' community edition is open source under the MIT licence, so you can self-host it and run flows on your own infrastructure.
On the hosted cloud, a run is 1 credit however many steps it has, so adding a logging step or a retry branch for reliability doesn't raise the charge.
Baseten's tokens and GPU minutes remain on Baseten's invoice, and that invoice is the one worth watching.
I can't point to a benchmark showing this saves a fixed percentage, because the saving depends on your traffic and on how idle your replicas are today.
What you can check is concrete: build the logging flow first, run it for a week against your real workload, and compare the measured utilisation to the 58% in the summariser example.
If the replica is busier than that, the dedicated GPU deserves a closer look. If it is much quieter, the data has told you to move back to per-token pricing, and you haven't paid for a commitment to find that out.
Frequently asked questions
Does Baseten have a free tier? Treat any free credit as a trial allowance, not a pricing tier you can plan around. Check what your account shows at sign-up, but run your break-even without it, because credits end and the utilisation maths doesn't.
Is Baseten billed per minute or per hour?
Per minute, not per hour, for dedicated GPU deployments. A replica that runs for twenty minutes costs twenty minutes of its hourly rate, so bursty traffic is cheaper than the hourly rate card suggests.
Model APIs are different: they are metered by usage (tokens for language models), so there is no idle GPU time to pay for. The per-minute meter only matters once you run your own replicas.
Can I bring my own model to Baseten? Yes, on dedicated deployments. Baseten packages custom models with Truss, its open-source framework, and runs them on GPUs you size yourself.
Model APIs cover only the models Baseten hosts. Your own weights therefore put you on the dedicated side of the cost comparison, where replica minimums and cold starts decide the bill.
Does Baseten charge when a deployment is scaled to zero?
No GPU time accrues while no replica is running, but the saving has a price. The next request waits for a cold start while a replica spins up, so the cost shows up as latency instead of dollars.
If your users can't tolerate that delay, you will configure a minimum replica count, and then you pay for idle time again.
When is a call to sales needed for Baseten?
Only for the enterprise tier, where pricing is negotiated rather than published. Self-serve usage, covering Model APIs and dedicated deployments, can be priced from the public rates alone.
On the enterprise tier, if a quote is the only way to learn a number you need, model the self-serve path first and treat the negotiated figure as an upside you haven't yet seen.
Related reading
References
Running the numbers
See what the same workload costs here.
Free forever plan, and every paid plan self-hosts at no extra cost.
See pricing Talk to sales
