AI credits are not your monthly cash bill
Understand included usage, subscription fees, overage and remaining credits. Worked Ollama examples separate consumption value from actual cash outlay.
A plan can include $60 of usage, charge a $20 subscription fee, and leave you with a $35 modeled bill. Those numbers are not contradictory. They describe an allowance, a fixed payment and a payment after overage. The confusion starts when a dashboard or comparison collapses all three into a single number called “cost.”
ModelBudgetCalc keeps consumption value and estimated cash separate. Consumption answers how much the work is worth at the selected provider's rate table. Cash answers how much the selected monthly plan would charge for that consumption under the modeled rules. Neither number alone tells you your bank balance, the amount to top up today or whether your account is about to stop accepting requests. Open the calculator to inspect those quantities side by side.
Five numbers that belong in different boxes
Consumption value is the dollar-valued usage generated by the workload. Its inputs include model rates, fresh input, cached input, output and any applicable peak rate. Subscription fee is the fixed amount for the selected monthly plan. Included usage is the amount of consumption covered by that fee. Overage is consumption beyond the included amount. Estimated cash adds the fixed fee and modeled overage.
Unused included usage is another useful diagnostic, but it is not a refund. It shows how much of a period's allowance would remain under the scenario. A higher number does not automatically mean you made a poor choice: access or concurrency may be valuable. It does mean that treating the entire allowance as money saved would exaggerate the benefit of the plan.
A receipt-style example
Take a synthetic Pro scenario with $75 of consumption. Under the current Ollama monthly pricing, Pro has a $20 fee and $60 included usage. The first $60 of consumption fits inside the allowance; the remaining $15 is overage. Estimated cash is therefore $20 plus $15, or $35. Consumption is $75, used included usage is $60, unused included usage is zero, and modeled cash is $35.
Now reduce the synthetic workload to $15. Consumption becomes $15, but the Pro fee remains $20. Used included usage is $15 and unused included usage is $45. The modeled cash bill is still $20, not negative $25 and not zero. On the same simplified rate basis, PAYG consumption expense would be $15 before any starter benefit. This is why small workloads deserve a PAYG comparison.
Increase consumption instead to $350 on Max. With a $100 fee and $300 included usage, the modeled bill is $150. A dashboard may prominently show that $350 was consumed, but this does not mean the plan comparison should report a $350 cash payment. Conversely, seeing a $100 subscription fee does not establish that the entire month will cost only $100.
The formula makes the distinctions explicit
Write C for consumption and A for included usage. Used included usage is the smaller of C and A. Unused included usage is the positive part of A minus C. Overage is the positive part of C minus A. Estimated cash is the monthly fee plus overage. These operations are simple, but naming them prevents a surprisingly wide range of spreadsheet errors.
For example, subtracting the full allowance from the fee produces a misleading negative cost. Subtracting unused allowance from next month's bill invents rollover. Counting the same allowance once as covered consumption and again as a cash rebate creates a double benefit. If your spreadsheet does any of those things, fix the accounting model before refining the token estimate.
Credits reset on a schedule, not when you finish a project
The official credit-plan announcement explains monthly resets on the subscription anniversary and no rollover of unused included usage. The active-days field covers work within one monthly billing period only, with a maximum of thirty-one days. Thirty is a synthetic default, not a claim that every billing period lasts thirty days or starts on the first calendar day. Do not combine workloads across resets and apply only one month's allowance.
This matters when you estimate the remainder of a period. If your reset is in four days, projecting thirty more days against the current remaining allowance overstates the immediate risk. If a large job will occur just after the reset, charging it against the current period understates the next period's demand. Use the actual remaining window from your account, while keeping account-specific details out of a public shared scenario.
How long will the remaining allowance last?
The horizon calculation needs four explicit values: included usage for the period, usage already consumed, expected daily consumption and days until reset. Remaining allowance is the positive part of included usage minus used usage. If that allowance is positive, divide it by expected daily consumption to estimate days until exhaustion. This is a pace calculation, not a prediction of the next exact billing timestamp.
For a synthetic example, suppose $40 remains, future consumption averages $8 per day, and the reset is seven days away. At that pace, the remaining allowance lasts five days. The next seven days consume $56, leaving $16 beyond the current allowance before reset. If the reset were only three days away, projected consumption would be $24 and this window would not exhaust the allowance.
A zero daily rate should read “no depletion at this pace,” not an impressive-looking infinite number. A zero remaining allowance should read exhausted now, even if future usage is zero. Those cases describe the current modeled allowance accurately without implying that the account is suspended or that paid credit is unavailable.
Why expense is not the same as top-up timing
A PAYG calculation values the consumption you expect to make. It does not know how much prepaid credit is already on your account, what purchase amounts are offered, when a card charge will occur or how any special balance is applied. A $12 consumption estimate is therefore not a guarantee that your next transaction will be exactly $12.
The same distinction applies to subscriptions with extra credit. This site does not connect to account balances or reproduce an invoice ledger. If your question is “What will leave my bank account today?”, use the provider's checkout and account statement. If your question is “What is the modeled cost of operating this workload for a period?”, the calculator is designed to help.
Do not move dollar labels between providers
A dollar of included usage only has meaning with the rate table and product terms attached to it. Two services can advertise the same dollar allowance while charging different rates for model usage or supporting different model variants. Comparing allowance size alone can conceal that difference. Even a familiar model family name is not enough to establish equivalent hosting, performance or token accounting.
This first version uses Ollama's current hosted rate table for every plan card. It does not reprice another provider's native cache fields as if they were Ollama's, and it does not convert a chat subscription into API credit. Keep the client, model, host and billing product distinct before making any comparison.
Use a forecast range, then check the real record
For a new project, build a low, central and high usage scenario. Change the number of requests, output length and cache share deliberately rather than multiplying the final bill by an unexplained safety factor. This reveals which assumptions matter and whether the lowest-cash plan changes across the range. For an existing project, inspect comparable past periods while allowing for changes in workload.
Do not imply that this forecast verifies an account or guarantees a saving. Taxes, currency conversion, annual commitments, legacy quotas, top-up rules and mid-cycle changes remain outside the model. Reconcile against your own account records when making a purchase. The plan comparison guide explains cash boundaries, while the cache and peak guide explains how consumption is built from tokens. Together they make the calculation auditable without pretending it is a bill.