fix(opencode): correctly set x-initiator header for agent-initiated copilot requests

[aklajnert]

Issue for this PR

Closes #8030

Type of change

• Bug fix

What does this PR do?

Upstream commit 88226f3 (tweak: ensure that compaction message is tracked as agent initiated) already handles the case where the parent user message contains a compaction-typed part. Two cases are still missing:

• Compaction LLM call itself — when the agent is "compaction", the call should immediately set x-initiator: agent without fetching the parent message (which won't have a compaction part yet at that point)
• Synthetic follow-up message — the "Continue if you have next steps" message created after compaction has all parts marked synthetic: true; this should also be x-initiator: agent

Also removed the remaining throwOnError: true from sdk.session.get().

How did you verify your code works?

• End-to-end test via mitmproxy against a real Copilot session — all 4 steps complete with correct headers
• Unit tests pass (bun test in packages/opencode)

Screenshots / recordings

Not a UI change.

Checklist

• I have tested my changes locally
• I have not included unrelated changes in this PR

[github-actions]

Thanks for your contribution!

This PR doesn't have a linked issue. All PRs must reference an existing issue.

Please:

1. Open an issue describing the bug/feature (if one doesn't exist)
2. Add Fixes #<number> or Closes #<number> to this PR description

See CONTRIBUTING.md for details.

[github-actions]

Thanks for updating your PR! It now meets our contributing guidelines. 👍

[rekram1-node]

lookin

[aklajnert]

@rekram1-node - I have removed unnecessary code changes, and confirmed the code still works as expected. This is ready for re-review.

[rekram1-node]

Nice thanks!

I have to do 1 more pass just to make sure that all the synthetic messages actually make sense to behave in this way I have to be rlly rlly careful here cause I cant have ppl getting incorrectly blocked if the billing starts being misconfigured.

I've also been in a discussion w/ some members of copilot team and they recently asked about this stuff so I dont wanna step on their toes either.

In any case this fixes at least 1 actual bug case so I will hopefully tmr be able to merge

[dhruvkej9]

I traced this in code to answer the “4 pending bubbles” question.

• Each Enter in TUI sends a prompt call (sdk.client.session.prompt(...)):
  packages/opencode/src/cli/cmd/tui/component/prompt/index.tsx (around 697-714)
• Server receives each as POST /session/:sessionID/message and calls SessionPrompt.prompt(...):
  packages/opencode/src/server/routes/session.ts (784-821)
• SessionPrompt.prompt always persists each user message first via createUserMessage(...) before looping:
  packages/opencode/src/session/prompt.ts (951+, 1307-1325)

Important part:

• Session execution is serialized by a per-session runner (runner.ensureRunning(...)). If a run is already active, additional prompt calls do not start another concurrent run; they wait on the current run:
  packages/opencode/src/session/prompt.ts (118-134, 1570-1576),
  packages/opencode/src/effect/runner.ts (111-131)
• Inside the loop, it picks the latest user message (lastUser) per step and also folds newer user messages into system reminders:
  packages/opencode/src/session/prompt.ts (1352-1359, 1483-1498)

So: 4 pending bubbles = 4 user messages queued/persisted, but 1 active session run at a time.

That means provider calls are not strictly 1:1 with pending bubble count while the run is in flight (it can process multiple newly queued user messages in a later step of the same run).

[msgongora]

For the last three days, I have been using exclusively the build from this PR. I plan to keep it until it is merged. Premium burning seems to be fixed. Thanks @aklajnert

[inorilzy]

For the last three days, I have been using exclusively the build from this PR. I plan to keep it until it is merged. Premium burning seems to be fixed. Thanks @aklajnert

Are you using oh-my-openagent at the same time? I want to ask if it still works when using both tui and omo at the same time?

[rekram1-node]

So testing some things:

• reading images bills usage
• any slash command w/ subtask: true will not be billed at ALL << v bad can get u banned
  ^ the subtask itself is not billed which ig kinda counts as subagent but then when the content is returned to main session its not returned there either

[aklajnert]

Reading images seems like an unrelated bug?
Also, isn't subtask also called by the same model, which is a part of the initial request?

Do you want me to act on it somehow? I feel like both cases are not related to the autocompaction header.

[rekram1-node]

Nah u can define a slash command like this:

---
subtask: true
---

Hello

Anytime u invoke it, it will never result in any billing at all. (with ur changes)

---

Reading images seems like an unrelated bug?

Uh not unrelated, it is pre-existing bug but thats the primary mechanism that drains requests currently.

[aklajnert]

Ok, now I understand. I did another approach in the latest commit. Tested against all known cases and it seems to work correctly.

[rekram1-node]

Now the llm cant read images at all in normal fashion and all subagent requests will eat your quota.

[aklajnert]

Sorry, I think I've rushed too much. I'll try again tomorrow having in mind all that cases.

[rekram1-node]

We are also talking w/ the copilot team currently so all of this may change (ill keep this pr posted) I think they are already dealing with a lot of abuse as is.

[aklajnert]

OK, I’ve tested a case with regular autocompaction, a command with a subtask, and subagents. It seems that everything works as it should.

I think reading images should work as well, but I can’t test it. I’ve tried every model in Copilot, and they all either rejected the request with “model x not supported for vision” or, in Grok’s case, accepted it but responded that it can’t read pictures. I also tested this in the production OpenCode environment and observed the same behavior. Which model supports vision? Could it be blocked at the enterprise level?

The CI failure seems to come from a flaky test. I can’t rerun it without another commit, so perhaps someone from the dev team can trigger CI again.

[dhruvkej9]

OK, I’ve tested a case with regular autocompaction, a command with a subtask, and subagents. It seems that everything works as it should.

I think reading images should work as well, but I can’t test it. I’ve tried every model in Copilot, and they all either rejected the request with “model x not supported for vision” or, in Grok’s case, accepted it but responded that it can’t read pictures. I also tested this in the production OpenCode environment and observed the same behavior. Which model supports vision? Could it be blocked at the enterprise level?

The CI failure seems to come from a flaky test. I can’t rerun it without another commit, so perhaps someone from the dev team can trigger CI again.

Gpt 5.3 codex, sonnet 4.5, opus 4.5, sonnet 4.6, opus 4.6, gpt 5.4, gpt 5.4 mini, gemini 3.1 pro, gemini 3 flash

All supports images

[aklajnert]

Gpt 5.3 codex, sonnet 4.5, opus 4.5, sonnet 4.6, opus 4.6, gpt 5.4, gpt 5.4 mini, gemini 3.1 pro, gemini 3 flash

All supports images

Should I enable it in the configuration somehow? I can't find it anywhere. In VSC I can use images, but not in OpenCode. For the model that works in VSC, in OpenCode I get an error that the model doesn't support vision. I have tried to enable it in the config, but it didn't work for me. I'm checking the released OpenCode versions, not my branch.