Plans & seats

Lokrix uses a hybrid commercial model: a tiered subscription that covers seats and platform features, plus usage credits that meter the one cost that scales with how much you measure — live runs against the real answer engines. Seats are for people; credits are for engine responses.

Why the model has two parts

A live engine run is the dominant cost of the platform, and it is multiplicative — prompts × engines × sample count × cadence. Bundling that into a flat seat price would either overcharge light users or throttle heavy ones. Splitting it lets a small team on a modest plan still run deep, statistically honest scans by topping up credits when they need to, without paying for seats they do not use.

How seats and usage credits meter live runsPlan seats and usage credits feed a metered live-run step (cost equals engines times prompts times K samples), which writes to a per-tenant metering ledger.Plan seatstiered subscriptionUsage credits1 credit ≈ 1 responseLive runs meteredengines × prompts × KMetering ledgerper-tenant balance

Seats and roles

A seat is a named member of your organization. Members carry a role — Owner, Admin, Editor or Viewer — that governs what they can do across every workspace and property. Adding a member consumes a seat on your plan; Viewers who only read reports still occupy a seat.

  • Owner / Admin — manage billing, members, integrations and workspace settings.
  • Editor — create properties, edit the prompt universe, and launch scans (which spend credits).
  • Viewer — read scores, trends and reports; no credit-spending actions.

Where billing lives in the hierarchy

Lokrix is organised as Organization → Workspace → Project (a Project is a tracked property). Subscriptions and the credit balance are held per workspace: every property inside a workspace draws live runs from the same credit pool, so you can budget across the sites one team owns. See workspaces for the full tenancy model.

What actually spends credits

Seats and the subscription are fixed; only live engine runs spend credits, where 1 credit ≈ 1 engine response. The predictive scoring model — used for everyday scores and what-if simulation — does not spend credits, so Lokrix defaults to it and escalates to live runs deliberately. For the mechanics of metering, see credits & metering, and to keep spend predictable set budgets & spend caps.

Related

  • Scan cost — how prompts, engines, samples and cadence multiply into a credit estimate.
  • Live vs. predictive — when a run is metered and when it is free.