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.
#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.
#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.
#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?