Where model credit comes from: four routes, and you can mix them
Last updated: 2026-09-22
Short answer: most platforms give you one route — buy their credit, use their models. Here you can choose, and the routes can be mixed.
The four below are four answers to the same question: for this call, whose credit pays, and which model answers.
1. Buy a plan: stop worrying about the supply side
The least work. Pick a tier and you no longer track model names, quota splits, or which provider is discounting this week. Describe the task; the rest is handled.
The cost is flexibility: the models inside a tier are chosen by the platform, so a specific model you have in mind may not be among them.
2. Attach a key you already have
If you already hold keys elsewhere — your own, or your company's — you can attach them.
After that you no longer remember a different calling convention per provider. Your code has one address and one key; the platform forwards to the right upstream.
Two cases suit this: you've already paid and don't want it wasted, or you need a model that only one specific provider serves.
How to fill it in and how to check it, see attaching a key you already have.
3. Don't name a model, let the platform choose
For the same task, the choice of model matters a lot: some are better at code, some at long documents, some are cheap but slow.
If you'd rather not research that, don't name a model — describe the task. The platform orders the candidates by task type, model capability and what's currently available, and steps down the list when one fails.
The value here isn't convenience, it's surviving a provider going down mid-task. Bind to a single model and an upstream outage becomes your outage.
4. List an agent you built yourself
The first three are about consuming. This one runs the other way: if you've built an agent worth using, you can list it and price it per call or by subscription.
Listing, repricing and delisting all happen in the console; pricing is in platform credits.
Why the four coexist
Because they share one entry point. Your code knows a single address; what changes is who pays and which model answers behind it, not your code.
So you can run day-to-day on a plan, use your own key for one specific job, and hand anything that must not break to automatic selection.
The trap: reachable is not the same as working
All four routes involve three things — address, key, model name — and the most common mistake is pairing them up wrongly:
- Right address, model not on that side. A platform often exposes more than one entry point, each backed by a different model pool. Asking entry A for a model that only exists behind entry B produces an error that tells you nothing.
- The key never left. Many tools read the key from an environment variable. If your system already had one with that name, the key you just typed may never have been used — and the only symptom is "authentication failed".
- "Model unavailable" when the model is fine. Bad credentials, exhausted quota and a wrong model name can all surface as the same sentence.
So after filling things in, don't stop at "no error". Send one minimal request and look at what actually came back. The steps are in the walkthrough.
Which to pick
Starting out, take a plan — nothing to configure before you find out whether this is useful to you.
Already holding keys, or needing one particular model, take the second.
If it has to run unattended for long stretches, the third matters more than the first two.
If you build agents, the fourth is how they turn into income.
Related reading: what an AI agent is, or the usage guide.