View as Markdown

Pricing & usage

Explanation — what & why

Vectros is credit-based, pay-as-you-go: you are metered on what you actually do, and a single usage report shows where you stand. There is no seat licence to buy before you can make a call, and every plan includes a large monthly read allowance — so exploring and serving your own data is not what drives cost.

Usage is metered on two independent axes, kept separate on purpose because data-plane work and model inference have very different cost structures:

  • A monthly credit allowance covers data-plane work — record writes, document ingests (including the indexing they trigger), deletes, searches, reads beyond your plan's included read and data-out allowances, and the execution time of your trigger scripts. It resets each calendar month, and the usage report tells you how much of the period's allowance you have consumed.
  • A pre-paid inference balance covers AI calls — chat, RAG, and document-ask. It is a ledger, denominated in cents, that draws down as you make inference calls and is topped up out of band. It does not reset monthly the way the credit allowance does. New accounts start at $0, so the first AI call returns a 402 until you top up in the developer portal (Billing → Inference balance) — every non-inference operation works without it.

A property worth designing around: reads are effectively free at the volumes most applications target. Every plan includes a large monthly read allowance (and a data-out allowance) that grows with your tier; within it, reads draw nothing from the credit allowance, and they are exempt from the per-tenant business rate limit either way. Writes, deletes, searches, read overage, and script execution time (trigger firings and synchronous executions) count against the allowance; only inference draws down the balance. So a read-heavy application is cheap to run on the data plane, and the cost you should reason about is the cost of writing and asking, not the cost of reading back.

Trigger scripts are charged for the execution time they do not earn back. A trigger script runs your code for a variable span, while everything else here is priced per operation — so a script that runs for a long time while performing few or no billable operations does not cover the compute it consumes. Execution time is therefore metered, and the charge is built so you can check it:

  • Script execution bills at a flat rate per second, measured over each execution's whole span — resolving the rule, preparing the sandbox, running your code and recording the outcome are all inside it, so the span is legitimately longer than your script's own run time.
  • Most billable operations your script performs include execution time at no extra charge, and that included time is earned by the fee the operation already paid — it is not a separate allowance you can run out of. A record write, a document ingest and a read charged as overage each include a different amount, because they are priced differently — a read inside your plan's allowance is charged nothing, so it includes nothing. The exact total applied is reported back to you, so you never have to reconstruct it.
  • Each execution also carries a small fixed platform baseline, which covers the cost of running an execution at all (the queue hop, the idempotency writes, the dispatch reads).
  • You are charged only for time beyond what your operations included. A script that does real work and finishes promptly typically owes nothing at all; what this charge reaches is a script that spins, sleeps, or waits.

Three consequences worth designing for.

A read-heavy script inside its read allowance includes nothing. Those reads are charged nothing, so there is no fee for them to have earned included time from, and the script pays for its own span. Data-out (egress) overage likewise includes no execution time.

A firing we refuse before your script runs is never charged — a rate limit, a credit ceiling, a concurrency limit, a rule whose grant or script does not resolve, a deleted rule — and neither is an execution that fails on an internal platform error of ours.

But once your code is running, the span is charged whatever the outcome. Your script throwing, a timeout, a resource or write-buffer limit, a write conflict, or a call your script made that its permissions or declared manifest did not allow. Those last ones are decided while the script runs — a script can probe, recover, run for minutes and still be reported under them — so do not read them as refusals. The line is not "did it succeed" but "did your code get to run".

Writes and deletes cost the same. Deleting a record or document is itself a write — the item, its lookup rows, and its index entries all change — so a delete charges the standard write fee (the same base and per-index charges a write pays; for documents, the one-time ingest fee applies only when content is ingested). This applies to individual deletes and to tearing down an app context. Closing your account is different: account offboarding and full-tenant deletion are always free.

Usage is also broken down per environment. Your account totals are the sum of your live tenant and your test tenant, each reported separately, so you can see what production traffic costs versus what your test traffic costs — and the two reconcile up to the account total, for a credential with cross-context reach. Test traffic is metered like production, so a noisy test loop shows up in the report rather than hiding.

A credential confined to a single app context sees only that context's usage — its totals narrow accordingly, not the account-wide sum. See the Operations & trust reference for the exact narrowing contract.

How-to — read what you are using

Pull the current period's consumption — the monthly credit allowance and the pre-paid inference balance — in one call:

const usage = await client.auth.getUsage();
console.log(usage.credits.used);          // whole credits used this period
console.log(usage.credits.usedMilli);     // exact figure in milli-credits (1 credit = 1000)

getUsage returns the report object directly — it is not wrapped in the list envelope and does not paginate. Pass a { year, month } to read a prior period. The full report shape (per-environment breakdown, the inference balance, and the limits) is in the Operations & trust reference; the step-by-step is in the Operations & trust how-to.

Access to the report is itself scoped: a token needs the billing:r permission to read it. That lets you hand a read-only billing view to an internal dashboard without granting it any data access — a token scoped to, say, records:r cannot read your billing figures.

Notes & limits

  • Qualitative here by design. This page describes the model — what is metered, on which axis, and how to read it. Current rates, the monthly credit allowance, and inference pricing are quoted at sign-up / in your account, not pinned in the docs, so a stale number never ships here.
  • Reads are free within a generous allowance; writes, deletes, searches, and inference are not. Architect for that asymmetry — cache nothing you can re-read, but batch writes where you can, and treat delete churn as write churn.
  • Keep trigger scripts short, and do the work rather than waiting for it. Execution time is the one charge here that is not proportional to what you stored or fetched, so it is also the one a bug can run up: an accidental spin loop bills for its whole span. It is bounded — the charge draws the same monthly credit allowance every other operation draws, so a runaway script hits your credit ceiling and stops firing rather than billing indefinitely (on a plan that has a ceiling — an unlimited plan has no such backstop).
  • Two axes never net against each other. Running out of monthly data-plane credits does not consume your inference balance, and vice versa; each is reported and topped up on its own terms.

Where to go next