Repository navigation
research(fleet): opencode via SSH-on-laptop vs attaching to the laptop server over the network — which is more efficient for opencode work? #1344
Description
PRIORITY — Drew, 2026-10-27 02:18 CDT ("make it a priority"). Context: the sandbox opencode server is STOPPED for good (Drew's laptop-only ruling, 2026-10-27) — all opencode work now runs against the laptop. Two access patterns exist; which one should be the fleet's default for opencode work is an open, measurable question.
THE COMPARISON (benchmark, don't opinion-shop):
A) SSH onto the laptop and run opencode there — CLI/TUI/sessions execute on the laptop, driven over ~/tools/laptop-ssh.sh (multiplexed). Agent tooling shells in, runs commands, reads output.
B) Attach to the laptop's opencode server over the network — the fork's attach/remote modes and/or the HTTP API (and OpenChamber pointed at the laptop server via OPENCODE_HOST + OPENCODE_SKIP_START), with the server reached directly over Tailscale or via an SSH port-forward.
MEASURE, on identical scripted workloads (session create, prompt round-trips on a small model, a multi-step file task, quota CLI run, session list/read):
- Latency: time-to-first-token and per-call round-trip overhead (local-on-laptop vs Tailscale-direct vs SSH-forward), incl. connection setup cost per invocation.
- Throughput/reliability: long-running session behavior, dropped-connection recovery (SSH session death vs server attach reconnect), concurrent sessions.
- Locality: where config/credentials/plan store/db live in each pattern (both are laptop-side in A; in B the server holds them and the client is thin — spell out what still executes client-side, e.g. the quota CLI's credential resolution).
- Failure modes: laptop asleep/rebooting, Tailscale down (SSH also rides it — note the shared dependency), server not running vs sshd not running.
- Fit with our tooling: stewardship dispatch, OpenChamber (its Remote Instances are SSH-based — mechanism (a) from the 2026-10-22 linking research), the quota gatherer (already laptop-resident), mcpx.
Prior art to reuse, not redo: 2026-10-22 OpenChamber linking research (three mechanisms; SSH forwards of laptop :3000 + opencode :40671 proven from the sandbox); laptop serve ports observed then: 43853 / 40671 / 13420.
DELIVERABLE: a short benchmark report in the usage-billing-hub goal files (or a more fitting fleet location — name it in the report), a DECISION RECORD with the recommended default pattern per use case (interactive agent work / scripted API calls / OpenChamber use), and follow-on implementation issues for whatever wiring the winner needs. If the answer differs by use case, say so with the measurements — a split verdict is a fine outcome.
Acceptance: both patterns benchmarked on the same workloads with numbers; decision recorded; follow-ons filed.
Acceptance criteria
- Both access patterns (SSH-on-laptop vs attaching to the laptop opencode server over the network) are benchmarked on the same workloads, with numbers recorded on this issue.
- A decision is recorded: the fleet default pattern, or a split verdict by use case where the measurements differ.
- Follow-on implementation issues are filed for whatever wiring the winning pattern needs (including OpenChamber use).
Activity
developing-today commentedon Oct 27, 2026
CODE-448
dezren39 commentedon Oct 27, 2026
Intake review
Fleet monitor intake pass (protocol §5), 2026-10-27. Verified still live: no merged PR implements or resolves this issue as of this run, and no duplicate open issue covers it.
Related: Related: Drew priority directive 2026-10-27 02:18 CDT (in the body). Context: sandbox opencode server stopped for good (laptop-only ruling, 2026-10-27); companion fleet-epic issues #1334-#1343 cover the surrounding lanes/dispatcher work.
Notes / risks / suggested approach: This is a measurement task, not an opinion task: same workloads, both patterns, numbers on the issue. Risk: laptop load/network variance skewing results — repeat runs and record variance. The decision itself lands with Drew once the numbers exist.
Labels normalized by this pass: kind/question, status/needs-triage, priority/high, effort/m, meta/enriched.
dezren39 commentedon Oct 27, 2026
Benchmark complete 2026-10-27. Full report + decision record:
workspace/goals/usage-billing-hub-token-quotas-per-service-saas-limits/files/opencode-access-benchmark-2026-10-27.md(hatch-personal).Verdict (split): programmatic opencode work (stewardship dispatch, scripted runs, tooling) defaults to ATTACH — persistent SSH forward to the laptop background service (127.0.0.1:13420), raw API for control +
run --serverfor turns. SSH stays for host administration, bootstrapping the forward, and server recovery. OpenChamber remains the human interactive front door.Why, in one paragraph of numbers: the work executes on the laptop server in both patterns, so times are close — API list/create 7–10 ms local vs ~450–470 ms via forward (one DERP RTT); prompt TTFT model-bound at 1.2–2.4 s either way;
opencode runtrivial prompt ~2.3 s on-laptop vs ~6.2 s from the sandbox; the multi-step file task 7.8–8.4 s (SSH) vs 9.5–9.7 s (attach). The decision is made on failure behavior: killing the transport mid-task in BOTH patterns (forward SIGKILL for attach, run-client SIGKILL for SSH) left the turn to complete server-side — all 10 files written, outcome "succeeded". Attach pays one 3.3 s setup and avoids SSH's per-command ~0.4 s tax + MaxStartups burst risk on every driven command. Direct tailnet attach is impossible today (both servers bind 127.0.0.1 only — probed and refused).Findings that became follow-ons (all filed, on Project #4 as Todo / pm-dashboard / Task / Week):
opencode runhangs indefinitely on an open non-tty stdin (reproduced in default/--server/--standalone; /dev/null completes in seconds)?directory=(fell back to /home/user and wrote a file there during the study)Method note: the first-choice benchmark model (ClinePass DeepSeek Flash) was pool-exhausted mid-study (402), so controlled figures use meta/muse-spark-1.1 identically across patterns.
dezren39 commentedon Nov 2, 2026
Claimed triage task 2554 for #1344 (openchamber scheduled lane). Next: verify the benchmark evidence and follow-on state on current main, then route or close.
dezren39 commentedon Nov 2, 2026
Triage verdict — already satisfied, no follow-up needed
Every acceptance requirement is met on the issue thread itself:
opencode runtrivial ~2.3 s on-laptop vs ~6.2 s from the sandbox, multi-step file task 7.8-8.4 s (SSH) vs 9.5-9.7 s (attach), plus failure-injection runs (transport kill mid-task in both patterns left the turn succeeding server-side).There is nothing left to route as a fix packet: the deliverable was the benchmark + decision, both already on this issue. Recommendation: close #1344 with this verdict and treat the three remaining open fork/fleet follow-ons (#1359, #1360, #1362) as the tracked continuation, rather than keeping the benchmark question itself open.
dezren39 commentedon Nov 2, 2026
Task 2554 completes as
already_done: the benchmark report, the split ATTACH/SSH/OpenChamber decision, and the five follow-on issues were already recorded in the comments before my claim (verdict 2026-10-27). I closed #1344 with a verdict comment; #1359, #1360, and #1362 remain the open tracked continuation. No further code or packet work is warranted.