fix(opencode): omit channel prompt for chat models - #47355
Conversation
|
@neriousy The reporter checked this with their LiteLLM setup and confirmed the prompt change. They also caught a versioned npm spec that I missed; 5de5c9a handles that, with regression coverage for pinned/tagged specs and their Foundry model IDs. The system/prompt tests pass (69 pass, 1 existing skip), as do the package and pre-push typechecks. The effect on intermittent premature stops is still unverified. Could you review the prompt change and approve the fork CI when you have a chance? |
|
@Rocklis Ran the batch you asked for. Short version: no measurable difference in premature stops, because at Setup. Two One deliberate config deviation you should know about: I stripped Instrument check first. Statically, Design. 10 tasks (6 short multi-step, 4 long ones that explicitly require a progress update before Buckets. A run is a premature stop if the last Result:
Fisher exact p = 1.00, but with a 0-vs-0 table that's a formality. The meaningful bound: zero events in Why it didn't reproduce. The traces explain it: this model emits its progress narration in the same Classifier positive control. To make sure the zeroes aren't an instrument failure, I ran a task that One thing that is a real signal. Counting mid-task (non-final) assistant text parts, paired by Limits, plainly. One model, one gateway, one machine, short scripted tasks. Our original report came Happy to re-run against a different model or a longer task profile if you have one in mind — the harness |
|
@spencer2211 I've added the batch results and the config/task limits to the PR description. I won't treat the zero-vs-zero result as proof that premature stops are fixed. Could you share a sanitized copy of the harness and task definitions? That would let us check the scoring and reuse the workload before asking for more runs. No need for another batch yet. @neriousy Would you consider this as a prompt-compatibility fix, with #47168 kept open for the unresolved long-session stops? The current issue check requires a closing link, so I've left that in place and made the limit explicit in the description. I can adjust the link when reviewing. |
|
@Rocklis Here it is. Two files, both inline below so nothing depends on a link staying alive. How to run. Each arm is a export AB_WORKTREES=/path/to/opencode/.worktrees
export AB_CONFIG=/path/to/ab-config.json
export AB_MODEL='my-openai-compatible-provider/my-model'
export AB_API_KEY=... # from your secret store
export AB_PASSTHROUGH_ENV=AB_API_KEY # allowlist it into the child env
export AB_SCRATCH=./ab-scratch
python3 ab_runner.py batch 8 # 6 tasks x 8 reps x 2 arms = 96 runs
python3 ab_runner_hard.py 8 # 4 tasks x 8 reps x 2 arms = 64 runs
python3 ab_runner.py posctl 4 # classifier positive controlRuns go one at a time, seeded random arm order per (task, rep) so gateway drift cancels. Per-arm Two limitations you should know before trusting the null, since you're checking the scoring:
One deviation from the code that produced the numbers. Also available if useful: the per-run classification records (
|
|
Synced dev in 56cb4b5 to resolve the import conflict from #48057. The new GPT-6 prompt path is unchanged. On that commit, the system/prompt tests pass (69 passed, 1 existing skip), along with the package typecheck and pre-push checks. @spencer2211 I've read through the harness. Could you attach the existing |
|
@Rocklis Here are the three record files: https://gist.github.com/spencer2211/1fe9772f4fd19a069a7b82a91bbd2ee4
Redaction: the only edit is Per-arm outcomes, straight from the files:
Agreed on the reading: zero-vs-zero bounds the rate (≤ 3.7 % per arm at n = 80) rather than showing a change in it. |
Issue for this PR
Closes #47168
This addresses the prompt mismatch. The intermittent stop in the original report is still unverified and needs to remain tracked; the current PR check requires a closing issue link.
Type of change
What does this PR do?
The GPT prompt asks for progress updates on a
commentarychannel, which OpenAI-compatible Chat Completions does not support. #47168 reports progress text ending a turn before the work is done, but that failure has not been reproduced naturally in the controlled comparison below.This splits out the channel section and omits it for
@ai-sdk/openai-compatible, including versioned npm specs. The rest of the GPT prompt and the loop's stopping rules are unchanged. The OpenAI Responses path keeps the channel instructions.How did you verify your code works?
foundry-gpt-*IDs from the report. The pinned/tagged cases failed before the follow-up fix; Responses still keeps the channel section.bun test test/session/system.test.ts test/session/prompt.test.ts: 69 pass, 1 existing skip.bun typecheckand the repository pre-push typecheck pass.The reporter confirmed the prompt change with their LiteLLM setup, then ran a batch comparing base
5cf9f51with head5de5c9a: 10 tasks, 8 repetitions per task per build, 160 runs total. Both builds completed all 80 tasks without a premature stop or error. Mid-task assistant text decreased on the PR head in 33 paired runs, increased in none, and tied in 47.Those are reporter-provided results, not an independent reproduction. The batch used one
gpt-5.5model behind LiteLLM, fresh sessions and scripted tasks, with external plugins and the custom skill library removed from both configurations. The original report came from long interactive sessions. This confirms a runtime effect in that setup, but does not demonstrate a lower premature-stop rate or rule out regressions elsewhere.Screenshots / recordings
Not applicable.
Checklist