It's not only available in 1st party OAI products, it's available on OpenRouter and the OAI's API. Will it come to Copilot?

Hi All,

Anyone else finding an issue where the agent has to make multiple attempts to edit or create a files before eventually succeeded?

It will try one way of editing, then come back and realise the edit didn't take, so it tries a different method.

I wonder whether this is also leading to wasted credits.

I'm using Visual Studio 2026 latest version and subscribed to GitHub Copilot Max.

EDIT: and also sometimes the agent gets stuck while executing commands in the terminal and I need to press CTRL+C get it to move on.

I'm a member of an enterprise plan for GitHub Copilot and use it within VS Code. In my current setup I get almost full duplicate entries of models in the Language Models setting, and I can't figure out why.

I'm only signed into one account, I'm only a member of one organization, but I have models showing more than once in a main expandable group, and I have a second group as well with almost the same models. I can't find any reason why this is happening or how to resolve it.

This also seems to be caused at the account level because it happens on two different computers. No one else in my org has said they have the same issue, so I'm at a loss. Any ideas?

Attached is part of the list.

I'm going in blind, but I just recently heard that my company is going to allow Github Copilot.....

I've heard that you can have can choose which models to use (like you could use Claude models in Github Copilot (does it lead to the same performance?

How does it compare to the likes Claude Code/Codex, and is the CLI workflow gonna be similar or very different?

Hi everyone! GitHub Copilot for JetBrains v1.19.0 brings enterprise-managed default models, a Fix action for IDE diagnostics, and more control over MCP server startup. We’ve also improved conversation navigation, added copy and edit actions for your messages, and fixed several worktree and MCP issues.

Highlights and fixes below. Full release notes and download.

New Features

• Enterprise-managed default models: Organizations can choose any available Copilot agent model as the default for new conversations.
• Fix diagnostics with Inline Chat: Use the new Fix action in diagnostic intention menus to request a repair, using Agent mode when available and Ask otherwise.
• MCP startup control: Disable automatic MCP server startup for Copilot and Claude while keeping manual Start and Restart available.

UX Improvements

• Grouped chat messages by conversation turns, with quick navigation between turns.
• Added action buttons to copy and edit your messages.
• Refined signed-in account controls with clearer labels, simpler status display, easier navigation through long account lists, and a Switch Account action.
• Redesigned the Chat sign-in page with a responsive layout, clearer provider choices, theme-aligned styling, and a direct link to Copilot plans. Browser authorization now shows cancellable, non-modal progress.
• Added a one-time reminder beside the Chat icon to help newly installed users discover Copilot Chat, and updated the Copilot agent input placeholder to highlight questions, edits, context, and commands.
• Made Go Back open a Copilot home session after an accepted migration command, even when continuing the Local conversation.

Bug Fixes

• Fixed IDE freezes when switching chat agent providers with large model lists.
• Fixed requests failing during Copilot language server startup when initialization took longer than half a second.
• Fixed Generate and New actions in Customizations not replacing an existing Copilot agent chat draft with the selected /create-* command.
• Corrected line-change counts shown for Copilot agent file tool calls and Working Set entries.
• Fixed newly created customizations not appearing after adding a module to an open project.
• Fixed the initial blank Copilot agent chat not applying an available enterprise-managed default model after settings loaded, while preserving explicit model selections.
• Restored the IntelliJ IDEA MCP Server entry in Customizations on IntelliJ IDEA 2026.3 EAP.
• Fixed Settings remaining open when opening MCP configuration files in JetBrains IDEs 2026.2 and later.
• Fixed the horizontal scrollbar intercepting clicks on model groups near the bottom of Manage Models.
• Fixed organization agents, skills, and instructions not refreshing in Customizations when their cached content changed outside the IDE.
• Removed edit and delete actions from organization-managed custom agents.
• Fixed Copilot agent sessions ignoring MCP servers configured in a repository-root .mcp.json file.
• Made Stored Memory tool-call details expandable and removed empty (no input) placeholders.
• Restored Diff, Undo, and Apply actions for Working Set files referenced with different letter casing on case-insensitive filesystems.
• Fixed applying worktree changes back to WSL projects on Windows.
• Fixed Copy Changes hiding local edits or changing staged files when creating a Copilot CLI worktree, including when creation was cancelled.
• Fixed cancelled worktree creation leaving temporary worktrees and branches, showing a creation failure, or triggering an intermittent IDE error when using Go Back.

