فريق Kasper3 دقيقة قراءة
Most platforms built on language models eventually expose the dial. A dropdown appears in settings: choose your model. Then a slider for temperature, because a customer asked. Then the model name shows up in an API response, because it was already in the object.
Kasper has none of that, and it is not an oversight we intend to correct.
The AI provider, the model names, the reasoning level, the temperature, the top-p and every other model parameter are platform-only and structurally unreachable by any tenant or tester — including through the API. A tenant must not even learn which model is in use.
Why not just make it read-only?
Because read-only is a promise about a screen, and screens are not where this leaks.
The usual sequence: the setting is hidden from the interface, kept in the same table as everything else, and then serialised by an endpoint that returns the whole row. Nobody decided to expose it. It was simply never removed from the object, and the interface was doing the work of concealment on its own.
The alternative is to arrange things so that the value is not present in any response a tenant can reach — not filtered out of it, not present in it. Those configurations live in the platform console and are resolved server-side. There is no tenant-facing shape that carries them, so there is no serialiser to remember to strip.
That distinction is the whole of it. "We do not show that" and "there is no path from you to that" look identical on a page and behave differently on the day somebody enumerates an endpoint.
What this costs you
It should be said plainly, because it is a real trade and we are on the side that benefits from you not noticing it.
You cannot pin a model version. If you have an evaluation suite of your own and you want it stable against a fixed model, you cannot have that. You cannot tune sampling. If your calls would be better with a colder model, you cannot make it colder yourself. And you cannot audit the provider from inside the product — you have to take our word, or a contract, rather than reading it out of a response.
Those are genuine losses for a certain kind of sophisticated customer. We think they are worth it, and we would rather write the trade down than let you discover it.
What you get instead
A model choice that is ours to get wrong. If the model behind your calls is a setting, then the quality of your calls is partly your configuration problem, and the honest answer to a complaint becomes "try a different model." When it is not a setting, quality is entirely our problem, and there is nothing to suggest you fiddle with.
Freedom to change it. Providers deprecate models, prices move, better ones arrive. A platform whose customers have pinned a model version cannot move without breaking them, so it does not move, and eventually every customer is on something old. We can migrate because there is nothing to migrate.
One less thing in your compliance surface. A model identifier in an API response is a fact about your vendor's supply chain sitting inside your logs.
What is yours
Everything about behaviour is yours, and it is the part that actually changes what a caller hears: the instructions the agent follows, its rules and refusals, its fallback when it cannot answer, the languages and accents it speaks, how strongly it holds a dialect, what tools it may call and with what arguments, and what happens when one fails.
That is a real division rather than a marketing one. You configure what the agent does. We are accountable for what it runs on. The line is drawn where the accountability is, which is why it is drawn in the architecture and not in a permissions table.