Managing and optimising AI costs in business: the CADRE framework

AI spending looks like no other spending

Two years ago, "artificial intelligence" did not exist as a budget line in most companies. Today it is everywhere, and almost never in one place. Part of it arrives through assistant subscriptions paid per seat. Another part through a programming interface bill that varies each month with usage. Another through expense claims, when an employee subscribes on their own to the tool that helps them. And a last, invisible part sits in the time teams spend reviewing, correcting and integrating what these tools produce.

Finance teams know the result: spending that grows without anyone being able to say precisely what it buys. This is not a price problem. It is a governance problem. Spending you cannot tie to a use cannot be defended, and cannot be optimised either.

This article presents the framework we use at Kabaun Studio to take back control of this line. We called it CADRE, French for "frame", after its five steps: Cartographier (map), Attribuer (assign), Dimensionner (size), Réduire (reduce), Encadrer (govern). It applies to a small company paying for a dozen subscriptions as well as to an organisation running agents in production.

The three kinds of AI spending

Before optimising, you need to know what you are talking about. A company's AI spending falls into three families, each managed differently.

• Per-seat licences. A monthly subscription per user to a conversational assistant, a writing tool, an AI feature added to existing software. The cost is predictable, but it is paid whether the tool is used or not. The risk is the dormant licence.
• Usage-based consumption. Calls to a model through a programming interface, billed by the volume of text processed, measured in tokens. This is the engine of agents, automations and custom tools. Cost follows usage, which is healthy, but it can drift unnoticed.
• Costs around the model. Application hosting, the knowledge base, monitoring, integration with existing tools, and above all human time: review, correction, maintenance. None of these appear on an AI vendor's invoice, and they are often the heaviest.

Most optimisation attempts fail because they look at only one of these families. Cutting licences without looking at real usage penalises the teams that use them. Lowering an agent's consumption by degrading its answers increases review time. The framework below handles all three together.

C for Cartographier: know what you pay for

The first step is an inventory, and it is almost always longer than expected. The point is not to list contracts signed by procurement, but everything that costs money, wherever it comes from.

• Official subscriptions, with the number of seats paid and the renewal date.
• Individual subscriptions, found in expense claims and card statements. This is where real usage hides, the usage nobody organised.
• AI features included or added in existing software, sometimes switched on by default and billed as an option.
• Programming interface accounts opened with one or more model vendors, with their billing history.
• Applications and agents in production, with their hosting and associated services.

For each line, record three things: the amount, who pays, and the person who could say what it is for. When nobody can answer the third question, the line is already suspect.

This inventory has a second effect, often more important than the first: it reveals where AI is really used in the company, including where it was never decided. It is also a security question, since an individual subscription is often a tool that sees company data pass through without any framework. Our article on hosting an AI project in France covers this point.

A for Attribuer: every cost has a use and an owner

Attributed spending can be discussed. Global spending cannot. The aim of this step is for every cost line to be tied to a precise use, a team and a person accountable for it.

For licences, it is simple: a seat belongs to a person and a team. For usage-based consumption, it is real architecture work, and the work most often neglected.

• One access key per service. A support agent, a document extraction tool and a proposal generator should not share the same programming interface key. With one key each, the vendor's invoice reads directly by use, and a service that runs away can be cut without touching the others. This is the rule we apply on every tool we deliver.
• A consumption log. Each call records the service, the user or request behind it, and the volume consumed. Without that log you know the total, never the detail.
• An owner per service. Someone on the business side who knows what the service delivers and can weigh its cost against its value.

Once attribution is done, a unit of measure becomes possible: the cost per useful task. The cost of a sales proposal produced, a document processed, a question resolved without human intervention. That unit, not the monthly total, is what lets you decide. A service whose bill doubles because its usage tripled is doing well. A service whose bill doubles at constant usage has a problem.

D for Dimensionner: the right tool, at the right size

The third step checks that each use pays for what it needs, and no more. This is where the quickest gains lie, because they require no development.

Match licences to real usage

Subscription admin tools show who used what. A seat unused for several weeks is reassigned or removed. Conversely, an employee paying alone for a tool they use every day may be a sign that an official seat is missing. The aim is not to cut, but to align spending with usage.

Choose between licence and consumption

For individual, varied, unpredictable use, a per-seat licence is often the right formula: the user explores, the cost is fixed. For repetitive, framed use built into a process, usage-based consumption is generally fairer: you pay for the volume actually processed, and you can optimise it. Many companies pay licences for uses that are really processes, and would gain from turning them into a dedicated tool. That is the shift described in our article on automating a repetitive task.

Choose the model by task

Not every use needs the most capable model. Classifying a message, extracting a field from a form, rephrasing a sentence: these run very well on lighter, cheaper models. Keeping the most powerful model for tasks that justify it, long reasoning, delicate writing, complex document analysis, is one of the most effective levers. One tool can route each request to the right model. Our article on what a new model generation changes shows how to evaluate that choice on your own cases rather than public benchmarks.

