github-copilot: gemini-3.8-flash intermittently fails with "does not support Responses API" #53712

Activity

1. github-actions

   assigned

   kitlangton

   on Oct 7, 2026
2. github-actions

   added

   needs:complianceThis means the issue will auto-close after 2 hours.This means the issue will auto-close after 2 hours.

   on Oct 7, 2026
3. opencode-agent commented on Oct 7, 2026

   

   opencode-agentBot

   on Oct 7, 2026 – with OpenCode Agent

   Contributor

   More actions

   Thanks for the detailed report. I tried to reproduce this on 2.0.24 with a simulated provider: I made a model with a medium variant and an agent file that has only description, mode: subagent and model: <provider>/<model>#medium, then called it from a primary agent with the subagent tool. The subagent's request went to the configured model with the medium variant applied, so the variant was not dropped there.

   I couldn't test GitHub Copilot itself. Reading the code, the Copilot API used (Responses vs chat completions) comes from the model's supported endpoints, not from the variant, so something specific to your setup may be involved. Could you share:

   1. Which model and variant the child session actually shows (e.g. in the TUI footer when you open the subagent session), or the model stored for that child session.
   2. Whether it still fails with your plugins (@dietrichgebert/ponytail, @slkiser/opencode-quota) disabled.
   3. Whether the parent session uses the same github-copilot/gemini-3.8-flash model, and whether the parent works.
   4. A bit more of the server log around the error. It should show which model and variant the failing request used.

   You can either reply here with the details, or edit the issue and then leave a comment saying you've updated it.
4. mtheunissen82 commented on Oct 7, 2026

   

   mtheunissen82

   on Oct 7, 2026

   Author

   More actions

   Thanks for looking into this. My original diagnosis was wrong: the variant is not dropped.

   1. Child session model: both failing subagent sessions have the variant stored:

      "agent":"developer","model":{"id":"gemini-3.8-flash","providerID":"github-copilot","variant":"medium"},"outcome":"failed"

   2. Plugins disabled: not tested yet (see below, the failure is intermittent, so a single run wouldn't be conclusive).
   3. Parent session: github-copilot/claude-opus-5.5, works fine.
   4. Server log: the error line doesn't include the model or variant:

      level=ERROR message="Failed to drain Session" cause="AI.Error: model gemini-3.8-flash does not support Responses API.\n    at ej (/$bunfs/root/chunk-ka490d6x.js:6:3619)\n    at yD (/$bunfs/root/chunk-8easrj4b.js:30:8160) ...
      

   New finding: it's intermittent and not variant-related. After an opencode service restart:

   • opencode run -m github-copilot/gemini-3.8-flash#medium --format json "reply OK" failed once with the same error (session stored with variant: medium, outcome failed, provider.invalid-request event).
   • Right after that, 4/4 runs with #medium and 4/4 runs without a variant succeeded, as did a --agent developer run.

   My earlier "with variant works / without fails" comparison was just two single runs and is coincidence. Before the restart, every subagent call failed (3/3).

   So the real question is why the Copilot request is sometimes routed to the Responses API for gemini-3.8-flash. Possibly the model's supported-endpoints metadata is stale or inconsistent between refreshes, or Copilot itself is flaky. Happy to retitle the issue or close it if you think it's Copilot-side. Is there a debug flag that logs which endpoint is chosen per request?
5. mtheunissen82

   changed the title [-]agents: model #variant in agent frontmatter is dropped when invoked as subagent[/-] [+]github-copilot: gemini-3.8-flash intermittently fails with "does not support Responses API"[/+] on Oct 7, 2026
6. opencode-agent commented on Oct 7, 2026

   

   opencode-agentBot

   on Oct 7, 2026 – with OpenCode Agent

   Contributor

   More actions

   Thanks for following up and correcting the diagnosis. That helps a lot. I agree the variant isn't being dropped: in my test on 2.0.24 the subagent's request also kept its variant, and your child sessions store variant: "medium".

   The remaining problem is that some GitHub Copilot requests for gemini-3.8-flash fail with "does not support Responses API", whether or not a variant is set, and it seemed to clear up after an opencode service restart. That text doesn't come from OpenCode's own code, so it is most likely the error Copilot's API returned. In 2.0.24, OpenCode picks the Copilot endpoint (Responses vs chat completions) from the supported-endpoints list Copilot reports for each model when it fetches the model list. If Copilot sometimes lists /responses for this model, or an old model list stays in use until the service restarts, that could explain the intermittent failures.

   I can't check this here: it needs a real GitHub Copilot account and the live model data. A maintainer with Copilot access will need to look into it. Your observation that a service restart cleared the repeated failures is a useful clue for them. I don't know of a flag that logs the chosen endpoint for each request.
7. github-actions commented on Oct 7, 2026

   

   github-actionsBot

   on Oct 7, 2026 – with GitHub Actions

   Contributor

   More actions

   Thanks for the detailed update. The report has useful reproduction steps and environment details, but the Bug Report template requires a Description field. Please rename ## Summary to ## Description so the required field is present.
8. mtheunissen82 commented on Oct 7, 2026

   

   mtheunissen82

   on Oct 7, 2026

   Author

   More actions

   Found the likely root cause.

   The GitHub Copilot language hook in 2.0.24 uses options.endpoint when it's set. That value comes from the live Copilot /models supported_endpoints. When endpoint is missing, the hook falls back to a name heuristic that routes gemini-* to the Responses API:

   b = (gpt-N with N>=5 && !gpt-5-mini) || f.startsWith("grok-") || f.startsWith("gemini-") || f.startsWith("mai-code-");
   c.language = b ? c.sdk.responses(f) : c.sdk.chat(f)

   Copilot's /models returns "supported_endpoints": ["/chat/completions"] for gemini-3.8-flash (checked 6 times, consistent). So whenever the live endpoint isn't applied to the model, the request goes to /responses and Copilot rejects it with does not support Responses API. The models.dev catalog entry has no endpoint, so it can't fill the gap.

   This explains the intermittency. Failures line up with times the live metadata likely wasn't applied: a long-running service before restart, and the first request from a new directory right after a provider.updated reload.

   Suggested fix: don't route gemini-* to /responses in the fallback (or default to chat when supported_endpoints is unknown), and/or make sure the live supported_endpoints is always applied before the first request.
9. github-actions

   removed

   needs:complianceThis means the issue will auto-close after 2 hours.This means the issue will auto-close after 2 hours.

   on Oct 7, 2026
10. github-actions commented on Oct 7, 2026

    

    github-actionsBot

    on Oct 7, 2026 – with GitHub Actions

    Contributor

    More actions

    Thanks for updating the issue with the new findings, reproduction context, and system details.
11. mtheunissen82 commented on Oct 7, 2026

    

    mtheunissen82

    on Oct 7, 2026

    Author

    More actions

    Honestly, I have no clue why this was going wrong. I reverted my developer agent model to sonnet 5 (also copilot) and now again switched back to gemini 3.8 flash with medium effort and somehow now everything works flawlessly.
12. mtheunissen82

    closed this as completedon Oct 7, 2026