92% of your Claude token costs are avoidable. Here is why.

Researched and written by Deal Engine R&D Engineer, Amir Ishmuhametov.

We recently published a whitepaper on scaling AI in PE and M&A. One of the sections that has generated the most reaction is not the architecture framework or the operating model. It is the cost page.

Not because the numbers are shocking, but because they are recognisable. One figure doing the rounds at the moment captures it well: a single person, at a single firm, running £280 in Claude costs in one day. Not a fund. Not a team. One person. It is an extreme example, but the pattern behind it is not unusual. Firms are starting to see their Claude spend climb in ways that are hard to explain and harder to attribute. The usage is real, the outputs are useful, but the bill does not quite match the value.

In our whitepaper we set out the structural reasons this happens and what the right architecture looks like to fix it. This post pulls out the most common causes we see: the patterns that drive AI costs up quietly, and what each one tells you about what is missing behind your team's AI usage.

If any of these sound familiar, the whitepaper goes deeper: How to scale AI in PE and M&A

The problem is rarely the model. It is how the model is being used.

1. The same work is being done across your team, repeatedly

Claude has no visibility into what a colleague looked at yesterday, what another analyst concluded last month, or what your firm as a whole already knows about a company. When five analysts run similar queries, screening companies in the same sector, pulling updates on pipeline businesses, prepping for the same conference, each one starts from their own personal context, not the firm's.

The model does not know the work has been done before. It cannot. There is nowhere for that work to live across the team. So it rebuilds, pulls from your CRM, checks recent news, cross-references public data, and your firm pays for research it has already paid for.

Token costs multiply not because individual usage is inefficient, but because there is no shared layer capturing and structuring what the model produces across the team. Every good output disappears at the end of the session that produced it. For a team of five running similar queries daily, that is not a marginal inefficiency. It is a structural one.

2. Every session spends money before it does anything useful

That disappearing output creates a second problem. Because nothing is retained at a firm level, every new session has to gather context from scratch before it can begin. Claude pulls from the CRM, retrieves relevant documents, checks data sources, and assembles a picture of the company or market in question. That process costs tokens before a single useful output is generated.

The difference is measurable. A session that starts with pre-built, structured context uses around 8,000 tokens to complete a typical triage workflow. The same session starting from scratch, pulling from multiple data sources in real time, uses closer to 40,000. That is an 80% reduction in token volume, purely from having the context ready before the session begins rather than assembling it during.

Without that, every session pays a cold start tax. Multiplied across a team, across a year, it adds up to a significant and entirely avoidable cost.

3. One expensive model is doing everything

The cold start problem is compounded by something else: most firms are running all of their AI usage through a single frontier model, regardless of what the task actually requires.

Claude is handling investment memos and CRM field updates. It is generating nuanced thesis assessments and formatting Slack messages. It is doing the analytical heavy lifting and the administrative grunt work, at exactly the same cost per token.

Not every task needs a frontier model. Routine screening, data extraction, structured formatting, and entity matching can all be handled by cheaper models at a fraction of the cost. But without a system that routes tasks to the right model, everything defaults to the most capable and most expensive option available. The output quality is often no better. The cost is significantly higher.

When you combine pre-built context with deliberate model routing, routing cheaper models for volume work and reserving frontier models for reasoning and synthesis, the overall cost reduction reaches around 92%. That is the number behind the title of this post. It is not a token count comparison. It is what the full picture looks like when the architecture is working properly.

4. There is no visibility into what is driving spend

These first three issues share something in common: they are largely invisible. There is no attribution, no audit trail, no way to know whether costs are being driven by one analyst running expensive queries, a workflow that has grown inefficient over time, or a structural pattern across the whole team.

This is what makes the £280 figure so useful as a diagnostic. It is not just a striking number. It is what unattributed, unstructured AI usage looks like at its logical conclusion. Most firms will not hit that in a single day. But the conditions that produce it, no visibility, no governance, no shared structure, are present in almost every firm using AI at scale today.

Without visibility, there is no way to manage it. Costs accumulate with no clear owner and no obvious lever to pull. By the time the bill becomes a problem, the usage patterns driving it are already embedded in how the team works.

5. You are paying Claude to forget

The invisibility in point four makes the underlying problem harder to see, but it does not change what is happening. Every datapoint the model touches costs something. Every company profile it builds, every news summary it generates, every screening assessment it produces. If none of that is captured, structured, and stored somewhere the team can access, the next interaction starts from nothing and the cost clock starts again.

This is the compounding version of points one and two. Over time, the gap between a firm whose AI usage builds on itself and one whose usage resets with every session is not just architectural. It is financial. One firm pays for research once and reuses it indefinitely. The other pays again every time. The savings from points two and three do not just apply to a single session. They apply to every session, every day, for every analyst on the team.

The model is not the problem. The absence of anywhere for its outputs to go is.

What this means in practice

Taken together, these five patterns describe the same underlying issue: AI being used as a session-by-session tool rather than a system that accumulates value over time. The costs are real, but they are a symptom. The cause is structural.

None of this requires switching models or rebuilding workflows from scratch. It requires thinking about what sits behind the model: how outputs are captured, how context is shared, how tasks are routed, and how usage is governed. These are engineering and architecture decisions, and they have a direct and measurable impact on cost.

Our whitepaper sets out what that architecture looks like in practice, with real numbers from live workflows.

Download the whitepaper