Do not use AI where a rule is enough

The most underrated lever is also the simplest: do not call a model for what a rule, a formula or a database query does perfectly. A price calculation, a date check, sorting into a known category need no AI. It is cheaper, faster and more reliable.

R for Réduire: the technical levers

Once each use is properly sized, consumption itself can be reduced. These levers belong to tool design, and this is where engineering work pays off.

• Context caching. When every call resends the same instructions and reference documents, vendors let you cache that part, billed far lower on re-read. Structuring calls to benefit from it is often the biggest gain on an agent in production.
• Shorter instructions. Instructions grow over time, each fix adding a rule. Reviewing and pruning them regularly lowers the cost of every call.
• Targeted context. Sending the model the three relevant passages of a document rather than the whole document. That is the job of a well designed search over the knowledge base.
• Answers of the right length. Generated text usually costs more than text read. Asking for a short answer when a short answer is enough is a direct lever.
• Batch processing. What needs no immediate answer can run deferred, often at a lower rate with vendors that offer it.
• Hunting invisible calls. An agent that checks its own answer, rephrases the question, then summarises the result makes three calls where the user sees one. Each must earn its place.

One precaution: every reduction is checked on a set of real cases before being applied. A saving that degrades quality is paid for elsewhere, in review or errors. Our article on the cost of an AI agent in production details the measurement item by item.

E for Encadrer: so that it holds over time

The first four steps produce a healthy situation at a given moment. The fifth keeps it that way. Without it, spending drifts again within months, as new uses and new tools arrive.

• Ceilings per service. Each access key has a consumption limit, with an alert before reaching it. An agent running away through a loop or abuse stops by itself instead of producing a surprise bill.
• Per-user quotas on public-facing tools, so a single visitor cannot consume a month's budget alone.
• A short monthly review. One table per service: consumption, cost per useful task, trend, owner. Half an hour a month is enough once attribution is in place.
• An entry rule. Every new subscription or service goes through a light checkpoint: which use, which owner, which key, which ceiling.
• A review at every model release. Prices and capabilities change fast. Replaying your cases on a new model lets you benefit from a price cut or move down a tier without losing quality.

The indicators to track

An AI cost dashboard fits in a few lines. The ones we recommend:

• Cost per useful task, per service. This is the main indicator.
• Licence usage rate: the share of paid seats actually used over the period.
• Share of context served from cache, for agents in production.
• Unattributed consumption volume, which should tend towards zero.
• Human review time per task, where measurable. This is the hidden cost that tells you whether an optimisation degraded quality.

Each indicator is compared with itself over time, not with an external norm. What matters is the trend and the gap to usage.

The most common mistakes

• Cutting without measuring. Removing the most expensive subscriptions, without knowing which ones are used, often hits the most productive teams.
• Running everything through one key. The bill becomes unreadable, and one faulty service penalises all the others.
• Optimising unit price and forgetting volume. A cheaper model that needs twice as many exchanges to reach the same result saves nothing.
• Ignoring human time. A very frugal tool whose every output must be fully reviewed costs more than it seems.
• Banning instead of organising. Banning individual uses pushes them into the shadows. Organising them lets you measure and frame them.

The cost, and what it consumes

There is one more reason to manage this line, beyond the bill. Every model call consumes energy and compute. A tool sized to the real need, which does not call a large model for a simple task and does not needlessly replay a long context, is also a more frugal tool. It is one of the principles of our responsible AI memo: financial cost and environmental cost are managed with the same levers.

Where to start

The first step takes a few days: the inventory, the list of services, and one key per service for those that lack one. It is often enough to reveal the first savings, and above all to make the rest possible. Our engineers carry out this work at the client's site, with the finance team and the people who use the tools; it is one of the fields of our finance FDE offer.

To place your organisation before starting, our AI diagnostic asks the right questions in a few minutes.

Frequently asked questions

Should you favour per-seat licences or usage-based consumption?

It depends on the use. For individual, varied and unpredictable use, a licence is often better suited. For repetitive use built into a process, usage-based consumption is generally fairer and can be optimised. Many companies would gain from turning what they pay as licences into a dedicated tool.

What is a token, and why does the bill depend on it?

A token is the unit a model splits text into, roughly a piece of a word. Vendors bill the volume of tokens read and produced at each call. The length of instructions, of the context sent and of generated answers therefore drives the cost directly.

What is the quickest saving lever?

Most often, matching licences to real usage and no longer calling a model for what a rule does perfectly well. Neither requires development. For agents in production, caching repetitive context is usually the biggest technical gain.

How do you stop an optimisation from degrading quality?

By checking every change on a set of real cases before applying it, and by tracking human review time per task. A saving that multiplies corrections is paid for elsewhere.

Should individual AI subscriptions be banned?

Banning them pushes them into the shadows. Better to list them, understand the need they cover, and offer an official framework with the right data guarantees. Individual usage is often the best indicator of what is missing.