Skip to content

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 choose a default. 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.

Capture pending: Settings, Models, with a provider connected and models enabledcapture pendingSettings, Models, with aprovider connected and modelsenabled1440×900/settings/models
Settings, Models, with a provider connected and models enabled

#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, choose whether a subscription can also power background work. Atoi does not use it there until you opt in.

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.

LayerThe question it answers
ProviderCan this account request models through this door?
Enabled modelShould it appear in the picker?
Selected modelWhich one handles this request?
Reasoning strengthHow hard should it think, when the model offers a choice?
CapabilityCan 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?