You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Copilot stopped work due to an error Execution failed: Error: Reasoning effort 'medium' is not supported for model 'gemini-3.8-flash'. #68529
@pelikhan I looked into this; details are on #68726 (#68726 (comment)). The screenshot is the Copilot cloud agent's own chat, so no gh-aw workflow is involved. I made the same assignment call that gh-aw's assign-to-agent makes, with gemini-3.8-flash at effort medium, and the session ran to completion. Copilot /models lists low, medium and high for Gemini Flash. So this doesn't reproduce today and looks like a Copilot cloud agent problem (or a transient one on 13 Oct), not something gh-aw can fix.
The Claude-on-Copilot effort 400 we found along the way is a separate gh-aw bug, now #68834.
FWIW, I've tried opening a GitHub support ticket once before (for some topic unrelated to this), and it was closed on sight with the reason that "I'm demanding a level of support I'm not entitled to". So please if this is something to be raised within some internal team, can you raise that for me, please?
@kubo6472 Thanks for the nudge. We reproduced this on 16 Oct with a different model (gpt-6.1-sol at max failed the same way while Copilot's /models listed that effort) and traced it to the Copilot cloud agent: it passes the chosen effort to the session without checking it, and the session rejects efforts its own model list doesn't advertise. I've filed it with the cloud agent team internally, with both reports. Until it's fixed, leaving the reasoning effort unset, or choosing another effort or model, avoids the failure; we can't yet tell which other efforts each model accepts.
@kubo6472 Thanks, that's useful: with Auto, the cloud agent picks the model and the effort itself, so this isn't something you can avoid by choosing differently. I've added that to the internal report. Until it's fixed, picking a model explicitly (and leaving effort unset) should avoid it.
Activity
pelikhan commentedon Oct 14, 2026
@SivaKesava1 could you take a peek at this one?
SivaKesava1 commentedon Oct 15, 2026
@pelikhan I looked into this; details are on #68726 (#68726 (comment)). The screenshot is the Copilot cloud agent's own chat, so no gh-aw workflow is involved. I made the same assignment call that gh-aw's
assign-to-agentmakes, withgemini-3.8-flashat effortmedium, and the session ran to completion. Copilot/modelslistslow,mediumandhighfor Gemini Flash. So this doesn't reproduce today and looks like a Copilot cloud agent problem (or a transient one on 13 Oct), not something gh-aw can fix.The Claude-on-Copilot effort 400 we found along the way is a separate gh-aw bug, now #68834.
kubo6472 commentedon Oct 16, 2026
FWIW, I've tried opening a GitHub support ticket once before (for some topic unrelated to this), and it was closed on sight with the reason that "I'm demanding a level of support I'm not entitled to". So please if this is something to be raised within some internal team, can you raise that for me, please?
SivaKesava1 commentedon Oct 17, 2026
@kubo6472 Thanks for the nudge. We reproduced this on 16 Oct with a different model (
gpt-6.1-solatmaxfailed the same way while Copilot's/modelslisted that effort) and traced it to the Copilot cloud agent: it passes the chosen effort to the session without checking it, and the session rejects efforts its own model list doesn't advertise. I've filed it with the cloud agent team internally, with both reports. Until it's fixed, leaving the reasoning effort unset, or choosing another effort or model, avoids the failure; we can't yet tell which other efforts each model accepts.kubo6472 commentedon Oct 18, 2026
@SivaKesava1 it went on AUTO for me specifically, it chose the gemini and tried choosing the effort supposedly.
SivaKesava1 commentedon Oct 18, 2026
@kubo6472 Thanks, that's useful: with Auto, the cloud agent picks the model and the effort itself, so this isn't something you can avoid by choosing differently. I've added that to the internal report. Until it's fixed, picking a model explicitly (and leaving effort unset) should avoid it.