> ## Documentation Index > Fetch the complete documentation index at: https://docs.brussle.com/llms.txt > Use this file to discover all available pages before exploring further. # Pricing > Usage-based pricing: judgments, storage, writes, queries and pinning, with plans that set a minimum per billing period and what's included. You pay for what you use, and anything cold costs close to nothing. A document that nobody changes costs storage only. No seats, and no charges per record or per entity. Platforms pay a small fee per active tenant namespace past the ones their plan includes. There is no high-availability tier: redundancy is the architecture. ## Usage | Line | Meter | Price | | - | - | - | | Judgments | `judgment_units` | from \$0.25 per 1,000 judgments, [counted by size, 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. Writes count the data a write stores, as compact JSON in UTF-8: each operation's document id, `state`, `attributes` and other fields, and the outcomes you post. How your client encoded the request does not change it: whitespace, indentation and `\u` escapes of non-ASCII text are not counted, and neither are `wait_for` and `wait_timeout_ms`. Each write's response reports it as `usage.bytes_written`. ## Judgments Judging is billed in **judgments**. Each judgment answered counts by its **size class**, set by the 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. | Size class | Tokens of context and question | Counts as | Price each at the first tier | | - | - | - | - | | Standard | up to 2,000 | 1 judgment | \$0.00025 | | Large | up to 8,000 | 4 judgments | \$0.001 | | Extra-large | up to 32,000, the engine maximum | 16 judgments | \$0.004 | A yes/no judgment with a 40-token question over an 800-token context is standard and counts as 1, and one over a 4,500-token context is large and counts as 4. A choice between 100 described options whose question takes 3,000 tokens is large and counts as 4, 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 falls with volume, in graduated tiers like tax brackets: each tier's price applies only to the judgments inside it, so using more never makes your bill smaller. Tiers count your organization's billed judgments across all its namespaces in a [billing period](#billing-periods), each by its size class, and start again with each period. | Judgments in the period | Price per 1,000 judgments | | - | - | | First 100M | \$0.25 | | Next 900M (to 1B) | \$0.14 | | Next 9B (to 10B) | \$0.07 | | Above 10B | \$0.035 | So 1B judgments in a billing period cost \$25,000 + \$126,000 = \$151,000, an average of \$0.151 per 1,000. A backfill estimate prices its judgments at the tiers you will be in, counting what you have already used this billing period. Beside the cost it gives `duration_s`, how long the backfill takes if nothing else is judged meanwhile. Other judging comes first and can make it longer ([backfill](/concepts/judgments#backfill)). For a steady, high volume on Scale you can also prepay an [annual commitment](#paying-annually) for a deeper discount, priced from your measured workload. 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 are answered together. 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 each part's question come to at most 2,000 tokens is 5 standard judgments 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 when it moves judgments into a smaller size class; within a class, fewer tokens cost the same. 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 of 900 tokens, each is standard and counts as 1, so 8,000,000 judgments, \$2,000 a month; over a 6,000-token context each is large and counts as 4, so 32,000,000 judgments, \$8,000. ## Plans Every plan has judgments, answers, freshness, context recipes, related documents, composite judgments, shadow reports, budgets, webhooks, and calibration from the outcomes you post. Every plan is [charged as usage grows](#how-you-are-charged). Plans differ in their minimum per [billing period](#billing-periods) and what else they include: | | Developer | Team | Scale | | - | - | - | - | | Minimum per [billing period](#billing-periods) | \$19.00 | \$499.00 | \$2,500.00 | | [Tenant namespaces](#tenant-namespaces) included | 25 | 25 | 100 | | Webhook endpoints | 2 | 20 | 100 | | [Paid annually](#paying-annually) | \$190 a year | \$4,990 a year | a commitment priced for your workload | | Outcome rules | Preview | Yes | Yes | | Labelling queue | Preview | Yes | Yes | | The learning loop's lift on the judgment page | Preview | Yes | Yes | | Threshold recommender | Preview | Yes | Yes | | Context recipe tuning suggestions | Preview | Yes | Yes | | [Templates](/guides/templates) across tenant namespaces | No | Yes | Yes | | Pooled template priors: each tenant grows its own calibration from the pool | No | No | Yes | | [Audit and evaluation history export](/guides/export-history) | No | No | Yes | | [SSO](/guides/sso) | No | No | Yes | | SLA and support response times | No | No | Yes | | Annual commitment priced for your workload | No | No | Yes | The minimum is a floor, not an extra fee: usage counts toward it, and the invoice is never less than it. On Developer, the dashboard previews the learning loop from what every plan has: for example, the threshold the recommender would pick for a yes-or-no judgment, worked out from its calibration report. Wherever a feature your plan doesn't include appears, the dashboard says what it does and which plan has it. Webhooks, subscriptions and the events feed are on every plan, and deliveries are included: they're never billed. Your plan sets only how many webhook endpoints your organization can have. ### Signing up You choose a plan and add a card when you sign up, before you get an API key. A card is required on every plan, and there is no free trial: `default/quickstart` is the free place to try things ([below](#quickstart)). * **Billing starts when you add your card.** Your first [billing period](#billing-periods) starts that day, and is billed at least your plan's whole minimum, not prorated, on the invoice issued after it ends. Usage counts toward the minimum. * **Until the card is added**, your organization has no API key and is billed nothing. Leaving and coming back to the dashboard resumes sign-up where you left it. ### Billing periods You're billed per **billing period**: a month that starts on the day of the month your card was added at sign-up, in UTC, not on the 1st. A period runs from 00:00 UTC on that day to the same day the next month, so its last day is the day before. Add your card on 17 October and your periods are 17 October to 16 November, 17 November to 16 December, and so on. * **The day never moves**, even if you replace the card later. * **A month without that day** (the 29th to the 31st) starts its period on its last day, and the next period goes back to your day. Add your card on 31 January and your periods are 31 January to 27 February, 28 February to 30 March, then 31 March to 29 April. * **Every period is billed in full**, whatever its length: nothing is prorated. * **Each period's invoice is issued the day after its last day**, once that day is complete. * **What counts per period starts again with the next one:** the minimum, the [judgment tiers](#judgments), the [tenant fee](#tenant-namespaces), namespace [budgets](/behavior#budgets) and [quickstart's limit](#quickstart). The Usage page in the dashboard shows your current period's dates. ### Keeping a card on file Your organization must keep a card on file on every plan. If its card is removed, or expires, and there is no other card to charge: * **Owners and admins get an email at once.** Owners are asked to add a card whenever they open the dashboard, and everyone else sees a banner asking them to ask an owner. * **Nothing stops yet.** Your API keys keep working and judging continues, but no new API key can be created until a card is added. * **The next charge fails** without a card, and then the [failed-charge steps](#how-you-are-charged) apply: judging pauses 3 days after it first failed if it's still unpaid. * **Adding a card ends this** as soon as it's saved. Owners and admins also get an email 14 days before the card on file expires, so a new one can be added in time. A card your bank renews needs nothing. ### Changing plan An owner changes your organization's plan on the dashboard's **Plan** page, under Settings. Before you confirm a downgrade, it shows the date it takes effect and exactly what stops then, and while it waits the page offers to cancel it. Everyone else in your organization can see the plan and what it includes. * **An upgrade applies at once.** Before you confirm, the page shows the new minimum. The [billing period](#billing-periods) you upgrade in is billed at the new plan's whole minimum, charged to your card on file with that period's invoice. * **A downgrade takes effect at the start of a billing period, the first that starts at least 30 days after you ask.** Until then you keep your current plan, its features and its minimum, so each period you're on it is billed at its minimum. Asking for your current plan again cancels the downgrade. * **A downgrade never stops answers or deletes data.** From its date, the outcomes your outcome rules derive are kept but left out of calibration, and the outcomes they collected before are still used. The learning loop goes back to a preview. [Templates](/guides/templates) freeze: your tenants keep answering with the template's active version, and you can still read it, backfill it, delete it and detach tenants from it, but you can't change it, and it isn't applied to new namespaces. Below Scale, every tenant reads its template's pooled calibration again from the next nightly fit, new exports of audit and evaluation history are refused (files already exported stay downloadable until they are deleted), and [SSO](/guides/sso) stays connected, so your members keep signing in through it, but nobody new joins through it. Upgrading again lifts all of this: at once, and for tenant calibration at the next nightly fit. * **Nothing is prorated.** Each billing period is billed at the minimum of the plan you're on at its end, so the period you sign up or upgrade in is billed at that plan's whole minimum. A call your plan doesn't include returns `plan_required` (HTTP 402). Its `details` name the `capability`, the cheapest plan that includes it (`required_plan`), and your organization's `plan`. ## Tenant namespaces Platforms that give each of their customers a namespace pay a small fee per **active tenant namespace** each [billing period](#billing-periods), past the ones their plan includes: 25 on Developer, 25 on Team and 100 on Scale. * A namespace is **active** in a billing period if at least one judgment in it was billed in that period. A namespace you only write to or read from is free, and so is `default/quickstart`. * The fee is graduated like the judgment tiers, counted from your first active namespace, and the ones your plan includes come off the bottom: | Active tenant namespaces in the period | Price each | | - | - | | 1 to 1,000 | \$2.00 | | 1,001 to 10,000 | \$1.00 | | Above 10,000 | \$0.50 | * It's **added on top of your plan's minimum**, never counted toward it, and it stays out of namespace [budgets](/behavior#budgets). * Namespaces under a prefix you mark **non-production**, such as `acme/staging/`, aren't counted, though judging there is billed as usual. See [staging environments](/guides/staging-environments). * It follows the plan you're on at the end of the period, like the minimum. * It counts toward the charges made as usage grows, so a platform with many tenants is charged during the period, not only at its end. For example, a platform on Team with 2,000 active tenant namespaces and 72M judgments in a billing period: | Line | Cost | | - | - | | Judgments, 72M | \$18,000.00 | | Tier minimum (\$499.00) | already met by usage | | Active tenant namespaces: 2,000 (25 included) | (975 × \$2) + (1,000 × \$1) = \$2,950.00 | | **Invoice** | **\$20,950.00** | With 25 or fewer active namespaces there is no fee on Team. ## Paying annually On Developer and Team, an owner can pay for a year up front on the dashboard's **Plan** page for 10 months' minimum, 2 months free: Developer \$190 and Team \$4,990. * **The year is your next 12 [billing periods](#billing-periods)**, or the 12 after your current year ends if you're renewing. Paid on the day you add your card at sign-up, it starts with your first period. Its price is on the invoice of the period you pay in. * **Each period of the year, your invoice doesn't charge the plan's minimum**: your payment covers it. Usage above the minimum and any tenant fee are billed as usual, and charges during the period only start above the minimum. * **Paying for a higher plan's year upgrades you at once.** Upgrading during a year applies at once too: your year still covers its plan's minimum each period, and you pay the rest of the new plan's minimum each period. You can pay for a year of the new plan to start when the current one ends. * **A downgrade goes no lower than your year's plan until the year ends.** If you upgraded during the year and then ask for a plan below the year's, you move back to the year's plan when the downgrade takes effect, and on to the plan you asked for when the year ends. * **No refunds.** A year covers its periods whatever happens. * **Renewing is up to you.** Your organization's owners and admins get an email 30 days before a year ends. After it, each period is billed its minimum again. On Scale, an annual commitment is priced from your measured workload and paid up front. To set one up, email [scale@brussle.com](mailto:scale@brussle.com). ## How you are charged Every plan is paid after use, and so that no bill builds up, your card is charged during the [billing period](#billing-periods) 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 | * You add the card when you sign up, before you get an API key, and [keep one on file](#keeping-a-card-on-file) from then on. Only an owner changes it, from the Usage page in the dashboard: **Card and invoices** opens the billing page, where the card is changed and every invoice is listed. * Each charge paid on its first try moves you up one step, up to \$1,000. Your step carries over from period to period. * Until your first charge, or a [year paid up front](#paying-annually), goes through, judging pauses at \$500 of unpaid usage (10 times your step), and your organization's owners and admins get an email. Usage a year covers isn't unpaid. Judging resumes as soon as that payment goes through, and after it 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. * The [tenant fee](#tenant-namespaces) so far counts as unpaid usage too, less the namespaces the largest plan includes, so upgrading later in the period never leaves you charged more than your invoice. A period covered by a [year paid up front](#paying-annually) is charged only above its minimum. * Charges count toward your minimum. When the billing period ends you're invoiced the larger of your usage and the minimum, plus any tenant fee, less what you've already been charged. * If a charge fails, it's retried over the next few days. While it stays unpaid: 1. **When it fails,** your organization's owners and admins get an email with a link to pay the invoice, which any of them can use, and the dates of the next two steps. Owners and admins can also pay it from the Usage page in the dashboard. Paying an invoice this way doesn't change the card on file. 2. **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. Owners and admins get an email. 3. **14 days after it first failed, every API key turns read-only.** Reads keep working; writes are refused with `forbidden` and `details.reason: "payment_overdue"`. Owners and admins get an email 3 days before, and another when it happens. 4. **Paying resumes everything:** judging within a minute, writes within a few minutes, and owners and admins get an email that it's paid. Paying a failed charge also moves you down one step, never below \$50. * A period's invoice that fails counts the same way. Everything resumes only once nothing is left unpaid. The Usage page in the dashboard shows your current billing period's dates, your step, your unpaid usage, this period's charges, your tenant fee so far, and what a year paid up front covers. ## 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 × 1 (standard: 2k tokens of context and question) = 5,000,000 judgments | \$1,250.00 | | Storage | about 25 GiB | \$0.75 | | Writes | about 8 GiB | \$0.80 | | Queries | about 100 GiB scanned | \$1.00 | | **Total** | | **\$1,252.55** | That is above the Team minimum of \$499.00, so the invoice is the usage: about \$1,253 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 each [billing period](#billing-periods), priced at the first tier's \$0.25 per 1,000 judgments: 4,000 standard judgments. Judging in `default/quickstart` pauses before a request would take it past that, until your next billing period starts, and its answers read `stale`; writes and reads continue, and your organization's owners and admins get an email. 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 period's judging still counts toward the \$1.00, and the new namespace has the same size cap. ## Related topics - [Composite judgments](/guides/composite-judgments.md) - [Subscriptions](/concepts/subscriptions.md) - [Staging and test environments](/guides/staging-environments.md) - [Introduction](/index.md) - [Import existing data](/guides/import-existing-data.md) This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.