AI Model Costs and Agent Workloads in Financial Services

AI Model Costs and Agent Workloads in Financial Services

A business case for an AI agent is a snapshot of prices on the day it was written. When model vendors report lower unit costs, that snapshot goes stale, and the team that wrote it rarely knows which workloads to revisit first. In October 2026, Innovify's market monitoring logged Anthropic's cache pricing for Haiku 5.5 and Sonnet 5.5 as a fall in frontier model unit costs. The question for a UK platform team is not whether to welcome that. It is what to re-plan, and what to leave alone until the evidence improves. This article sets out what the evidence supports, what it does not, and how a CTO or head of product can rework high-volume agent workloads in financial services without building on claims they cannot yet verify.

What the evidence supports, and what it does not

Start with the reported fact. On 7 October 2026 our market intelligence recorded that frontier model unit costs were falling. The items behind it were Anthropic's cache pricing for Haiku 5.5 and Sonnet 5.5, and OpenAI's launch of GPT-6 with a feature it calls "Intelligent UI". The sources are the vendors' own newsrooms. These are vendor-authored claims, they come from a single source, and we rate the confidence as medium.

Two details matter. First, the OpenAI item is not a pricing story. Our reading is that interface-generating models widen the options for client-facing design, which is a separate question from workload cost. Second, the evidence we hold does not include the price lists themselves. So this article quotes no prices, no percentage savings and no break-even points. A figure we could not trace to a source would do more harm than having no figure at all.

Now the interpretation, which is ours and not the vendors'. Lower unit costs for small and mid-tier models change the economics of high-volume agent workloads: triage, classification and subagent tasks. That is a direction of travel. It is not a number, and it is not a promise that any particular workload now pays for itself.

This is why the article is shorter than most we publish. The evidence is thin, and padding it with confident-sounding detail would be the wrong response. What we can offer is a way of thinking that works whatever the current prices turn out to be.

Why high-volume workloads are the ones that move

The arithmetic is simple. The cost of an agent workload is the number of calls multiplied by the cost of each call, plus everything else you need to run it safely. When volume is low, the cost per call hardly matters, and the "everything else" dominates. When volume is high, the cost per call becomes the largest line in the model, so a change in unit price moves the business case.

That is why the workloads named in the intelligence are the repetitive, narrow ones. They are the places where a lower price per call is multiplied the most.

Triage and classification

Triage and classification are the clearest candidates. Sorting inbound customer emails by intent, or routing a case to the right queue, is a narrow task repeated many times. It is also a task where a smaller model may be good enough, provided you can show that it is on your own data. The word "may" is doing real work in that sentence, and we come back to it below.

There is UK evidence that this kind of work is moving into production. LHV Bank took an AI agent for customer emails live in the UK, and the reported path was a proof of concept followed by production. That mirrors the pilot-to-production journey many teams describe, and it is the kind of high-volume, repetitive task where unit cost can matter.

Subagents

In an agentic design, a lead agent breaks a job into parts and hands narrow tasks to subagents. The intelligence names subagents among the high-volume workloads. Our analysis is that each narrow, well-specified subtask is a separate decision: does it need the larger model, or would a smaller one do?

Model routing

Put those together and you have the design pattern usually called model routing. Each task goes to the smallest model that does the job acceptably, and harder judgement stays with a larger one. The important design point is that the choice of model should be a configuration, not something hard-wired into the workflow. If a price changes, or a new model arrives, you want to re-route a task by changing a setting and re-running your tests, not by rebuilding the workflow.

Where agents are already running in financial services

It helps to separate where agents are being deployed from where cost is the constraint, because they are not always the same place.

Our October intelligence points to finance operations as the first production home for agents. PYMNTS reported on Nestlé with SAP agents, and on US regional banks putting AI into operations. Collections, accounts payable and banking operations are the recurring examples. In a related development, Visa, BILL and Billtrust are running a live pilot of AI agents paying business-to-business invoices through Visa Intelligent Commerce. Visa describes the pilot as a first; that is Visa's own claim, and we have not verified it independently.

What these have in common is not model pricing. It is that approvals, supplier relationships and audit trails already exist. Where those controls are in place, delegated actions are easier to authorise and to insure than open-web consumer purchases. None of the reports we have says these deployments were chosen because of model pricing. We would be inventing a link if we said otherwise.

That is a useful corrective for a business case. If the first production agents are appearing where governance is already strong, governance, not unit cost, is probably what decided where to start.

