Skip to content
AppsWeb

Web


Sign in to your thread, ask Atoi, answer an Ask, follow a Task, read its Receipt, and share the reviewed result.

Use the web for Atoi's broadest surface. Start in your thread, keep it open while work runs, and open a Project or Settings only when you need them.

#1. Arrive and sign in

Open atoi.app and sign in. After onboarding you land in your thread at /; Explore opens Suggestions with work that needs you, active work, and recent Threads.

Open an existing item in place, or press ⌘N to start a new request.

Capture pending: The home thread with Ask Atoi ready after sign-incapture pendingThe home thread with Ask Atoiready after sign-in1440×900/
The home thread with Ask Atoi ready after sign-in

#2. Ask for an outcome

Choose Ask Atoi and describe the result you want. Type @ to attach an agent, Project, document, or Computer, and add a file or Connection only when it adds necessary context. Pick the model and reasoning strength before you send.

After you send, Atoi opens the Thread at /c/<thread>.

#3. Answer an Ask

Read the question, its options, and what each one changes. Answer in the Thread. If the Ask is waiting in Inbox, open /inbox, confirm the request and target, then approve or deny it.

Capture pending: Thread showing an Ask card above the composercapture pendingThread showing an Ask cardabove the composer1440×900/c/<thread>
Thread showing an Ask card above the composer

#4. Watch a Task

Open the Task from its Thread, Inbox, search, or a Project's Tasks page. The Task opens in the panel and adds ?task=<task> to the current address. Read the state literally: queued, running, waiting on you, completed, failed, or cancelled.

On the web you can read Task proof and inspect a Task change set. Start, cancel, continue, apply, and draft-PR actions are not on the web yet. Use the terminal for those actions.

#5. Read the Receipt

When the Task stops, read Result, Changes, Checks, and Proof in order. Open every artifact, inspect the immutable change set when one exists, and keep unresolved work in the same Thread.

Capture pending: Task Receipt panel with Result, Changes, Checks, and Proofcapture pendingTask Receipt panel withResult, Changes, Checks, andProof1440×900/c/<thread>?task=<task>
Task Receipt panel with Result, Changes, Checks, and Proof

#6. Share only after you review

Open the Thread menu and choose the public share action. Read the owner-visible redaction Receipt, copy the link, and test /share/<share> in a signed-out window before you send it.

Add a person to your Workspace when they should take part in a Thread. Use a public share when someone should only read a copy. Follow the sharing checklist for both.

#7. Use Projects and Settings when the work needs them

Open a Project to create, rename, archive, or restore it, bind its Workspace, and move among its Threads, Tasks, documents, and activity. Open Settings to manage preferences, provider Connections, Skills, Plugins, Computers, data, billing, and usage. Browser-owned authorization and checkout stay here even when you begin them in the terminal.

#On this surface today

On the web today you can use:

  • Sending with attachments, context, a selected model, and reasoning strength.
  • Group participants and presence.
  • Response feedback and reactions.
  • Public sharing.
  • Full Thread lifecycle.
  • Channel lifecycle and authorization.
  • Preferences and provider Connections.
  • Skill and Plugin lifecycle and installation.
  • Terminal authorization, companion pairing, and checkout.
  • Project lifecycle and Workspace binding.
  • Task proof and change-set inspection.
  • Search, For You, Inbox decisions, and Automations.

The cross-client inventory does not claim full parity. On the web, Task lifecycle, reading a Project's source state, and Task apply or draft-PR actions are still designed to converge from the terminal set.

#Where it differs

  • Compared with the web, Apple verifies the message composer, group participants, and Task proof, but not Thread or Project lifecycle, public sharing, or Task actions.
  • Compared with the web, Android verifies the message composer and group participants, but not Task proof, Inbox decisions, public sharing, or record lifecycle.
  • Compared with the web, the TUI and CLI add reading a Project's source state and Task lifecycle and actions. Browser-owned authorization still returns you to the web.

Was this useful?