> ## Documentation Index > Fetch the complete documentation index at: https://docs.vainona.ai/llms.txt > Use this file to discover all available pages before exploring further. # Pricing > Usage-based pricing: judgments, storage, writes, queries and pinning, with a monthly minimum. You pay for what you use, and anything cold costs close to nothing. A document that nobody changes costs storage only. There are no seats, no charges per entity, and no high-availability tier: redundancy is the architecture. ## Usage | Line | Meter | Price | | ------------------------- | -------------------- | ------------------------------------------------------------------ | | Judgments | `judgment_units` | from \$0.10 per 1,000 judgment units, [less at volume](#judgments) | | Storage, history included | `bytes_stored_hours` | \$0.03 per GiB-month | | Writes | `bytes_written` | \$0.10 per GiB | | Queries | `bytes_scanned` | \$0.01 per GiB | | Pinned namespaces | `pinned_bytes_hours` | \$0.50 per GiB-month | Storage includes every evaluation ever made, so history is kept at close to our cost. ## Judgments Judging is billed in **judgment units**. One unit is one judgment answered, per started 1,000 tokens of its compiled context and its question together. The question counts as the engine reads it: its text, its criteria, and every option or level with its description. A yes/no judgment with a 40-token question over an 800-token context is 1 unit, and one over a 4,500-token context is 5 units. A choice between 100 described options whose question takes 3,000 tokens is 4 units even over a 100-token context, because the engine reads all of it. The price is the same whichever engine answers, so switching engines never changes your bill. The price per unit falls with volume, in graduated tiers like tax brackets: each tier's price applies only to the units inside it, so using more never makes your bill smaller. Tiers count your organization's billed units across all its namespaces in a calendar month. | Judgment units in the month | Price per 1,000 units | | --------------------------- | --------------------- | | First 100M | \$0.10 | | Next 900M (to 1B) | \$0.081 | | Next 9B (to 10B) | \$0.04 | | Above 10B | \$0.02 | So 1B units in a month cost \$10,000 + \$72,900 = \$82,900, an average of \$0.0829 per 1,000. A backfill estimate prices its units at the tiers you will be in, counting what you have already used this month. For a steady, high volume you can also prepay an annual commitment for a deeper discount, priced from your measured workload and paid up front. Contact us to set one up. These are not billed: * answers copied without an engine call because the document changed but its compiled context did not; * failed evaluations; * anything in `default/quickstart` ([below](#quickstart)). Every judgment answered is billed on its own, over the context and its own question, including judgments that share a context recipe and go to the engine in one request. Each part of a [composite judgment](/guides/composite-judgments) counts as a judgment over the context and that part's question, so a five-part composite whose context and part questions come to under 1,000 tokens is 5 units per document. Features cost nothing. The shadow job that measures a composite before it answers is free, like every shadow job. A tighter [context recipe](/guides/context-recipes) is the lever on cost: fewer tokens, fewer units. A judgment that reads [related documents](/guides/related-documents), the documents that point at the one it judges, is billed the same way, related documents included in the context. What decides its bill is how often it runs, and that follows how often the related documents change, so creating one that runs `on_change` shows a replay estimate of its monthly cost before you confirm. For example, 1M accounts judged about 8M times a month, with a 10-minute debounce, a 1-hour ceiling and a 40-token question: over their last few tickets, a context and question under 1,000 tokens, that is 1 unit each, 8,000,000 units, \$800 a month; over a 6,000-token context and the question it is 7 units each, 56,000,000 units, \$5,600. ## Monthly minimums Each plan has a monthly minimum. The minimum is a floor, not an extra fee: usage counts toward it, and the invoice is never less than it. | Plan | Minimum per month | Prepaid credit | | --------- | ----------------- | -------------- | | developer | \$16.00 | Yes | | team | \$256.00 | No | | scale | \$4,096.00 | No | ## How you're charged Developer is paid from prepaid credit. Team and Scale are paid after use, and so that no bill builds up, your card is charged during the month each time your unpaid usage reaches a threshold. The threshold grows as you pay: | Step | Charged each time unpaid usage reaches | | ---------------------------------- | -------------------------------------- | | 1, where every organization starts | \$50 | | 2 | \$200 | | 3 | \$500 | | 4 | \$1,000, every time | * Each charge paid on its first try moves you up one step, up to \$1,000. Your step carries over from month to month. * Until your first charge goes through, judging pauses at \$500 of unpaid usage (10 times your step). It resumes as soon as that charge is paid, and after your first charge this limit no longer applies. * A charge is for all your unpaid usage at the time, counted at the daily usage update, so it can be a little more than the threshold. Quickstart usage never counts toward it. * Charges count toward your monthly minimum. At the end of the month you're invoiced the larger of your usage and the minimum, less what you've already been charged. * If a charge fails, it's retried over the next few days and your organization's owners get an email. If it's still unpaid 3 days after it first failed, judging pauses: writes and reads keep working, and answers that need a new judgment read `stale` until it's paid. Paying resumes judging within a minute and moves you down one step, never below \$50. * A month-end invoice that fails counts the same way. Judging resumes only once nothing is left unpaid. The Usage page in the dashboard shows your step, your unpaid usage, and this month's charges. ## A worked example A support team judges 1M tickets a month with five judgments, each over a context and question of 2k tokens, on Team. | | Usage | Cost | | --------- | ------------------------------------------------------------------------------- | -------------- | | Judgments | 5 judgments × 1M tickets × 2k tokens of context and question = 10,000,000 units | \$1,000.00 | | Storage | about 25 GiB | \$0.75 | | Writes | about 8 GiB | \$0.80 | | Queries | about 100 GiB scanned | \$1.00 | | **Total** | | **\$1,002.55** | That is above the Team minimum of \$256.00, so the invoice is the usage: about \$1,003 a month. ## Quickstart Usage in `default/quickstart` is free: it is never billed, and never counts toward a charge. So that it stays a place to try things, its judging has a limit of \$1.00 of usage a month. Once it reaches that, judging in `default/quickstart` pauses until next month, and its answers read `stale`; writes and reads continue. To keep judging, create a namespace of your own. It also holds at most 10,000 documents and 100 MB: a write past that is refused with `too_large`, and a message that points you to a namespace of your own. Deleting `default/quickstart` and writing to it again resets neither: the month's judging still counts toward the \$1.00, and the new namespace has the same size cap.