How to rework a business case when prices move

You cannot control vendor pricing, but you can build a business case that survives it changing. Here is a sequence we would use.

1. Inventory by task shape, not by project. List each agent workload and, for each, note its volume, how tolerant it is of error, what happens when it is wrong, and whether a person reviews the output. High volume plus low consequence of error is where to look first.
2. Make price a dated, sourced input. Put the unit price in one cell, with the date and the vendor page it came from. Treat it as a variable that someone will change, not a constant. If you cannot source a number, say so in the model rather than estimating one.
3. Test on your own data before moving anything. A smaller model is only cheaper if it makes acceptable decisions on your actual inputs. Build an evaluation set from real, anonymised cases, and compare the outputs. A saving that changes the answer is not a saving.
4. Count the costs that do not fall. Human review, monitoring, audit logging, integration work and change control do not shrink because a model is cheaper, and they belong in the model next to the unit price.
5. Set a trigger to revisit. A vendor price change, a new model release or a material change in volume should each prompt a short, scheduled review rather than an ad hoc debate.

Step three is where a good idea either survives or does not. Running several candidate models against the same evaluation set in parallel is a natural fit for a short proof of concept, and Innovify AI Labs is built around that kind of parallel testing.

Where governance still dominates cost

The FCA's 19 October speech is worth reading closely here. As summarised in our intelligence, the regulator is applying existing frameworks, including Consumer Duty and senior-manager accountability, to AI rather than creating new rules for agents. It also published examples of good and poor AI practice, and said AI providers should add disclaimers to AI financial advice. The material we have reviewed does not address model size or pricing, and we make no claim that it does.

The implication is ours, not the FCA's: accountability does not shrink with the model. A named senior manager is accountable for a customer outcome whether it came from a large model or a small one. So moving a workload to a different model is a change that needs testing, approval and a record, and that work costs the same either way.

The wider debate points the same way. Our October intelligence finds that who authorises, and who is liable for, an agent's transaction is the dominant agentic-commerce theme for a third run in a row. JPMorgan Chase's decision to block outside AI agents from direct access to customer accounts, and to back open-banking routes instead, is one reported example. None of that depends on what a model call costs.

So the practical position for a UK fintech platform team is this. Lower unit costs are a reason to re-examine your high-volume workloads. They are not a reason to relax the controls around them.

Where Innovify fits

Innovify is a technology partner with deep expertise in banking, financial services, fintech and insurance. We help mid to large businesses build AI-native products, and we design compliance in from day one. For this topic, that means helping teams decide which workloads are candidates for a smaller model, test that decision properly and put governance around it before anything reaches production.

Through our AI / ML Development work, we help businesses build agent workloads that regulated firms can govern. Through Innovify AI Labs, enterprise teams can run several proofs of concept in parallel, test them with real users and finish with a business case ready for funding. That is a sensible way to turn a vendor's pricing announcement into evidence about your own workloads.

FAQ

Do falling model costs mean agent workloads are now cheap to run?

Not necessarily. Vendors have reported lower unit costs for small and mid-tier models, but those are vendor-authored claims and the figures are not in the evidence we hold. Unit cost is also only one part of the total cost of running an agent safely, alongside review, monitoring, audit and integration.

Which agent workloads should a financial services team review first?

Start with high-volume, narrow tasks such as triage, classification and subagent work, because a change in unit price is multiplied most there. Prioritise those where an error has a low consequence and where you can test a smaller model against real cases.

Should a financial services firm move to smaller models now?

Only after testing on its own data. A smaller model is worth using if it makes acceptable decisions on your inputs and the change goes through your normal approval process. Cost alone is not a sufficient reason to move.

Does the FCA say which model size to use?

Not in the material we have reviewed. The FCA's 19 October speech applied existing frameworks, including Consumer Duty and senior-manager accountability, to AI. The senior manager remains accountable for the outcome whichever model produced it.

How often should an AI business case be revisited?

Set triggers rather than a calendar alone. A vendor price change, a new model release or a material change in volume should each prompt a short review, with the unit price recorded as a dated and sourced input.

Conclusion

Falling unit costs for small and mid-tier models are worth acting on, but only as far as the evidence goes. The evidence says the direction is favourable for high-volume workloads such as triage, classification and subagents. It does not give you a price, a saving or a break-even point. Treat price as a dated input, route tasks to the smallest model that passes your own tests, and keep the governance work in the plan, because that is the part that does not get cheaper.