opencode coding agent on dev VMs — deferred (weight, overlap) #6

New issue

Open

opened 2026-07-15 12:57:03 +01:00 by allod-agent · 0 comments

allod-agent commented

2026-07-15 12:57:03 +01:00

Member

User story: So that I can keep development profiles lean and intentional, the deferred coding-agent option should stay documented with the concrete reasons and revisit criteria before adding another general agent.

Part of the "Profiles & VM archetypes" arc.

While rolling out the pi coding agent (#4) we evaluated opencode as a similar followup and decided to defer it. This issue records the evaluation so a later decision is deliberate rather than a rediscovery.

Feasibility is not the blocker. opencode is already exposed by the pinned nixpkgs-unstable (v1.17.15, meta.mainProgram opencode), so the integration would be mechanically identical to pi: install pkgs-unstable.opencode in the dev profile, generate a global memory pointer, and add a shell alias plus a yolo opencode case. Low mechanical effort, R2 blast radius, same acceptance-test shape as the pi work.

Concern — weight. opencode is the heaviest of the candidate agents. It is TUI-first with a client/server architecture and a server-backed runtime, versus pi's single lean CLI binary, and it is the largest closure of the four. Adding it cuts against the stack's stated tooling priority of minimalism, where dependencies are liabilities before they are conveniences.

Concern — overlap. The dev VMs already ship claude-code, codex, and pi. opencode's genuine extras (built-in LSP diagnostics, the full-screen TUI, first-class MCP, shareable web sessions) are real but overlap heavily with existing capability. A fourth general-purpose coding agent doing roughly the same job is hard to justify on marginal benefit alone.

Decision: deferred. Revisit only if there is a concrete need for opencode's TUI or LSP workflow specifically, not just to have another agent.

If revisited, resolve these integration unknowns first, the same due diligence pi's --approve got:

Global-context path: confirm opencode's global instruction file location (expected under ~/.config/opencode/, not ~/.pi/agent/) so the memory-pointer adapter targets the right file.
Approval bypass: identify opencode's non-interactive/permission-bypass mechanism for the yolo case; it uses a permissions system and agent modes rather than a single --approve flag.

The version and feature notes above reflect opencode 1.17.15 as pinned on 2026-07-15; re-verify against the then-current package on revisit, since opencode moves quickly.

Context: follows the pi rollout in #4.

**User story:** So that I can keep development profiles lean and intentional, the deferred coding-agent option should stay documented with the concrete reasons and revisit criteria before adding another general agent. _Part of the "Profiles & VM archetypes" arc._ --- While rolling out the pi coding agent (#4) we evaluated `opencode` as a similar followup and decided to defer it. This issue records the evaluation so a later decision is deliberate rather than a rediscovery. Feasibility is not the blocker. `opencode` is already exposed by the pinned `nixpkgs-unstable` (v1.17.15, `meta.mainProgram` `opencode`), so the integration would be mechanically identical to pi: install `pkgs-unstable.opencode` in the dev profile, generate a global memory pointer, and add a shell alias plus a `yolo opencode` case. Low mechanical effort, R2 blast radius, same acceptance-test shape as the pi work. Concern — weight. opencode is the heaviest of the candidate agents. It is TUI-first with a client/server architecture and a server-backed runtime, versus pi's single lean CLI binary, and it is the largest closure of the four. Adding it cuts against the stack's stated tooling priority of minimalism, where dependencies are liabilities before they are conveniences. Concern — overlap. The dev VMs already ship claude-code, codex, and pi. opencode's genuine extras (built-in LSP diagnostics, the full-screen TUI, first-class MCP, shareable web sessions) are real but overlap heavily with existing capability. A fourth general-purpose coding agent doing roughly the same job is hard to justify on marginal benefit alone. Decision: deferred. Revisit only if there is a concrete need for opencode's TUI or LSP workflow specifically, not just to have another agent. If revisited, resolve these integration unknowns first, the same due diligence pi's `--approve` got: - Global-context path: confirm opencode's global instruction file location (expected under `~/.config/opencode/`, not `~/.pi/agent/`) so the memory-pointer adapter targets the right file. - Approval bypass: identify opencode's non-interactive/permission-bypass mechanism for the `yolo` case; it uses a permissions system and agent modes rather than a single `--approve` flag. The version and feature notes above reflect opencode 1.17.15 as pinned on 2026-07-15; re-verify against the then-current package on revisit, since opencode moves quickly. Context: follows the pi rollout in #4.

No labels

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

allod/profiles#6

No description provided.

Rows
Columns