Models and keys

Atoi is BYOK-first. You provide model access; Atoi provides the thread, project, task, and approval workflow around it. Provider and model choices stay explicit so you can control access, routing, and spend without turning every conversation into infrastructure work.

Add provider access

Open Settings → Models, choose a provider, and add its API key. Atoi validates supported provider keys before treating them as connected. Saved secrets are encrypted in backend storage.

After save, settings queries do not return the key. The client receives a configured or not-configured status, and an existing key is represented by a masked placeholder. Reopening the dialog lets you replace the credential, but it does not reveal the stored value.

This redaction boundary matters when sharing screens, exporting settings state, or inspecting product traffic: configuration status can be visible without exposing the secret.

Shape the model picker

Provider access determines which catalogs can be used. Enabled-model settings determine what appears in the composer. The picker groups models by provider, supports search, and keeps the active model attached to the conversation.

Keep the enabled set legible. A useful baseline is one default for everyday work, one faster option for short iterations, and one stronger option for judgment-heavy tasks. Add multimodal models when the workflow actually includes images or other mixed inputs.

Changing the model changes what answers the thread. It does not create a new thread, project, or task.

Set reasoning strength

Models with a known reasoning profile expose a reasoning-strength picker beside the composer controls. The available values depend on the selected model and transport. Labels can include Default, None, Minimal, Low, Medium, High, Extra high, and Maximum, but unsupported choices are not shown.

Use Default when the provider’s own behavior is appropriate. Lower strengths favor speed and cost. Higher strengths favor deeper reasoning. The selection is validated against the model profile and remains part of the thread’s model settings.

Choose an approval posture

Approval posture governs how often durable Code work interrupts for confirmation:

• Strict asks before every meaningful write, terminal command, or runtime escalation.
• Balanced keeps approvals frequent for risky actions while allowing low-risk flow. It is the default.
• Relaxed reserves approvals for the highest-risk actions and long-running transitions.

This is an interruption policy, not permission to ignore hard safety gates. Pending approvals remain explicit task state, and their resolutions are written to the shared approval ledger.

Settings also include a terminal-approvals switch. When enabled and a CLI or TUI session is attached, eligible approval requests can be resolved there instead of requiring a return to the web. The same ledger remains authoritative across web, mobile, CLI, and TUI.