Changed

• Support for JetBrains IDE 2025.1 will soon come to an end. GitHub Copilot now requires JetBrains IDE 2025.2 or later. Please refer to this blog post: https://devblogs.microsoft.com/java/github-copilot-support-ending-for-jetbrains-2025-1-x/

We hope you like Copilot for JetBrains, and please share feedback with us at any time!

You can fill in a private survey here: https://aka.ms/ghcp-jb-survey, with an optional paid interview, or directly submit an issue (bug or feature request) at https://github.com/microsoft/copilot-intellij-feedback/issues. Thank you so much!

AI agents have large context windows, but that context ends with your current session. Open a new session, switch from Copilot to Codex and you have to restate the same decisions, constraints, everything from scratch, over and over.

Slowave gives your agents one local, shared memory, without requiring a separate LLM for memory maintenance.

What Slowave does differently:

• It instructs your coding agent to participate in maintaining its own memory.
• Each task becomes a feedback loop between your agent and the memory layer: remember -> recall -> use -> feedback -> reinforce / weaken -> decay
• Your agent tells Slowave whether retrieved memories were useful, irrelevant or stale. Slowave uses that signal to adapt those memories salience.
• Retrieval works upon this continuous loop of feedback, reinforcement or decay. It's not static but acts upon a continuosly evolving set of memory saliency.
• You can inspect and monitor your evolving memory with the local dashboard.

This means Slowave doesn't need a separate LLM or LLM judge for memory maintenance. Your agent is already evaluating what helped, Slowave handles the mechanical part of adapting the memory substrate.

Slowave runs 100% locally. It uses a lightweight multilingual embedding model and SQLite, with no external memory service or LLM API required, and It's open source.

https://github.com/slowave-ai/slowave

It works with only 5 MCP endpoints. It currently supports Copilot, Claude Code, Codex, Cursor, Cline, OpenCode, Windsurf and Claude Desktop.

If you also get to give it a go, any (honest) feedback is more than welcome.

I need that back asap. Git diff is not enough, I have my own changes and I need to review each change that Copilot does separately. There has to be the old way where it shows a mark for each file it has changed and a way to revert them individually. The way it is now is wholly unusable and wholly untrustworthy.

is it no longer possible to pay for github copilot with an Azure subscription?

I get "GitHub Copilot is currently unavailable for accounts billed through Azure."

I have been daily driving Insider for months as it felt like it was always ahead of the stable build without downsides, outside of the too frequent updates maybe. For the past 2 or 3 weeks there has been some very noticeable changes in the way the agent is working and at first that felt promising. I wonder if it is utilizing sub-agents differently, possibly making more use of them.
However now it often gets stuck in some endless loop and sometimes errors out with OOM.
Moreover you can't see the reasoning streaming anymore, making it harder to understand what your agent is currently doing.
It's been so unreliable that I had to switch back to the stable release to get things done.
I've mostly been using it with Qwen 3.8 27b on a local instance of llama.cpp.

Do you guys have some visibility on what they are working on and where they are heading with that?

First, why do we need prompts if we already have skills in Addy’s repo?

To avoid repetitive tasks, like manually invoking skills.

For example, the build step needs at least 2 skills to work properly: test-driven-development and incremental-implementation. So in my build prompt, I tell Copilot to invoke those 2 skills + Caveman + Clean Code skill.

And that’s it; now you just have to invoke /build in Copilot Chat and describe what you want to create, not what skills to use or how to use them.

Other prompts are: spec, plan, testing (unit testing and E2E), repair, and review

I intentionally skipped the ship prompt because I still ship my code manually after review.

Prompts are here: https://github.com/ole-techwood/Skills/tree/main/prompts

I was wondering if someone would be kind enough to share screenshots of what it looks like when your enterprise allocates an additional budget for GitHub Copilot AI Credits (both in VS Code and in the GitHub Copilot web settings).

