feat(opencode): add plan mode, reasoning effort, and status telemetry

[swear01]

Summary

• add real OpenCode plan mode support so the existing web option affects runtime behavior
• wire OpenCode reasoning effort through the CLI, hub, and web flow so it can be shown and changed from the settings panel
• bridge OpenCode ACP usage into the existing token-count pipeline so the web status bar can show ctx and cache

Test plan

• bun run test -- src/agent/messageConverter.test.ts src/agent/backends/acp/AcpSdkBackend.test.ts in cli
• bun run typecheck in cli
• bun run test -- src/chat/normalize.test.ts in web
• bun run typecheck in web
• Manual verification in an isolated hub + runner environment for OpenCode session controls and status telemetry

Issues

• Fixes OpenCode: support plan mode #672
• Fixes OpenCode: model reasoning effort setting fails with 400 #674

Notes

• Also includes OpenCode web status telemetry (ctx / cache) so ACP usage data is visible in the existing composer/status bar without introducing an agent-specific UI path.

Made with Cursor

[github-actions]

Findings

• [Major] OpenCode plan mode is exposed to local sessions without local enforcement — adding plan to the shared OpenCode modes makes CLI/API paths accept it for local OpenCode sessions, but the enforcement added in this PR lives in the remote launcher/ACP permission handler. The local launcher only mirrors permission.* hook events, so local plan mode can still execute tools, defeating the mode's safety expectation. Evidence shared/src/modes.ts:29.
  Suggested fix:

  if (flavor === 'opencode' && mode === 'plan' && sessionResult.session.agentState?.controlledByUser === true) {
      return c.json({ error: 'OpenCode plan mode is only supported for remote sessions' }, 409)
  }

• [Major] Failed OpenCode effort switches remain persisted — the config RPC stores the requested effort and reports it as applied before the remote launcher successfully calls session/set_config_option; if OpenCode rejects the value or method, the catch path only mutates the current batch and sends a message, leaving hub/session state on the rejected value and causing later turns to retry it. Evidence cli/src/opencode/runOpencode.ts:147.
  Suggested fix:

  const fallbackEffort = this.currentBackendEffort;
  batch.mode.modelReasoningEffort = fallbackEffort;
  session.setModelReasoningEffort(fallbackEffort);
  session.pushKeepAlive();
  this.onReasoningEffortRollback?.(fallbackEffort);

Questions

• None.

Summary

• Review mode: initial
• Two issues found: remote-only plan enforcement is exposed to local OpenCode sessions, and failed OpenCode reasoning-effort switches can leave persisted state out of sync with the backend.

Testing

• Not run (automation; static review only).

HAPI Bot

[github-actions]

[MAJOR] This exposes plan as an OpenCode mode for every path, including the default local hapi opencode --permission-mode plan flow and web permission-mode updates on controlled-by-user sessions. The PR only enforces plan in the remote launcher/ACP permission handler; opencodeLocalLauncher just mirrors permission.* hook events, so local plan mode can still run tools.

Suggested fix:

if (flavor === 'opencode' && mode === 'plan' && sessionResult.session.agentState?.controlledByUser === true) {
    return c.json({ error: 'OpenCode plan mode is only supported for remote sessions' }, 409)
}

Also reject terminal local startup unless --hapi-starting-mode remote:

if (options.permissionMode === 'plan' && options.startingMode !== 'remote') {
    throw new Error('OpenCode plan mode is only supported in remote mode')
}

[github-actions]

[MAJOR] This records the requested effort as applied before the remote launcher has successfully called session/set_config_option. If OpenCode rejects the value or the method, the catch path only mutates the current batch and sends a message; the hub/session state still says the rejected effort is active, and future messages are queued with the same stale sessionModelReasoningEffort.

Suggested fix:

const fallbackEffort = this.currentBackendEffort;
batch.mode.modelReasoningEffort = fallbackEffort;
session.setModelReasoningEffort(fallbackEffort);
session.pushKeepAlive();
this.onReasoningEffortRollback?.(fallbackEffort);

Wire onReasoningEffortRollback to update sessionModelReasoningEffort before the next queued turn.