Models and keys
Connect a provider with your own key or subscription, enable models, and pick a default.
Atoi runs on your own provider access. Connect a provider, enable the models you want, and set the one your conversation runs on. Any thread can switch to another enabled model without changing who you are talking to.
#Connect a provider
Open Settings → Models and choose a provider. Some connect with an API key. Some connect with the subscription you already have, through a sign-in flow. Both land on the same provider page.
Keys are secret input. Atoi masks them after you save and never shows the full value again. Saved keys sit under Credentials on the same page.
#Three states, three meanings
- Key saved: the provider is connected.
- Model enabled: it shows up in the picker.
- Request succeeded: a real call worked for this model and this account.
One does not prove the next. Balance, region, and retired models can still fail a request.
#Pick a model and a reasoning strength
The model picker in a thread lists your enabled models. Reasoning strength appears only for models that support it. Changing either affects the next request, not the thread.
Under Settings → Roles, the Chat row sets the model your conversation runs on. The other roles stay on Automatic, the built-in ladder, until you pick a model for one.
If a request fails, the failure stays on the message with a Resume action. Fix the cause, then resume. If Atoi had to answer with a different model than the one you picked, the message says which model ran.
#Rotate or remove a key
Replace a key from the provider page when it changes. Removing a provider makes its models unavailable for new requests. Past threads keep their history.
Never paste a key into a thread, a document, a screenshot, or a support report, and never ask Atoi to fetch one for you.
#The layers
A provider is the door. A model is what answers. Neither one changes who you are talking to.
| Layer | The question it answers |
|---|---|
| Provider | Can this account request models through this door? |
| Enabled model | Should it appear in the picker? |
| Selected model | Which one handles this request? |
| Reasoning strength | How hard should it think, when the model offers a choice? |
| Capability | Can it take this input and produce this output? |
#Curate
Pick one reliable default, one stronger option for hard problems, and specialty models only for recurring jobs. A long enabled list makes picking harder and keeps retired IDs around.
#Qualified names
Atoi can name a model as provider/model so the same upstream model through OpenRouter, the gateway, or a direct provider stays distinct. Routing and billing differ by door.
#Verify what changes
Catalogs, prices, context limits, and regional access change. Read them from the live provider page in Atoi, not from a model's family name.
Read Providers for the supported provider ids and Model capabilities for what to verify before you rely on a model.
Was this useful?