Research mode fans out to thousands of unbounded sub-sessions: exhausts subscription quota, then OOMs the host

Summary

A single research prompt causes opencode to recursively decompose the question into thousands of unique sub-questions, each in its own session, with no breadth or depth cap. Over three occurrences in 36 hours this consumed ~11,400 flagship-model calls (exhausting a ChatGPT Plus quota) and twice grew the process past 11 GB RSS until the kernel OOM-killed it, destroying the session in a way that leaves it invisible in the session list.

I don't know whether the fan-out itself is intended behaviour. Even if it is, the absence of any budget, depth cap, or diminishing-returns check makes it hazardous on subscription-billed providers and on modest hardware.

Environment

• opencode 1.17.8 (also observed on the same install prior to updating to 1.18.11)
• Linux 6.8.0, 16 GB RAM (Intel N100 mini PC), Ubuntu 24.04
• Provider: OpenAI via ChatGPT subscription OAuth; model gpt-5.6-sol
• Storage: ~/.local/share/opencode/opencode.db (613 MB at time of diagnosis)

Reproduction

Ask a broad research question in a normal session, e.g.:

can we do some research on self hosted home video security? whole pipeline, from hardware to software, ideally all self hosted and open source

Observed three times in 36 hours (all figures read directly from opencode.db):

Start → end	Duration	Sessions created	gpt-5.6-sol calls	Ended by
08-01 10:07 → 10:28	21 min	3,324	3,585	OOM kill at 10:43 (11.3 GB RSS)
08-01 10:58 → 12:02	63 min	3,002	3,453	—
08-02 09:16 → 09:40	24 min	4,363	4,324	OOM kill at 09:41 (12.5 GB RSS)

Median gap between messages during a burst: 31 ms.

The sub-questions are genuinely distinct (not a retry loop)

This was my first hypothesis, and the data rules it out. For the 08-02 burst: 4,363 user messages, 4,363 byte-distinct prompts; after normalising case, digits and punctuation over the first 400 characters, 4,353 are still unique. Median prompt length 708 characters (max 1,734). Samples:

• Research ONLY official github.com/OpenIPC organization repos …
• Research only; do not edit files. As of 2026-08-02, investigate ONVIF … onvif.org …
• Research only, current as of 2026 — use only official nist.gov/csrc/nccoe URLs, investigate NIST SP …
• Research only, no workspace edits. Find explicit exact definitions of constant bitrate (CBR) and …

So this is real recursive decomposition — each answer spawning finer sub-questions — rather than one prompt being resent.

Consequences

1. Subscription quota exhaustion. ~11,400 calls to a flagship model over three runs took a ChatGPT Plus allowance to 58% / 2,947 turns and required spending a manual quota reset. Re-authenticating does not help, because the usage is genuine; the account simply reports "usage limit reached" until the window rolls.

2. Host OOM, with session loss. The process accumulated 12.5 GB RSS (92 GB virtual) holding the session state:

Aug 02 09:41:11 kernel: Out of memory: Killed process 3735215 (opencode)
                        total-vm:92239700kB anon-rss:12531712kB

Because OOM kill is SIGKILL, nothing is flushed. The messages remain in opencode.db — I can query them — but the session no longer appears in the session list, so from the user's point of view the work simply vanished. This matches other "session lost" reports but has a specific, diagnosable cause.

Expected behaviour

Some bound on autonomous fan-out. Any of these would prevent both failure modes:

• A configurable maximum number of sub-sessions (and/or recursion depth) per request, with a sane default.
• A token or request budget for a research run, after which it stops and reports what it has.
• Backpressure on memory: cap concurrent in-memory sessions, or stream completed sub-session state to disk rather than retaining it all.
• A confirmation prompt (or dry-run plan) before a request expands beyond, say, 50 sub-sessions.

Notes

Happy to supply further detail from the local database if useful — the burst analysis above is reproducible with queries against message (time_created, data.role, data.modelID) joined to part on message_id.