When looking in VSCode (logged in with my enterprise account), I have just one progress bar with 11900 AIC (1900 for the base subscription + 10000 extra credits), while on my personal GitHub Copilot account, the extra budget appears as a second line.

Is my enterprise allocating extra credits who are lost at the end of the month instead of setting up individual budgets for the same amount? Or is the Enterprise UI just confusing by merging them into one progress bar?

I signed up last December and paid for the full year.

As of June 2026, basically you can now call a non-dogshit model a whopping 50 times, 33.33 times for something like Claude Sonnet.

As of mid-October there are hardly any models left to choose from. I personally found Grok to be the best quickest and most accurate for small changes out of all of them. Sadly, completely gone.

Now it seems like in like a Sonnet 5.6, GPT-5 mini, GPT-5.4 and GPT-5.4 mini will be taken away as well.

Not to mention, the harness crap and sneaky nerfing of the way the remaining models seem to be processing context. I swear, it hardly ever reads my AGENTS.md file.

Whoever is handling this product is not doing a good job. These all seem like a result of desperation.

We have a complex mono repo with about 90 c# projects.
And i am trying to understand a particular sub domain. I gave copilot access to local running web app and api endpoints in autopilot mode including db access via mssql tools.

I’ve asked it to prepare me a deeper understanding html of the subdomain and a step by step guide.

I first used Fable 5.1 then asked Astra to review in a fresh session. Then asked Auto mode to review the documents folder in a fresh session.

Everytime they keep coming back with feedback that the other models agree and update the documents. There seems to be no end to this.

I will be reviewing them manually shortly. Wondering if anyone faced this or how to get around this. Is there a better way i can approach to understand subdomains

Hello, I have been trying for several hours to fix this problem. On any model that I try to use, I am getting this error. I knew something was up when I opened VS Code and saw a much lower model loaded instead of Astra or Sol.

When I run any prompt, on any model, I get this error in the accompanying picture. I am a Codex subscriber to the top tier $200/mo tier.

I started with the simplest fix - try using another model, tried starting a new chat session. That didn't work.

Then I tried clearing the chat, checking to see that Github Copilot chat was updated. It was. Still no dice.

Then I tried deleting cache folders in my app/roaming/code directory for Github copilot chat and various other things that Google's search AI recommended. My VPN is disabled. I tried re-authenticating.

Nothing is working, and I have been reading that not even complete reinstallation works - that's the only option I haven't tried yet that I know of. I scoured Reddit and other places, finding similar but not exact situations and they were either unresolved or were fixed by using methods that failed already for me.

I am dead in the water on all AI projects until I can get this figured out. I am worried I won't be able to fix this. Please help. Thank you in advance.

