Pay what you scale. Less as you grow.

The point of a self-service BI platform is that the people closest to a decision can answer their own question. Per-seat licensing prices exactly that behaviour. Every additional viewer is a line item, so the rollout stops at the analysts, everyone else gets a screenshot pasted into a deck, and the platform quietly becomes a report factory with a queue.

Qrly has no seat count in its price. Users, groups, projects and collections are unlimited, permissions run from NO_ACCESS through VIEW, EXPLORE, CURATE and MANAGE on collections and NO_ACCESS / RESTRICTED / FULL on data, and none of those levels has a price attached. Adding the whole finance team on Monday changes nothing on the invoice.

Metered compute — per query, per credit, per capacity unit — is the single biggest cost driver in modern analytics, because the meter runs fastest exactly when the tool is working. A dashboard that auto-refreshes, a drill-down that someone actually explores, a scheduled report that fans out per region: all of it is billable, and so all of it becomes something to ration.

Qrly bills none of it. It also gives you the controls to keep your warehouse bill down rather than adding to it: four opt-in cache tiers (in-process, persistent, materialized tables written into a database you own, and full table sync with CDC), a per-connection query governor with a bounded concurrency semaphore and wait queue, and a per-user daily query budget that is checked and reserved atomically before every run.

Revenue per analytics user rises steeply with company size, so a flat percentage would break at both ends. The tranche schedule tapers instead: 0.18% on the first €500k, down through 0.12%, 0.0525%, 0.027%, 0.017% and 0.0105%, to 0.006% above €500M. A €1M business pays 0.15% of revenue; a €100M business pays 0.022%; a €1B business pays 0.009%.

Because the tranches are marginal, the curve is continuous. There is no band you can cross by one euro and re-price your entire turnover, and no renewal conversation that starts with a surprise.

Seat forecasts are guesses and query volumes are unknowable in advance, which is why analytics budgets are so consistently wrong. Your revenue, on the other hand, is a figure your finance team already produces, already forecasts and already signs off.

So the Qrly line in next year's budget is arithmetic rather than a negotiation, and it does not move when the platform succeeds. The one thing that ties the fee to the product is that the product is supposed to help the number it is priced on.

You configure a per-organisation provider row with your own encrypted API key: Claude, OpenAI, Azure OpenAI (deployment-qualified), Gemini, Mistral, or a local Ollama, LM Studio, Jan.ai, LocalAI, GPT4All, LibreChat, Lobe Chat or Open WebUI endpoint. Any OpenAI-compatible service works out of the box, because the factory falls back to the OpenAI adapter for unknown types.

Point a local model at it and the marginal cost of an AI question is your own electricity. Nothing in the Qrly fee changes either way — the licence is a function of revenue, not of tokens.

The provider row carries the input and output cost per million tokens, the currency, the default model, a max-token cap and a budget period and amount. The admin AI providers page shows usage and spend charts against those figures, alongside a connection test and the org's security system prompt.

You get the accounting a resold-credits model gives you, without the margin that usually pays for it.

Agents are governed by a per-organisation daily token budget and a daily session cap — 50,000 tokens and 50 sessions a day by default — enforced as one of four independent stop conditions in the ReAct loop, alongside the step cap, a wall-clock deadline and provider errors. The budget is re-queried live mid-run so concurrent sessions cannot double-spend, with a pre-call check and a post-tool re-check on every iteration so a long run cannot overshoot by a whole turn.

A run that hits the ceiling ends as BUDGET_EXHAUSTED and says so, and budget state is surfaced to clients in the 429 response rather than failing silently.

Separately from AI, every user has a daily query budget — a per-user override falling back to an organisation default, and to 1,000 if neither is set. It is checked and reserved atomically before every query, race-safe via an upsert keyed on user and date, with bytes returned and AI tokens recorded asynchronously.

Administrators get a budget page with queries-today, active-user and over-budget KPIs, a date-ranged report and a per-user editor; users see their own budget on their profile. The per-connection query governor caps concurrency and queue depth on top, so a runaway dashboard cannot take a production database with it.