They ask: How would you reduce our AI spend without hurting quality?
You say: I build an inventory of the work before I touch any settings.
List every task the team actually does. Reading requirements and finding gaps. Writing test cases. Generating automation. Analysing failures. Reviewing a design for risk. Then, for each one, ask honestly how much reasoning it requires.
Most of the list needs much less than people assume. Turning a written criterion into a test case is mechanical. Judging whether a design will survive production is not.
Then you route. Cheap systems for the mechanical work, the expensive ones where the reasoning is genuinely hard, and the same logic applies to effort settings within a single system.
The saving comes from the inventory, not from negotiating a contract.
It also gives you something to show. An inventory is a document a manager can read, argue with, and approve. A recommendation with no inventory behind it is an opinion, and opinions do not survive a budget conversation.
The answer that ends the conversation early: "we would use a cheaper model." Which work, and how did you decide. Without the inventory it is a guess that will show up as quality problems later.
They ask: What is the difference between a subscription and API access, from a cost perspective?
You say: One is all you can eat and the other is priced by the plate, and people carry habits from the first into the second.
On a flat plan, running something twice costs nothing extra, so you stop thinking about it. That is a reasonable way to work while you are learning.
Metered access bills what you consume. The same casual habit now has a number attached, and it compounds across a team.
What makes it worse is that defaults tend to favour thoroughness, which means consumption. Nothing sinister. But nobody ships a tool configured to use as little as possible, and the person paying is not the person who set the default.
The practical move is to go and read the defaults before the first bill rather than after it. That is a ten minute job that almost nobody does, and it is the difference between a surprise and a decision.
The answer that ends the conversation early: treating them as two ways to buy the same thing. They produce different behaviour, and the behaviour is the cost.
They ask: Why should we hire you over someone with more testing experience?
You say: Because I can take work you are currently doing expensively and make it cost less without making it worse, and I can show my working.
The routing decision is a real skill. Knowing which tasks need heavy reasoning and which do not, then setting the work up so each one runs on what it actually requires.
You do not deliver a pizza in an expensive car. Not because the expensive car cannot do it. Because it is the wrong vehicle for the errand and somebody is paying the difference.
Most people testing software today have not thought about this at all. If I save a meaningful share of what you spend, that is the easiest conversation about my salary either of us will have.
And it is a claim you can support in the room. Describe the inventory, describe which work you would move and why, and name what you would measure to prove it worked. That is a plan, not a promise. Managers have heard a great many promises about this technology. Very few of them arrived with a number attached and a way to check it.
The answer that ends the conversation early: listing tools you have used. They asked why you rather than someone else. Everyone has the tools. Almost nobody arrives with a cost argument.