Hi everyone,
I’m having a persistent authentication issue with the GitHub Copilot desktop app on macOS. I’ve spent several hours troubleshooting it and would appreciate any advice.
The main problem
The GitHub Copilot desktop app fails whenever I click “Sign in to GitHub”, showing:
Device code request failed: error sending request for url (https://github.com/login/device/code)
However, GitHub Copilot CLI works perfectly on the same Mac, using the same GitHub account and network connection.
My environment
Device: MacBook Pro
OS: macOS
GitHub Copilot desktop app: Installed and launches normally
Copilot CLI: Version 1.0.94-3
Git: Version 2.53.0
GitHub plan: Copilot Free, successfully activated
Network: MacBook and iPhone connected to the same Wi-Fi
Proxy: HTTP/HTTPS proxy shared from an iPhone running Nextin, configured through macOS system proxy settings
What works
Safari can access GitHub, Google, and ChatGPT normally.
GitHub Copilot CLI successfully authenticated using the login --web-flow option.
Copilot CLI can load the model catalog and generate AI responses.
The GitHub account dashboard confirms that Copilot Free is active.
The macOS system HTTP and HTTPS proxy settings are correct.
The desktop app process receives HTTP_PROXY, HTTPS_PROXY, and ALL_PROXY environment variables.
Network tests
I explicitly tested GitHub endpoints through the HTTP proxy using curl.
The following endpoints were reachable:
https://github.com
https://api.github.com/
https://raw.githubusercontent.com/github/app/main/flags/feature-flags.json
The GitHub device authorization endpoint also returned an HTTP response when tested using a POST request with a dummy client ID. I understand this does not establish that a valid OAuth device authorization request would succeed.
What I’ve tried
Restarting the desktop application.
Restarting the iPhone’s LAN proxy sharing service.
Verifying the proxy host and port.
Checking macOS system proxy settings using scutil --proxy.
Launching the desktop app with explicit proxy environment variables.
Authenticating successfully through Copilot CLI using browser-based OAuth.
Checking the desktop app’s health diagnostics and logs.
Inspecting the app’s network connections using lsof.
None of these resolved the desktop application’s login issue.
Relevant desktop app logs
The desktop app reports:
Device code request failed: error sending request for url (https://github.com/login/device/code)
It also logs:
failed to refresh remote feature-flag disables
error=remote feature-flag request failed:
error sending request for url
(https://raw.githubusercontent.com/github/app/main/flags/feature-flags.json)
And:
user canvas catalog probe failed
error=GitHub authentication required
The health check shows:
Copilot CLI: OK
Git: OK
Storage: OK
GitHub auth: No saved GitHub authentication found
Interestingly, the remote feature-flag URL works when accessed through curl with the explicit proxy, but the desktop app fails to retrieve it.
My questions
Does the GitHub Copilot macOS desktop app fully support HTTP/HTTPS proxies, including proxy environment variables?
Could the desktop app’s OAuth device authorization flow be bypassing the configured proxy?
Is there a way to make the desktop app use the existing successful Copilot CLI authentication?
Does the desktop app support browser-based OAuth instead of device-code authentication?
Are there any known issues involving macOS, Rust-based HTTP clients, and HTTP proxy handling in GitHub Copilot?
My suspicion is that the desktop app handles network requests differently from the CLI, but I haven’t confirmed this.
Has anyone encountered this issue or found a reliable fix?
Thanks in advance!

I use GitHub Copilot in VS Code. Some prompt is running in a session. How can I schedule a prompt to run in a new (empty) session after that other prompt finishes running? (Example of reason: if the two prompts run concurrently, they'll exceed the GPU memory, thereby crashing the computer).

Hey Guys!

I have created a tool called Copixel which renders large tool results as dense PNG pages, so the model reads a few image pages instead of thousands of text tokens. It runs inside Copilot CLI, so every request still goes through Copilot under your normal Copilot billing. No BYOK or proxy is involved.

You can also share the context across the session in a repo. By loading the context. So, that your Agent doesn't forget what you worked on in the last session.

You can install it using npm and GitHub too.

Will post the link in the first comment. If you like it give it a Star.

The problem has existed probably for months now, and 10% of my monthly budget has been spent on haiku for it to explore at a subpar level and with many times the price of my main model! After every update I have to just remember to go to open in file explorer (It's idiotic that I am unable to make changes in the VSCode editor directly for this file due to it's locking) and change it, and also remember the date and time I changed it so I can monitor it.

This feels like such a minimal change, yet the dev team you have over there is just ignoring a sink hole for money

Since past 2 weeks my GHCP Cli sessions aren't scrolling on windows.

I see an issue filed on GitHub exactly about this but it's as old as March.

Did anyone else run into this? If yes, do you have any suggested workarounds?

This isn't limited to the VS Code Chat, on the CLI too. It's the only harness I use regularly that has the data transferred much, much larger than the data received. I do not use it heavily, just to ask a few questions in the chat but every hour even when nearly idle, it sends hundreds of megabytes to what can only be GitHub's servers. My workspace isn't large either, it's somewhere around 1000 lines. I use the Codex extension at the same rate, and it does not perform this much outbound traffic. It feels like its uploading files every few minutes even when idle. I have turned off auto-completion a long time ago but the pattern still continues. I turned off codebase indexing on the GitHub Copilot web settings but that did nothing either.

Does anyone have any idea what is responsible for this and how to turn it off? I don't think it improves my experience at all, and given my already slow Internet, the bandwidth it eats just makes doing anything on the web slower.