Delegate a coding task to an external model running in OpenCode. The delegated model runs an agentic loop with the MCP servers configured in opencode and the skills from ~/.claude/skills - it is a full worker, not a single completion call.

Monitoring is event-driven (SSE) with poll fallback and a hard ceiling (OPENCODE_MAX_POLL_MS, default 45 min) - it never waits forever. Empty responses are retried automatically; a session that ends in error comes back as an error, not as an empty success; if the opencode server is down the bridge restarts it. Run bridge_health first when in doubt.

USE IT FOR: an atomic task whose design is already decided in the prompt. AVOID IT FOR: open design decisions (the model will fill the gap with something plausible) and long build/run loops inside the agent.

TRAP: use ABSOLUTE paths for every file in the prompt, even when passing 'directory'. If the wait hits the ceiling you get an error carrying the session_id - the model MAY STILL BE RUNNING on the server: check task_progress before continue_task.

CHOOSING THE MODEL - MANDATORY: if the user did not name a model for this task, DO NOT pick one on your own. Call list_models, then propose ONE model with a one-line reason ("qwen3.7-plus: multi-file refactor, needs the bigger context") and ask the user to confirm or change it. Once they answer, reuse that choice for the following delegations in this conversation until they say otherwise. Only skip the question when the user already named the model.

RETURNS: session_id for continue_task / task_progress / abort_task / end_task.

Send a follow-up message to an existing delegation session (full history preserved). Same monitoring guarantees as delegate_task: hard wait ceiling, and a session that ends in error comes back as an error.

USE IT FOR: iterating on work that came back good, or asking for the final summary when the answer came back empty. DO NOT use it while a round is still running - it queues a second prompt on top of the one in flight; check task_progress first. DO NOT use it to switch models: a session belongs to the model it was created with, so relaunch with delegate_task instead.

Inspect a running delegation without interrupting it: tool-call count (the reliable liveness signal), last tools, todo list. HOW TO READ IT: a tool-call count that grows between two spaced checks means it is working; a todo list that stops moving does NOT mean it is stuck, and is not a reason to abort - the model does not update it while working. For ground truth on files, run 'git status --short' in the worktree. This answers 'alive vs stalled', never 'how much is left'.

Abort the round running in a delegation session. The session and its history are KEPT for inspection or resume, and the bridge will never re-prompt an aborted session. Use it when two spaced task_progress checks show no growth AND the worktree is unchanged. Not the same as end_task, which deletes the session.

End and DELETE a delegation session on the server, clearing this bridge's registry for it. Use it once the work is accepted. There is no recovery afterwards: to stop the work but keep the history, use abort_task instead.

List delegation sessions from the SERVER (survives bridge restarts), enriched with this bridge's registry. Use it to recover a session_id when a delegate_task failed without returning one.

IMPORTANT: GET /session on the opencode server is SCOPED BY DIRECTORY. This tool sweeps the server's default scope plus every directory this bridge knows about, and it always prints which scopes it swept. If the bridge was restarted its registry is empty, so a session created with a project directory may not show up - in that case call it again passing that directory explicitly.

List what this opencode server actually offers: every provider/model, its effort levels (opencode calls them "variants"), context window and whether it reasons - plus the aliases configured in bridge.config.json.

USE IT BEFORE delegate_task whenever the user has not named a model: pick a candidate here, then propose it to them with a one-line reason. It is also how you find the valid 'effort' values, which differ per model.

The catalog is large (hundreds of models across providers), so the output is capped. It always reports how many models matched and how many were left out - if something you expect is missing, narrow with 'query'/'provider' or raise 'limit' instead of assuming it is not there.

Check the whole delegation chain in one call: credential file readable, serve up and STABLE (two spaced reads, so a dying instance cannot pass), auth enforced, provider models present, skills valid. With deep=true also runs a REAL MCP call through a disposable delegation on the cheapest model, then deletes that session. Run it with deep=true before a batch of delegations and whenever the environment smells broken - it is the manual liveness test turned into code. Do not run deep=true in a loop: it spends tokens.