Task discussions

How discussions work

Every task has Comments on its Overview, under the spec. A comment without a mention is a note to yourself. Mention a model with @ and it reads the task and the discussion so far, then replies under your comment.

Use a discussion before anything gets built, for example to ask how a model would approach the task or to find gaps in the spec. Replies are read-only. The model runs in Plan mode in the task's folder, so it can read the code but can't change files or the task.

Codex, Claude Code, OpenCode, Oh My Pi, Cursor, Pi, and Antigravity can join discussions when enabled. fx does not expose a read-only Plan mode, so its choices explain that limitation. Use a normal fx thread for work.

Ask a model

1. Open the task's Overview and scroll to Comments.
2. In the comment box, type @. A list of models and efforts opens, with entries such as @Opus 5.5 - High. Keep typing to narrow it, use the arrow keys to move, and press ↵ or Tab to pick one.
3. Write your question.
4. Choose Comment, or press ⌘↵.

A mention names the model as the model picker does, followed by the effort. When two models share a name, the list adds the harness or provider in parentheses. You can also mention an Orcling by name; it replies with the model it uses.

Mentions inside code or quoted lines are ignored. If a mention matches no available model, the comment isn't sent and the error names the mention.

When the spec itself mentions models with @, Ask tagged agents appears beside the Comments heading. It asks those models to discuss the saved description with you. A mention in the description never starts work.

How replies arrive

Each model's reply appears under your comment as it is written, signed with the model, the effort and the harness. Until it finishes, the reply says Queued or Replying…. A model answers your comments one at a time, in the order you wrote them.

• Reply on a model's reply addresses that model. It continues the same session, so it remembers what it said.
• Reply on your own comment addresses the models that comment mentioned. Each one shows above the box; click it to leave that model out.
• Cancel response stops a reply that is queued or being written. Retry response asks again after a reply fails or is cancelled.
• A model can stop to ask you a question. The question appears in its reply, which says Waiting for your answer until you answer.

Each reply gets the task's spec, the earlier discussion and your newest comment. Very long discussions are trimmed to their most recent part.

Ask several models

Mention more than one model in the same comment, up to eight. Each one replies on its own, so you can compare answers from different providers or efforts side by side. Their replies run at the same time.

If any of them reads your comment as a request to build, nothing starts on its own. OpenOrc asks Who should implement? with a button for each model you asked. Choose one; the work starts with that model, and the other replies stay as they are.

From discussion to work

Under the Comments heading, OpenOrc notes that clear work requests continue in a linked thread. Each model decides whether your newest comment is discussion, needs clarifying, or clearly asks for the work to be done, and only your own words in that comment count. "How would you implement this?" is discussion; "Can you implement this?" is a request. The spec, quoted text and other models' replies never count as a request.

When a model reads your comment as a request:

1. Its reply finishes as usual.
2. OpenOrc starts the work in the task's thread, with that model and effort. It uses the thread the task came from when that thread is idle and runs the same model in the same place; otherwise it creates a thread named after the task.
3. The reply says Starting work…, then Working in thread, and gains Open thread. The task moves to In progress, and that thread becomes the task's thread.
4. When the work ends, the reply adds whether it completed, failed or was cancelled, followed by the agent's final message.

Once the task's thread has started, a later request starts nothing new. It is queued in that thread as a follow-up, using the thread's current model and settings.

Next steps