Will the AI be a
surprise invoice?

See the highlighted block above the contents list. The rest of this article explains the fear, then shows exactly how credits and hard caps remove it.

When a head of safety or a procurement lead evaluates AI in a safety platform, the first instinct is rarely “will it work?” It is “what will it cost, and can that cost run away?” The instinct is correct, because of how most AI features are sold.

The common model is usage-based AI pricing: you are billed for how much the AI is used, measured in opaque units of text processed. The trouble is that you cannot know that number in advance. How much text a task consumes depends on how long the input is, how long the answer is, and how many steps the work takes — all decided at run time, not at purchase.

• A busy reporting week processes more than a quiet one.
• A complex investigation costs more than a routine note.
• An enthusiastic user can quietly drive the meter up.

With that model, the invoice is a guess until it arrives. You cannot hand a finance committee a firm number, you cannot cap a team without building your own controls on top, and a single spike can turn a planned line item into an awkward conversation. For a safety function that has to run for years on a predictable budget, “we will see at the end of the month” is not an acceptable answer.

eAviora takes a different position. On every operator-facing surface, AI consumption is metered in plain credits. A credit is a single, stable unit of AI consumption. You read it the way you read any other balance: how many you have, how many a piece of work draws down.

Crucially, the operator is never shown the engineering underneath. There are no token counts, no raw dollar figures attached to an AI action, and no model or model-family names. Those details are real — they exist on the administrative side — but they are not the unit a safety or quality lead has to reason about. The job of a head of safety is to run a safety system, not to learn a pricing model.

This is the difference that removes the guesswork. With token-based pricing you have to understand input length, output length and step count to even estimate cost. With credits, you do not estimate — you budget. The platform draws down a known unit against a balance you set. There is no arithmetic to learn and no price list to keep track of as the underlying technology changes.

It is worth being precise about what credits cover. Credits meter the AI consumptioninside the product — the assistant, the specialist agents that propose classifications and draft analysis under human review. Your subscription— the real-money price of the platform — is a separate, contracted figure shown in normal currency. This article is about the first one: the AI consumption, and why it will never surprise you.

Metering in credits would not be enough on its own — a clean unit with no ceiling still runs away. The second half of the design is the control: AI usage is governed by hard budget caps, and a hard cap is one that the platform respects before it acts, not after.

The caps operate at three levels, so control is not all-or-nothing:

• Organisation. A ceiling for the whole operation, so AI spend across every team stays inside the planned envelope.
• Per-seat. A ceiling for an individual user, so one busy or enthusiastic person cannot consume the whole budget.
• Per-conversation. A ceiling for a single working session with the AI assistant, so a long, deep exchange has a known bound.

The mechanism is the part that matters. Every AI request is checked against the remaining budget before it runs. If the request would push consumption past the cap, it is blocked— the work does not happen, and no credits are spent. The platform pauses rather than overspends.

This is the inversion of the usage-based model. There, you spend first and discover the total later. Here, the limit is enforced in advance, so the worst case is “the AI paused and asked for more budget,” never “the bill was larger than we expected.” A spike cannot become a surprise, because the cap is the ceiling and the cap is checked first.

The clearest way to understand the design is to look at what actually appears on screen when the AI assistant does work.

What the operator sees. One consumption figure, in credits, alongside a confidence percentage for the AI output. That is the whole provenance the operator needs: how much this drew down, and how sure the assistant is. Two numbers, both meaningful, both readable at a glance.

What the operator does not see.No token counts. No raw dollar amount for the AI action. No model name, no model-family chip, no engineering telemetry strip. None of the internals that a usage-based tool pushes into the customer's face are present here, because none of them help a safety lead make a safety decision.

The result is a calmer, more honest surface. Where AI contributes, eAviora marks it clearly and shows credits and confidence — the AI accent is deliberate, not decorative. The operator can act on the assistant's proposal, see how confident it is, and know the cost is already inside a budget that cannot be exceeded. No one has to translate a token estimate into a finance line, because the finance line was the cap all along.

To see where the AI assistant and the specialist safety agents fit in the wider platform, read eavy, the agentic safety copilot and AI in aviation safety management. To discuss budgets and pricing for your operation, contact us.