Pick the right model for the job

It is "which model is good enough for this queue, at this price". A customer asking what your opening hours are does not need the most capable reasoning model ever built. They need a correct answer in under a second. Spending premium tokens on that question is not thoroughness, it is waste, and at support volumes it is expensive waste.

The conversation where someone is trying to cancel a contract and is already annoyed is a different problem. There, nuance is the entire job, and the cheaper model failing to read the room costs you far more than the token difference ever would.

These are two different purchasing decisions, and most platforms only let you make one. Model choice is set per agent, so you can make both.

Every model in the picker shows its credit cost per message on the row itself. A more capable model costs more credits per interaction, and you find that out while you are choosing, not when your credits run out three weeks later.

This sounds like a small interface detail and it is not. Pricing that only becomes visible in arrears is how support automation quietly turns into an unpredictable bill. Seeing the cost next to the choice makes the trade-off an actual decision rather than a surprise. Your plan sets how many credits you get each month, and credits can be topped up with an add-on. The current numbers are on the pricing page.

Your agent’s knowledge and the model that reasons over it are separate things. Everything you taught it on the training data side stays exactly as it is when you change models. There is no retraining step, no re-upload, no downtime. You pick a different model and the next message uses it.

That is what makes experimenting cheap. Run a queue on one model for a week, look at the conversations, and move if the quality was not there. The cost of being wrong is a dropdown.

When the agent gets something wrong, the first instinct is to reach for a bigger model. Usually the model was not the problem. An agent that answers confidently and incorrectly because the policy it was trained on is eighteen months out of date will do exactly the same thing on a more expensive model, only more persuasively.

Two things move answer quality further than model choice, and both are cheaper. The first is what the agent knows: what you trained it on, how current that is, and whether the answers that have to be exactly right are pinned as Q&A pairs rather than left to be inferred from a PDF. The second is what it can reach: an agent action lets it look the answer up in your systems instead of reasoning about it from documentation.

So spend the model budget last. Get the training data right, give the agent the endpoints it needs, and then move up a model on the queues where nuance is genuinely the job.