Models & accounts

Whose credentials these are#

Every credential here belongs to your sandbox. You connect your own subscription and turns spend your allowance. intentic never resells inference, and the platform never holds the token.

Providers#

Two more sources are open-ended rather than built in:

Connect them on Sandbox → Agent. A subscription connects by signing in; nothing asks you for an API key you'd have to rotate by hand.

Several accounts of one provider#

A sandbox can hold more than one account per provider: a work Claude and a personal one, two ChatGPT seats, and a turn can name which serves it. Absent, it takes the provider's first.

Naming one matters most where nobody is watching. When an automation's first account runs out of headroom, or belongs to an organisation that switched the plan off, every unattended run errors against it until somebody reads the row. That is why an automation can pin an account and a chat rarely bothers.

An account belongs to a provider, so an automation can only pin one while every model on its ladder is on that same provider. Spread the ladder across providers and the pin goes: the daemon then serves each fire from whichever connected account has the most headroom, which is what you wanted from the pin anyway.

What an automation runs on#

An automation names its own models, in order, and it cannot be saved without them. It is the one thing here that spends an allowance with nobody in the room, on a schedule you set once and rarely re-read — so nothing is chosen for it. There is no sandbox-wide tier behind an automation and no inheriting whatever your chat happens to be set to this week.

The list is a ladder for the same reason every other model list in this product is one, only more so: a chat refuses in front of somebody who can retry it, while a wake at 3am against a spent allowance simply does not happen and nobody finds out until morning. Each rung carries its own model, reasoning tier, speed and harness; the daemon walks them at fire time and takes the first one this sandbox can actually start. An automation whose every provider has since been disconnected records the fire as an error saying so, rather than quietly spending something else.

The harness#

The harness is the agentic loop that serves the turn, and it is a different axis from the provider: the same model behaves differently under each, which is why the picker asks separately. Each provider runs on the loops below, its default first; where there is more than one, the picker shows one chip per loop.

The picker remembers the loop per provider, so choosing Claude Code for Codex says nothing about Grok. A request naming a loop the provider doesn't offer runs the provider's own, and is recorded that way: the conversation, its transcript and the usage ledger name the loop that actually served the turn.

The choice matters because the loops support different features, and the app tells you before you find out mid-turn. A runtime lacking mid-turn steering, clarifying questions, per-tool approvals, MCP tools or reasoning-effort control lists those limits, names another loop of the same provider that lifts them where there is one, and the composer hides the controls it would ignore. The composer's model pill names the loop whenever it isn't the provider's default.

What each vendor allows#

Some routes work but sit outside what the vendor allows. They stay available, and the picker marks them quietly: a small icon beside the provider and on that loop's chip, and a Vendor terms row whose hover card says what the vendor allows.

• Google: theAntigravity terms don't allow its sign-in in third-party clients such as OpenCode, and Google has suspended accounts for it.
• Meta: a Muse Code subscription key isfor use with Muse Code only. Muse Code is Meta's default loop here; choosing Claude Code instead runs the key outside those terms.
• Codex and Grok under Claude Code: OpenAI and xAIlist theapps a plan may run in, and Claude Code, reached through the bundled translator, isn't one of them. Nothing on record forbids it.

Per-turn controls#

Beyond the model there is reasoning effort, extended thinking, and a fast-speed request: each offered only where the runtime actually honours it. A conversation remembers what its last turn ran with, so opening it again seeds the composer from that conversation rather than from whatever another tab last picked.

Permission modes are the other half. A runtime that reports the full axis gets per-tool approval cards; one that does not gets propose-then-approve or run, nothing between. There the container is the isolation boundary and every tool call inside it is pre-approved.

Models for work you didn't start#

Sandbox → Agent → Models holds one ordered list per job: commit messages, session titles, the safety judge, loop verdicts, pipeline fixes, deployment fixes, maintenance chores, documentation runs, acceptance runs, automation wakes and the rest. Each list is tried top to bottom, so one spent account doesn't take a job down, and each entry carries how its model runs — effort, thinking, speed, harness — as well as which model it is.

A row you haven't touched falls back to its own default, and the two defaults are genuinely different:

• One-shot helpers — a commit message, a session title, a verdict — default to Auto: the cheapest rung of every connected provider, best first, resolved at the moment it's read. So it can never name a provider you have no credential for, and it improves by itself when you connect one. Nothing stops you pinning a frontier model to your commit subjects instead; that's a preference, and it's yours to have. A model kept for one-shot jobs, one that cannot call tools or the small local one, can be pinned here and nowhere else.
• Whole sessions — an automation's wake, a chore, an acceptance run, the fix a refused push proposes — fall back to whatever your own chat is set to. Nothing can judge what a session is worth, and a wrong guess is billed in whole sessions, so the honest default is a model you already chose.

What it costs#

Two different kinds of money, and only one of them is a bill. intentic itself is free: every sandbox, every capability and team sharing, with no tiers and no card. What a turn costs is your provider subscription being spent, because the credential is yours and intentic never resells inference. The one optional charge anywhere is a hosted sandbox, described on Pricing.

Sandbox → Usage reports the durable spend ledger: a row appended when a turn ends, grouped by day, provider, account and model, with cache hit rates alongside. Rows are written daemon-side and never edited, so it records what was spent rather than estimating it. Agent cards carry their own cost, and a workflow step can be capped in dollars: the one resource you cannot recover after an unattended fan-out.

When a provider refuses a turn because an allowance is spent or a plan is off, the last refusal is kept and shown beside the account, so a fleet that has quietly stopped working says why.

Related pages

• Automations & workflows: where pinning an account and a model actually pays off.
• Full child agents: children that choose a provider and harness independently.
• Remote runners: which model credentials can serve a turn on another machine.
• Access & sharing: who else may spend this sandbox's allowance.