![\"Diagram](\"https://github.blog/wp-content/uploads/2026/06/architecture.png?resize=1024%2C753\")
Qubot, our internal Copilot-powered analytics agent, allows any GitHub employee to ask questions about our data in plain language. Here's what we learned as we built it.
\nThe post How we built an internal data analytics agent appeared first on The GitHub Blog.
\n","@content":"\nLarge data and analytics organizations often struggle to make access to data and insights truly self-serve. The industry tried to solve this problem, quite unsuccessfully, for decades, but now AI is giving us a credible way to do just that.
\n\n\n\nAt GitHub scale, providing dedicated analytics support to dozens of product teams is challenging, and therefore many teams are left to solve this problem on their own. Though there is a lot of valuable product telemetry that product and engineering teams can use to make decisions, figuring out which data model, which grain, which filter, and then write the query and validate the result has always been difficult without the support of a data analyst.
\n\n\n\nEnter Qubot, our internal GitHub Copilot-powered analytics agent. Qubot allows any Hubber (that’s what we call GitHub employees) to ask questions about any data model in GitHub’s data warehouse in plain language and get an answer within seconds.
\n\n\n\nQubot is not a reporting tool or a dashboard replacement. Instead, it’s intended for exploratory questions like “Which cohort of users has the highest retention on this feature?” or “What product contributed to move this metric the most last week?” Qubot has zero cost maintenance and helps teams ramp up quickly on datasets they may be unfamiliar with.
\n\n\n\nIn this blog post, we’ll go over how we built Qubot, how it’s changed, and what we learned.
\n\n\n\nThe architecture has three main components: user interface, context layer, and query engine.
\n\n\n\nQubot is accessible through Slack, VS Code, and the Copilot CLI. The Slack interface doesn’t require any configuration, and it is the preferred collaboration tool of Hubbers. When someone posts a question in the Qubot Slack channel, a Qubot instance is spawned as a Copilot Cloud Agent running on github.com. The answer is provided directly in Slack, allowing the user to share the result with others, but also iterate in the thread to evolve or refine the question. All the results are also stored as a markdown report in a pull request that the user can reference to fine tune the query or use it in a dashboard.
\n\n\n\nQubot is also available in VS Code and the Copilot CLI, for users that want an experience more integrated with their workflows. Qubot can be installed with one command as a plugin, and it becomes available in any agent session in VS Code or Copilot CLI alongside any other custom agents, skills, and tools configured by the user.
\n\n\n\nOur data warehouse contains data at different stages of curation: raw events (bronze), conformed facts and dimensions (silver), and curated datasets designed for specific business use cases (gold). The context layer is built in a federated way, with knowledge that is tailored to the type of data.
\n\n\n\nWe also leverage our ETL pipelines to systematically enrich the context layer with additional signals and derived metadata. The context is loaded at runtime via the GitHub MCP Server, fetching it from the context layer.
\n\n\n\nThe context layer is constantly enriched with new knowledge persisted across multiple repositories. At GitHub, we primarily use markdown for documentation, so we don’t need to interface with multiple different tools.
\n\n\n\nWe’ve streamlined federated context contribution through a context agent. Teams can contribute via a standardized template or by referencing a repository containing relevant context. The agent then ingests, organizes, and normalizes this information into a structured format that has proven effective for Qubot based on our evaluations.
\n\n\n\nEvery change to the context layer or agent configuration gets evaluated before it ships. When someone wants to enrich the context layer with new knowledge, they can open a pull request. The new context goes through an offline eval framework that measures accuracy of the response, latency in finding the right answer, and catches regressions before they reach users.
\n\n\n\nThe benchmarking framework for evaluating Qubot across structured test cases has three components:
\n\n\n\ngh agent-task create, runs multiple parallel trials, polls for completion, and saves detailed JSON results.The end-to-end flow is: define test cases → run Qubot N times per case → collect results → aggregate stats → compare configurations.
\n\n\n\nQubot connects to both Kusto and Trino, the two query engines that power most of GitHub’s analytics workloads, via a MCP server. We developed a custom implementation of the Trino MCP server, while for Kusto we deployed a local version of the Fabric RTI MCP Server. Kusto is fast and well-suited to exploratory questions over recent event data. Trino handles complex joins and deeper historical analysis.
\n\n\n\nRather than forcing users to know which to use, Qubot defaults to Kusto and switches to Trino automatically when the question requires it.
\n\n\n\nQubot has been widely adopted at GitHub, with hundreds of enthusiastic users running thousands of queries. The number of questions that Hubbers ask in the data and analytics Slack channels has reduced dramatically, because now they can explore the data with greater autonomy and reach out only for complicated questions. It also allows Hubbers that never dared to dip into the data warehouse to access the data they need to drive their decision making. That is one of the reasons for offering multiple interfaces like Slack, Copilot CLI, and VS Code; Hubbers are very technical, but we wanted to offer an option with no barrier to entry and zero configuration.
\n\n\n\nWe quickly discovered that the context layer is key to enriching the reasoning capabilities of Copilot and to create an expert analytics agent. In our experiments we found that structured and well curated context not only makes Qubot more accurate, but also three times faster at returning the right answer. This has profound implications on the analytics engineering discipline, because it makes this type of artifact a first class citizen in how data is modeled, rather than an afterthought.
\n\n\n\nQubot has been a rare example of successful hub-and-spoke execution. It removes strain from the data and analytics team, as product teams own the telemetry for their surfaces and business teams own the definition of their gold data. Qubot acted as a gravitational force to centralize all this distributed knowledge into a single tool that can benefit all GitHub, providing incentives to partner teams to contribute to Qubot, instead of creating multiple tools limited to their own domains.
\n\n\n\nQubot engineering team: Weijie Tan, Tobias Tschuemperlin, Vamsi Anamaneni
\n\n\n\nSpecial thanks: Yaswanth Anantharaju
\n\nThe post How we built an internal data analytics agent appeared first on The GitHub Blog.
\n"},{"json_class":"Feedjira::Parser::AtomEntry","@author":"Natalie Guevara","@title_type":"html","@raw_title":"How pull request limits are cutting down the noise","@url":"https://github.blog/open-source/maintainers/how-pull-request-limits-are-cutting-down-the-noise/","@links":["https://github.blog/open-source/maintainers/how-pull-request-limits-are-cutting-down-the-noise/"],"@entry_id":"https://github.blog/?p=96841","@updated":{"json_class":"Time","s":1781734471,"n":0},"@published":{"json_class":"Time","s":1781798400,"n":0},"@categories":["Maintainers","Open Source","maintainers","open source","pull requests"],"@summary":"Learn how pull request limits can help manage contribution volume in your repositories, and see what’s next on the roadmap.
\nThe post How pull request limits are cutting down the noise appeared first on The GitHub Blog.
\n","@content":"\nMore people are contributing to open source than ever, most of them trying to help. The challenge is keeping up with the volume. Creating a pull request has never been easier. Reviewing one still takes a human about as long as it ever did. When great contributions and low-quality noise land in the same queue, the ones that deserve attention are harder to find.
\n\n\n\nThat’s why we’ve introduced pull request limits. It takes on the problem we hear most: too many incoming pull requests, too much low-quality noise, and too few ways to manage the flow.
\n\n\n\nA pull request limit sets the maximum number of pull requests a user without write access can have open at once in your repository. Hit the limit, and you must close or merge one before opening another. Pull requests opened by Copilot or another AI agent will counts toward your limit. Trusted contributors can be placed on a bypass list, where they are exempted from limits, but don’t gain full contributor access. Draft pull requests will not count towards your limit.
\n\n\n\n![\"A](\"https://github.blog/wp-content/uploads/2026/06/608690507-ead99df1-2879-43d6-8f5b-f04431eeefcf.jpg?resize=1024%2C566\")
GitHub already has interaction limits, but those are temporary cooldowns. These new pull request limits are persistent and configurable—giving maintainers the control they told us they were missing.
\n\n\n\nA cap also changes how contributors behave. When anyone can open a pull request in seconds, a polished change and a rough draft look the same in the queue. But when only a few pull requests can be open at once, a contributor must be selective and prioritize which contributions they want to be reviewed. That first judgment call happens before the pull request reaches you, and a smaller pool makes good work easier to spot.
\n\n\n\n\n\n\n\n\nIt’s helped us want to review pull requests again. Knowing that someone hasn’t just opened 5–10 pull requests that are slop makes it much easier to want to look. Going forward we expect it to help us manage our backlog and ensure the things people are working on are the things we need.
\nNicholas Tindle, AutoGPT
\n\n\n\n\nThis feature is great. We’ve had problems on Homebrew for a while with enthusiastic users submitting many pull requests that need near identical review. AI further accelerated it. This allows us to still have outside contribution and maintainers contribute more while gating users to a level of pull requests we can cope with.
\nMike McQuaid, Homebrew
\n\n\n\n\nAt OpenClaw we get a huge volume of pull requests from the community and had to build our own bots for fighting spam. We are super glad GitHub has been able to develop out-of-the-box solutions for maintainers now to manage this volume.
\nVincent Koc, OpenClaw
These limits are especially crucial right now because of a change in the ecosystem. In January 2023, developers merged about 25 million pull requests a month across GitHub. Today that number tops 90 million—a roughly 3.6x increase. More people are building in the open than at any point in GitHub’s history.
\n\n\n\nMost contributions come in good faith, and even good-faith work can pile up faster than one volunteer can answer. In February, we wrote that open source was hitting its own Eternal September. A pull request limit gives maintainers some of that attention back, without closing the door on the next contributor.
\n\n\n\nPull request limits are just the first step. The same feedback is pointed straight at what comes after: more flexible, more granular control over how contributions flow in.
\n\n\n\nArchiving pull requests (shipping soon): Repository admins will be able to archive pull requests, hiding low-quality or spammy pull requests out of the main pull request view. Archived pull requests stay accessible to admins, but can be filtered out of the default list. We chose archive over delete on purpose: some organizations can’t permanently delete pull requests for legal or compliance reasons, and many maintainers want to keep them for context.
\n\n\n\nIssue limits (in development): The controls you now have on pull requests will be applied to issues: per-repository caps on how many open issues a user without write access can have at once, with a bypass list, plus an option to restrict issue creation to collaborators.
\n\n\n\nSmarter bypass signals (up next): The goal is less manual trust management. Instead of curating a bypass list by hand, you could let contributors clear a limit automatically based on real signals: a previously merged pull request in the repo, account age, or organization membership. That frees maintainers from curating lists by hand and gives them more time to focus on the work itself.
\n\n\n\nCross-repository controls (exploring): A per-repository cap helps with repeated activity in one project, but it does nothing when someone opens pull requests across hundreds of repositories at once. We’re exploring ways to catch contributors who spray pull requests across multiple repositories, whether through trust signals, rate limiting, or other cross-repository controls.
\n\n\n\nOpen source runs on the people who show up every day. To everyone who reviews pull requests late at night, mentors a first-time contributor, triages a backlog, files issues, or tells us where our tools fall short: thank you. You shaped this feature, and your input is critical in helping us decide what comes next. We’ll keep building with you.
\n\n\n\nTry the pull request limit in your repository settings, and tell us where it helps and where it doesn’t.
\n\n\n\nSee you in the pull request queue. 🧡
\n\nThe post How pull request limits are cutting down the noise appeared first on The GitHub Blog.
\n"},{"json_class":"Feedjira::Parser::AtomEntry","@author":"Natalie Guevara","@title_type":"html","@raw_title":"Getting more from each token: How Copilot improves context handling and model routing","@url":"https://github.blog/ai-and-ml/github-copilot/getting-more-from-each-token-how-copilot-improves-context-handling-and-model-routing/","@links":["https://github.blog/ai-and-ml/github-copilot/getting-more-from-each-token-how-copilot-improves-context-handling-and-model-routing/"],"@entry_id":"https://github.blog/?p=96832","@updated":{"json_class":"Time","s":1781803402,"n":0},"@published":{"json_class":"Time","s":1781725306,"n":0},"@categories":["AI & ML","GitHub Copilot"],"@summary":"How GitHub Copilot is making more of each session go toward useful work, so your credits go further.
\nThe post Getting more from each token: How Copilot improves context handling and model routing appeared first on The GitHub Blog.
\n","@content":"\nAs Copilot takes on more agentic work, from planning and editing to debugging, reviewing, and calling tools across longer sessions, efficiency means more than using fewer tokens. It means being smarter about how you use them.
\n\n\n\nIncreasing efficiency starts with reducing what Copilot has to repeat from turn to turn, including context, tool definitions, and cached state. It continues with choosing the right model for the job. A quick explanation, a focused edit, and a complex multi-file change should not all be treated the same way.
\n\n\n\nWe are working on both: improving the Copilot harness so more of each session goes toward the task itself, and expanding Auto so Copilot can pick the model that fits the work without asking developers to make that choice every time. This post focuses on harness improvements in GitHub Copilot for VS Code and on ongoing work to expand Auto across Copilot surfaces.
\n\n\n\nIn longer GitHub Copilot sessions in VS Code, the harness prepares a lot of recurring information for the model: instructions, repository context, conversation history, available tools, and the current state of the task. Some of that context is needed. Some of it can be cached, deferred, or loaded only when it becomes relevant.
\n\n\n\nTwo improvements in GitHub Copilot for VS Code are doing most of the work here. Prompt caching helps Copilot reuse model state for repeated prompt prefixes instead of recomputing the same prefix on every request. Tool search lets the model load tool definitions on demand, instead of sending every full tool schema into context on every turn.
\n\n\n\nThat matters more as agents use more tools. A session may need access to MCP tools, terminal commands, file operations, workspace search, and product-specific actions. Loading every full tool definition up front adds fixed cost to each turn, even when only a small number of tools are relevant to the task. With tool search, Copilot can keep the available toolset broad while sending less unnecessary tool schema into the model.
\n\n\n\nFor a deeper technical look at the implementation, including prompt caching, cache-control breakpoints, provider-specific tool search, and how these changes work across long-running agentic sessions, read the VS Code technical deep dive.
\n\n\n\nAuto answers a practical question: which model is the best fit for this task right now?
\n\n\n\nAfter your first prompt, Copilot uses task intent and current model health to choose a model that best fits the task. Different kinds of work, like quick explanations, focused edits, or multi-file changes, do not all benefit from the same level of reasoning, so Auto makes that call without requiring you to tune model settings.
\n\n\n\nIn our evaluations, no single model consistently performed best across tasks. In many cases, a more efficient model reached the same outcome, while stronger models mattered most when the task required deeper reasoning. Auto learns where stronger reasoning improves the result. It routes up when the task demands it and stays more efficient when it does not. The goal is not to trade quality for cost, but to use the model that best fits the work.
\n\n\n\nAuto combines two signals: what model is healthy and available right now, and what kind of work Copilot is being asked to do.
\n\n\n\n![\"Chart](\"https://github.blog/wp-content/uploads/2026/06/608776889-fa214f25-8231-4b9f-a0cc-9eff3cbb1be8.png?resize=1024%2C576\")
![\"Chart](\"https://github.blog/wp-content/uploads/2026/06/608777067-4addfe82-4e15-4bca-ab71-907abbe0579e.png?resize=1024%2C576\")
Taken together, these signals let Auto avoid a one-size-fits-all approach. The point is not to send every task to the biggest model, or every task to the cheapest one. It is to choose the model that fits the work.
\n\n\n\nGetting routing right in evaluations is only part of the problem. To make Auto useful in real workflows, we also had to account for how developers actually use Copilot: conversations get longer, context builds up, tasks shift, and developers work in many languages.
\n\n\n\nCache-aware routing. Switching models on every turn may sound flexible, but it can work against efficiency. When a conversation stays on the same model, the prompt prefix can be cached and reused across turns. Switching models mid-conversation breaks that cache, which can cost more than the routing change saves. Auto avoids that by routing at natural cache boundaries: on the first turn, when there is no cache to lose, and after compaction, when Copilot summarizes older turns and the prompt prefix resets. Between those points, the selected model stays in place so the cache can keep building.
\n\n\n\nRouting across languages. Copilot serves developers around the world, so routing has to work in languages other than English. We trained the routing model on conversations across 16 language families, including CJK, European, and others. In evaluations, routing accuracy stayed within four points of the English baseline across language groups, with no statistically significant quality gap.
\n\n\n\n![\"Chart](\"https://github.blog/wp-content/uploads/2026/06/605338236-0e8f7a05-ba70-4471-806c-65aba753c914.png?resize=1024%2C576\")
Learning when escalation matters. Instead of labeling tasks as simply “easy” or “hard,” we trained the router to learn where models actually diverge. For each training query, responses from a less capable model and a more capable model are scored across quality dimensions. The router learns when the stronger model adds value, and when a more efficient model can produce an equally good result. For context-dependent messages in longer agentic sessions, the router is trained on complete multi-turn conversations, including the original user intent, recent assistant responses, and conversation metadata.
\n\n\n\nAuto with task intent is already live in Visual Studio Code, github.com, and mobile. It gives Copilot more signal about the kind of work you are doing, whether that is coding, debugging, planning, or using tools, so it can make a better model choice for the task.
\n\n\n\nWe are continuing to expand that experience across Copilot. Next, we are bringing Auto with task intent to more surfaces and adding more ways for teams to make Auto the default.
\n\n\n\nCopilot is getting more efficient by default, but a few habits can help your credits go further.
\n\n\n\nFor the full guide, see How to get more out of your AI credits.
\n\n\n\nAuto model selection is available today across supported Copilot experiences. To learn more, see the Auto model selection docs. You can also share feedback in Copilot discussions.
\n\n\n\nWe are continuing to make Copilot more efficient across the system so more of your credits go toward useful work, without requiring you to tune every model choice yourself.
\n\n\n\nThis post contains contributions from Nhu Do and Aashna Garg.
\n\n\n\n\n\nThe post Getting more from each token: How Copilot improves context handling and model routing appeared first on The GitHub Blog.
\n"},{"json_class":"Feedjira::Parser::AtomEntry","@author":"Natalie Guevara","@title_type":"html","@raw_title":"What are git worktrees, and why should I use them?","@url":"https://github.blog/ai-and-ml/github-copilot/what-are-git-worktrees-and-why-should-i-use-them/","@links":["https://github.blog/ai-and-ml/github-copilot/what-are-git-worktrees-and-why-should-i-use-them/"],"@entry_id":"https://github.blog/?p=96793","@updated":{"json_class":"Time","s":1781711623,"n":0},"@published":{"json_class":"Time","s":1781643534,"n":0},"@categories":["AI & ML","Git","GitHub Copilot","git worktrees","GitHub Copilot app"],"@summary":"Git worktrees have been around since 2015, but it wasn't until recently they became popular. Learn what they are, how to use them, and why you might.
\nThe post What are git worktrees, and why should I use them? appeared first on The GitHub Blog.
\n","@content":"\nIt seems like the latest hotness in git these days is the concept of worktrees. Which… is kind of funny because they’ve been around since 2015.
\n\n\n\nBut, nevertheless, they are cool, and you might be wondering why you’d use them, how they differ from branches, and why they are suddenly so popular.
\n\n\n\nLet’s talk about it!
\n\n\n\nLet’s say you lived in a worktree-less world, and were working on a ticket, and suddenly an urgent bug came to you and you had to switch contexts.
\n\n\n\nFirst, you might stash your work:
\n\n\ngit stash \"wip feature login\" Then you’d switch to your main branch and update:
\n\n\ngit checkout main \ngit pull origin mainThen make a bugfix branch:
\n\n\ngit checkout -b hotfix-bugThen you’d fix everything, commit, and push the branch:
\n\n\ngit add . \ngit commit -m \"fix broken submit button\" \ngit push origin hotfix-bugThen after merging a pull request, you might return back to your computer and pull main and remove the bug branch:
\n\n\ngit checkout main \ngit pull origin main \ngit branch -d hotfix-bug And then you could go back to the feature you were working on:
\n\n\ngit checkout feature-login \ngit stash popPhew. Where were we?
\n\n\n\nThe mental overhead of switching around, reloading files, reinstalling node_modules based on whatever changed, and so on, is a lot. The context switching burden is heavy.
Now, this is a basic example, but sometimes developers would work around this kind of chaos with doing some more complicated git stash commands, or even multiple clones of the same repo (I’m guilty of that one).
Until… worktrees!
\n\n\n\nWith worktrees, you never leave your branch and you never stash, and your editor context for your original feature stays untouched.
\n\n\ngit worktree add ../hotfix-workspace -b hotfix-bug mainThis instantly creates a sibling folder called hotfix-workspace, and bases it on main, and checks out a new branch called hotfix-bug.
Now you can open that folder in a new editor window (or cd into it) and fix the bug. Your original editor window stays exactly as you left it.
cd ../hotfix-workspace \n# ...fix fix fix... \ngit add . \ngit commit -m \"fix broken submit button\" \ngit push origin hotfix-bugYou merge the pull request online just like before, and once it’s merged, you can simply delete the temporary folder.
\n\n\ncd ../main-project \ngit worktree remove ../hotfix-workspaceThis is so much smoother! Worktrees can go beyond the git command line, too. For example, VS Code has full worktree support built in. You have options! And no matter where you work, worktrees give you zero risk of stash conflicts, there’s no editor disruption, and you can truly work in parallel.
\n\n\n\nFor a really long time, worktrees were relatively unknown. Most developers had never heard of them, because either Git GUIs didn’t support them (or treated them as second-class citizens), or because they just usually followed the known pattern of feature branch, then work, then PR, then merge, then repeat.
\n\n\n\nNow, our work as developers has changed. AI has made us work in parallel more than we ever have before in the history of software development. Developers run so many sessions in parallel, and “code review culture” is growing beyond “code writing culture.”
\n\n\n\nAgents and humans can do more in parallel with worktrees. It’s the default mode for the GitHub Copilot app, and for many other modern tools.
\n\n\n\nWorktrees do solve a whole lot of issues, but there’s definitely some things to watch out for.
\n\n\n\nnpm install or pip install across multiple of them, your computer might get very full, very quickly..gitignore requirements: if you create worktree folders inside your main repo directory, you have to manually add them to .gitignore to not accidentally track them. You can make these worktrees outside of your main repo (and many apps do that by default), but it’s worth noting.Great question! What’s awesome is they “just work” out of the box. When you open the app, there’s a dropdown that asks you where you want to run your new session on the home screen. The default is a new worktree.
\n\n\n\n![\"Screenshot](\"https://github.blog/wp-content/uploads/2026/06/Screenshot-2026-06-16-at-1.35.20-PM.png?resize=924%2C819\")
Then, once you kick off a new session, you can click the session name at the top of the app, and you’ll see the (fun!) generated name of your worktree, as well as the path where it’s located, the project that worktree is for, and details about the changes that you’ve made.
\n\n\n\n![\"Screenshot](\"https://github.blog/wp-content/uploads/2026/06/Screenshot-2026-06-16-at-1.36.45-PM.png?resize=877%2C331\")
Easy peasy lemon squeezy!
\n\n\n\nI will give you the most senior developer answer I can: It depends! You might prefer working in one way or another. You might not do as much work in parallel and like the mental model of branches and stashing. You might only do worktrees from now on. You might want to do both!
\n\n\n\nThe world’s your oyster, and you can try them all in the GitHub Copilot app today.
\n\nThe post What are git worktrees, and why should I use them? appeared first on The GitHub Blog.
\n"},{"json_class":"Feedjira::Parser::AtomEntry","@author":"Natalie Guevara","@title_type":"html","@raw_title":"GitHub Copilot CLI for Beginners: Overview of common slash commands","@url":"https://github.blog/ai-and-ml/github-copilot/github-copilot-cli-for-beginners-overview-of-common-slash-commands/","@links":["https://github.blog/ai-and-ml/github-copilot/github-copilot-cli-for-beginners-overview-of-common-slash-commands/"],"@entry_id":"https://github.blog/?p=96773","@updated":{"json_class":"Time","s":1781554534,"n":0},"@published":{"json_class":"Time","s":1781554531,"n":0},"@categories":["AI & ML","GitHub Copilot","GitHub Copilot CLI","GitHub Copilot CLI for Beginners"],"@summary":"GitHub Copilot CLI for Beginners: Learn how to use slash commands to control your terminal AI agent.
\nThe post GitHub Copilot CLI for Beginners: Overview of common slash commands appeared first on The GitHub Blog.
\n","@content":"\nWelcome back to GitHub Copilot CLI for Beginners! In this series (available in video and blog format), we’ll give you everything you need to get started using GitHub Copilot CLI. So far in this series, we’ve covered how to get started and when to use interactive and non-interactive modes. In this edition, we’ll learn what slash commands are, why they matter, and how to use slash commands to control GitHub Copilot efficiently. You can complete tasks like switching models, checking token usage, and resuming past sessions right from your terminal.
\n\n\n\nLet’s dive in!
\n\n\n\nWhen working in Copilot CLI, one of the most powerful concepts to learn early on is slash commands. Slash commands are built-in controls that you can access directly from the command line. Acting as your control surface within Copilot CLI, slash commands allow you to:
\n\n\n\nSlash commands can be thought of as your command center for interacting with Copilot CLI. To look at all of the options available, just type / in the command line for a scrollable list of all currently supported slash commands.
Let’s take a look at some of the most popular ones.
\n\n\n\nDifferent models are optimized for different kinds of work. If you want to switch models, type /model into the command line. This will display a list of available models, along with key details like:
Choosing the right model can significantly impact both speed and results.
\n\n\n\nCopilot CLI operates within a context window, which determines how much information it can “remember” during a session. If you want to check your current usage, type /context to learn how many tokens you have left, along with system usage and available buffer.
If you find that you’re running low on space, you can free up space by typing /compact in the command line. This summarizes your current conversation so you can continue without having to start a new session. Copilot CLI will do this automatically when you approach the limit, but you can also do this manually if you want to transition to a new task or clean up context mid-session.
If you’d rather start fresh and completely reset your environment, you can use /clear to clear the session entirely.
If you want to resume a previous session, you can type /resume. This will bring up a list of previous sessions you’ve had, including both local and remote sessions. Entering a previous session will show you your session history, and you can pick up right where you left off.
As you work with Copilot to make changes to your project, it’s important to keep track of what’s changed. If you want to see what the changes are, run /diff to see recent updates. This gives you a clear view of what modifications were made during your session, so you can validate changes before moving forward.
If you want to work across repositories or directories, you don’t have to exit Copilot. You can type /cwd to change your working directory to another repository. This allows you to scope Copilot’s work to a specific part of your project and helps you stay efficient while multitasking across codebases.
In the past, you might have granted Copilot CLI permission to perform actions like editing files. Say you’re switching to a repository you want to be more careful in and want to reset those permissions: you can do so by running /reset-allowed-tools.
Using these slash commands gives you even better control over Copilot CLI—and the more familiar you become with them, the more deliberate your workflow becomes.
\n\n\n\nWhether you’re switching models, managing context, or navigating across projects, using slash commands in CLI gives you the tools you need to stay in control. And if you haven’t already: open up your terminal, type /, and explore! There are many more slash commands to discover.
Happy coding!
\n\n\n\nLooking to try GitHub Copilot CLI? Read the docs and get started today.
\nMore resources to explore:
\n\n\n\nThe post GitHub Copilot CLI for Beginners: Overview of common slash commands appeared first on The GitHub Blog.
\n"},{"json_class":"Feedjira::Parser::AtomEntry","@author":"Natalie Guevara","@title_type":"html","@raw_title":"Accelerating researchers and developers building multilingual AI with a new open dataset","@url":"https://github.blog/ai-and-ml/llms/accelerating-researchers-and-developers-building-multilingual-ai-with-a-new-open-dataset/","@links":["https://github.blog/ai-and-ml/llms/accelerating-researchers-and-developers-building-multilingual-ai-with-a-new-open-dataset/"],"@entry_id":"https://github.blog/?p=96776","@updated":{"json_class":"Time","s":1781551052,"n":0},"@published":{"json_class":"Time","s":1781551050,"n":0},"@categories":["AI & ML","LLMs"],"@summary":"A new repository-level dataset, published on GitHub under CC0-1.0, helps researchers and developers discover multilingual developer content across READMEs, issues, and pull requests.
\nThe post Accelerating researchers and developers building multilingual AI with a new open dataset appeared first on The GitHub Blog.
\n","@content":"\nSoftware may be written in programming languages, but human language is at the heart of developer collaboration. Developers explain how projects work in READMEs. They ask for help in issues. They review, debate, and improve code in pull requests. That collaboration often happens in English—but not always. As AI becomes a bigger part of how developers build software, multilingual developer content matters more than ever.
\n\n\n\nToday, GitHub is publishing the GitHub Multilingual Repositories Dataset, a repository-level metadata dataset designed to help researchers and developers discover public GitHub repositories with evidence of non-English natural-language content. When building the dataset, we found that language distribution differs across READMEs, issues and pull requests: Korean is the most common non-English language in issue text, but only the fifth-most common in READMEs. Portuguese tops the non-English README list with more than 3 million repositories.
\n\n\n\nThe dataset is now available on GitHub under CC0-1.0. It follows through on a commitment we made in 2025, as part of Microsoft’s European Digital Commitments, to make multilingual data more accessible, including to open source AI developers.
\n\n\n\nThe GitHub Multilingual Repositories Dataset is intentionally not a dump of repository content. Instead, it is a metadata dataset that helps developers and researchers find repositories where multilingual collaboration may be happening. The dataset covers over 80 million classification rows across more than 40 million repositories. For each public repository, we provide:
\n\n\n\nWe deliberately did not collapse the three classifiers into a single label. Different classifiers have different coverage and confidence calibration, especially for lower-resource languages. By exposing all three, we let you decide how strict you want to be. Want a high-precision Greek subset? Require all three classifiers to agree above some confidence threshold. Want broad recall for an exploratory study of Romance languages? One classifier may be enough.
\n\n\n\nThe dataset is designed for the kind of work that’s hard to do with general web text:
\n\n\n\nLanguage identification is hard, especially in software repositories. Repository text is often short. It may include badges, templates, installation commands, code snippets, usernames, or mixed-language content. A 150-character sample may not represent the whole repository. Classifiers also vary in coverage and calibration, especially for lower-resource languages.
\n\n\n\nThat is why the dataset should not be treated as a ground-truth benchmark for language identification. Instead, it is designed as a transparent discovery tool. Users can inspect classifications, confidence scores, and sources, then choose the precision and recall tradeoffs that fit their own research or development workflow.
\n\n\n\nThe dataset also should not be used to infer sensitive attributes about repository owners, contributors, or communities. The signals are repository-level metadata, not person-level attributes.
\n\n\n\nToday, many European languages remain underrepresented in the online text used to build and evaluate AI systems. That creates a risk that AI tools work well for some developers, languages, and communities, while leaving others behind. Open data can help close that gap. We built this dataset because developer content is different from general web text. READMEs, issues, and pull requests contain the language of software collaboration: installation instructions, bug reports, feature requests, review comments, and community norms. That context can help build AI systems that better understand how developers actually work.
\n\n\n\nBy making multilingual developer-content signals easier to find and analyze, this dataset gives researchers, open source developers, and model builders another tool for studying language representation in software development. It can help identify gaps, support better evaluation, and inform more inclusive AI tools for developers across Europe and beyond. It also reflects a broader principle: Building AI for developers should include the communities, languages, and workflows developers actually use.
\n\n\n\nWe’ll be discussing the dataset, and the broader importance of open data for multilingual AI, at the Open Innovation Dialogue Hub in Strasbourg on June 16. The event is co-organized by the Microsoft Open Innovation Center, the Council of Europe, and GitHub, and will bring together policymakers, researchers, cultural institutions, and open innovation leaders to discuss AI, linguistic diversity, cultural heritage, and open data.
\n\n\n\nMultilingual AI needs multilingual developer communities. We hope this dataset helps more people study, support, and build for them. By releasing it under CC0-1.0 on GitHub, we’re inviting researchers, open source maintainers, and model builders to use it, critique it, extend it, and build evaluation sets and tools on top of it.
\n\n\n\nIf you do something interesting with it, we’d love to hear about it.
\n\nThe post Accelerating researchers and developers building multilingual AI with a new open dataset appeared first on The GitHub Blog.
\n"},{"json_class":"Feedjira::Parser::AtomEntry","@author":"Dylan Birtolo","@title_type":"html","@raw_title":"How we made GitHub Copilot CLI more selective about delegation","@url":"https://github.blog/ai-and-ml/how-we-made-github-copilot-cli-more-selective-about-delegation/","@links":["https://github.blog/ai-and-ml/how-we-made-github-copilot-cli-more-selective-about-delegation/"],"@entry_id":"https://github.blog/?p=96755","@updated":{"json_class":"Time","s":1781303185,"n":0},"@published":{"json_class":"Time","s":1781303183,"n":0},"@categories":["AI & ML","GitHub Copilot","AI agents","coding agent","GitHub Copilot CLI"],"@summary":"Better orchestration, fewer handoffs, faster progress, without a single new knob.
\nThe post How we made GitHub Copilot CLI more selective about delegation appeared first on The GitHub Blog.
\n","@content":"\nIn agentic systems, more delegation isn’t always better. Imagine asking Copilot CLI to make a simple change. Instead of handling it directly, it spins up a helper agent that searches the repository, waits on a result, and stalls. Work that should have taken one step now takes three. While some tasks genuinely benefit from a specialist subagent—like exploring an unfamiliar repository, checking an independent area of the code, or running a long command while the main agent keeps moving—delegation isn’t free. Every handoff adds coordination overhead, tool calls, and wait time. If an agent delegates too eagerly, the “help” can become friction.
\n\n\n\nWe recently released an improvement to our agentic harness called smarter subagent delegation. This makes Copilot CLI more selective by helping the main agent:
\n\n\n\nSmarter subagent delegation has now rolled out to 100% of Copilot CLI production traffic. If you want to get started today, simply update GitHub Copilot CLI by running the /update command in your terminal to version 1.0.42 or later.
In a production A/B test, this improvement reduced tool failures per session by 23%, including a 27% reduction in search tool failures and an 18% reduction in edit tool failures. It also improved total user wait time by 5% at P95 and 3% at P75, with no quality regression. Here, P95 captures wait time near the slowest 5% of sessions, while P75 reflects wait time toward the slower end of typical sessions. This means fewer unnecessary handoffs, fewer repeated searches, fewer failure-prone tool paths, and less waiting during long-running coding tasks.
\n\n\n\nIn this post, we’ll walk through how we identified unnecessary delegation in Copilot CLI, what we changed to make delegation more selective, and how we validated those changes through offline evaluation and production A/B testing. We’ll also show why those changes led to fewer failures and less waiting—and what that looks like for developers using Copilot CLI day to day.
\n\n\n\nThe problem: Delegation is powerful, but not free
\n\n\n\nSubagents are one of the most important capabilities in an agentic CLI. They let Copilot break down complex work, run investigations in parallel, and keep the main agent focused on coordinating the final answer. For large codebases and multi-step engineering tasks, that can be the difference between a slow linear workflow and an efficient parallel one.
\n\n\n\nBut delegation introduces its own failure modes:
\n\n\n\n![\"Animated](\"https://github.blog/wp-content/uploads/2026/06/fig1-tool-failures.gif?resize=768%2C432\")
Our goal: help developers use subagents when they create leverage, avoid them when they add overhead, and parallelize work when the task genuinely benefits from independent execution.
\n\n\n\nFrom problem signals to shipped improvement
\n\n\n\nThe way we identified the problem became the way we solved it. Instead of treating agent trajectory analysis, product changes, evaluation, and rollout as separate activities, we used them as one feedback loop: observe the agent behavior, isolate the orchestration bottleneck, make a targeted change, validate it offline, measure it online, and ship only once the end-to-end workflow improved.
\n\n\n\n![\"Flow](\"https://github.blog/wp-content/uploads/2026/06/fig2-slide-4-diagram.png?resize=1024%2C425\")
1. Analyze: Let LLMs identify the delegation bottleneck
\n\n\n\nInstead of manually reviewing agent sessions, we used LLMs to analyze full trajectories and identify where orchestration was helping versus where it was adding overhead. That analysis surfaced a consistent pattern: subagents were sometimes being invoked for tasks that were already narrow, obvious, or fully described in the handoff.
\n\n\n\nIn those cases, the subagent could spend time re-searching the repository even though the main agent already had enough context to act directly. That clarified the improvement target: keep simple discovery-and-edit tasks in the main agent, and reserve subagents for work that is broader, cross-cutting, or naturally parallelizable.
\n\n\n\n2. Change: Refine the orchestration policy
\n\n\n\nAfter identifying the bottleneck, we used LLMs to help translate that diagnosis into a more selective orchestration policy.
\n\n\n\nCopilot CLI should handle focused work directly: find a file, read it, make a targeted change, and verify it. Delegation is more useful when the work requires independent context, broad exploration, or parallel execution.
\n\n\n\nIn practice, that means starting with the narrowest effective path, escalating when complexity or uncertainty creates value, and stepping back down when the task becomes focused again. Subagents should be treated as a parallelism tool, not a pause button. When Copilot launches a subagent, the main agent should continue making progress on independent work rather than simply waiting for the result.
\n\n\n\nWhen a subagent is used, the handoff should also be specific: what the user asked, what is already known, what the subagent owns, and what kind of result the main agent needs back.
\n\n\n\n3. Validate: Test offline, confirm online, then ship
\n\n\n\nBefore broad rollout, we validated the change with automatically generated regression cases and existing benchmarks. This helped confirm that the new delegation guidance reduced avoidable overhead without breaking cases where subagents genuinely add value.
\n\n\n\nFinally, we moved through staff and public A/B testing, then analyzed production metrics across reliability, responsiveness, subagent workload, and quality. The gains did not come primarily from making individual LLM calls faster. Instead, it reduced orchestration overhead by avoiding unnecessary subagent paths and lowering subagent workload per user.
\n\n\n\nThat end-to-end process let us move from problem signal to shipped improvement while keeping the user experience stable: fewer avoidable handoffs, fewer failure-prone tool paths, and no quality regression.
\n\n\n\nOutcomes
\n\n\n\nAfter rolling smarter subagent delegation to production traffic, we saw measurable percentage improvements across reliability and responsiveness (Table 1):
\n\n\n\n| Dimension | Metric | Delta |
|---|---|---|
| Reliability | Tool failures per session | 23% reduction |
| Reliability | Search tool failures | 27% reduction |
| Reliability | Edit tool failures | 18% reduction |
| Responsiveness | Total user wait time at P95 | 5% lower |
| Responsiveness | Total user wait time at P75 | 3% lower |
| Quality | Quality metrics | No regression |
| Metric | Delta vs. control | Interpretation |
|---|---|---|
| Failed raw subagent search calls | 15% reduction | Reliability – fewer failure-prone subagent search paths. |
| Average subagent LLM duration per user | 12% lower | Responsiveness – reduced orchestration overhead per user. |
| P95 subagent LLM duration per user | 18% lower | Responsiveness – better worst-case subagent overhead. |
These results show that better orchestration can improve the developer experience even when the visible feature surface doesn’t change. By teaching Copilot CLI when to delegate, when not to delegate, and how to parallelize the right work, we reduced friction in the agent loop itself.
\n\n\n\nThat is the power of GitHub Copilot as a system: the experience gets better not because developers are given more switches to manage, but because Copilot becomes better at allocating models, tools, and subagents behind the scenes.
\n\n\n\nHow this benefits developers today
\n\n\n\nFor developers using Copilot CLI, this should feel like a smoother day-to-day experience. Straightforward tasks are more likely to be handled directly, complex tasks still get specialist help when it adds value, and long-running sessions keep moving with less unnecessary waiting. In practice, Copilot CLI becomes more efficient and less noisy without asking developers to work differently.
\n\n\n\nThe change is intentionally behind the scenes. Your workflow stays the same, but Copilot CLI is better at coordinating the work: fewer unnecessary handoffs, less repeated search work, fewer failed tool paths, and faster progress on long-running or multi-step tasks.
\n\n\n\nWhat’s next
\n\n\n\nThis work is one step toward our larger goal of improving how Copilot CLI chooses the right model, agent, and tools across your workflow. While having more agents and models available expands what Copilot can do, the value to developers depends on how well Copilot applies them across the work they are already doing, like reading files, running commands, and moving from an issue toward a pull request.
\n\n\n\nAs tasks become more complex, the quality of that orchestration matters more. The best system is not the one that delegates the most, but the one that knows when to act directly, when to delegate, and how to keep work moving without adding friction.
\n\n\n\nThe next step is making Copilot CLI more adaptive across models, agents, skills, and tools, so developers don’t have to decide whether a task needs a larger model, a specialist subagent, or a procedural skill. Copilot should make that decision based on the task, repository context, policy, and expected outcome.
\n\n\n\nWe will continue improving how Copilot CLI plans work, coordinates subagents, and measures end-to-end outcomes. That includes better visibility into main-agent and subagent behavior, deeper analysis of failure reasons, and stronger proxy metrics for orchestration quality. The goal is simple: less waiting, fewer avoidable failures, and more useful progress from every agent session.
\n\n\n\nGet started today and share feedback
\n\n\n\nUpdate GitHub Copilot CLI by running the /update command in your terminal to version 1.0.42 or later.
Already tried it? We’d love to hear what you think. Share feedback with the /feedback command in a CLI session or open an issue in our public repository.
Acknowledgements
\n\n\n\nSmarter subagent delegation was made possible by collaboration across Code|AI, Copilot CLI, experimentation, human evaluation, and product teams. Thanks to everyone who helped identify the problem, design the process, validate the outcome, and ship the improvement to production.
\n\nThe post How we made GitHub Copilot CLI more selective about delegation appeared first on The GitHub Blog.
\n"},{"json_class":"Feedjira::Parser::AtomEntry","@author":"Natalie Guevara","@title_type":"html","@raw_title":"GitHub availability report: May 2026","@url":"https://github.blog/news-insights/company-news/github-availability-report-may-2026/","@links":["https://github.blog/news-insights/company-news/github-availability-report-may-2026/"],"@entry_id":"https://github.blog/?p=96626","@updated":{"json_class":"Time","s":1781213418,"n":0},"@published":{"json_class":"Time","s":1781213415,"n":0},"@categories":["Company news","News & insights","GitHub Availability Report"],"@summary":"In May, we experienced nine incidents that resulted in degraded performance across GitHub services.
\nThe post GitHub availability report: May 2026 appeared first on The GitHub Blog.
\n","@content":"\nIn March and April we shared updates on GitHub’s availability and infrastructure investments. As that work continues and we approach some major milestones, we wanted to start sharing more regular updates in our monthly availability reports. So before we dive into incidents from May, here’s how we’re tracking with our ongoing work to make GitHub more reliable.
\n\n\n\nOur progress in making GitHub more resilient
\n\n\n\nThe short version: GitHub’s traffic is growing rapidly, driven in large part by AI-assisted and agentic development workflows, and we’ve been transforming our infrastructure to keep up with it. That means moving to Azure for elastic capacity, breaking our monolith apart into isolated services, and eliminating the shared failure points that have driven past incidents.
\n\n\n\nHere’s where we stand. We’re now serving 40% of monolith traffic from Azure (up from 8% in February), with Git traffic at 30% and repository replication at 99%. We’ve more than doubled our effective capacity in four months. At the same time, we’re completing the isolation of our primary database cluster: splitting users, authentication, and authorization into independent domains so that a problem in one can no longer cascade across the platform. Our new users service is fully cut over, and handling double the traffic at substantially lower database cost. Stateless authentication tokens are also rolling out, eliminating per-request database lookups that amplified pressure during traffic spikes.
\n\n\n\nWe are making structural changes that permanently remove failure modes. We acknowledge that we have work to do, but we’re committed to getting it done and making GitHub reliable when and where you need it. The principle guiding our decision is simple: availability, then capacity, then features.
\n\n\n\nThanks for your partnership as we keep building GitHub’s reliability and resilience.
\n\n\n\nIn May, we experienced nine incidents that resulted in degraded performance across GitHub services.
\n\n\n\nMay 04 15:45 UTC (lasting 55 minutes)
\n\n\n\nOn May 4, 2026, between 15:34 and 16:40 UTC, github.com experienced a service disruption that produced elevated latency and an increased rate of request failures across a broad set of customer-facing services. Total customer impact lasted approximately one hour and six minutes.
\n\n\n\nThe most significantly impacted service was pull requests, which was statused Red for the duration of peak impact. Issues, actions, webhooks, and Git operations experienced elevated latency and intermittent errors. A number of dependent services—including Codespaces, Pages, Packages, OAuth and GitHub Apps, Marketplace, and Copilot—also saw varying degrees of degraded performance due to shared data dependencies. At peak, approximately 1.3% of requests returned a 5xx response, averaging around 0.46% across the duration of the incident.
The disruption was triggered by a routine online schema migration running against a large, heavily-accessed database table. The migration had been progressing without issue for several hours, but as traffic ramped up toward the weekly peak, the combined load from the migration and normal production traffic saturated database connection capacity. This produced query contention on a primary database and cascading timeouts across services that depend on it.
\n\n\n\nThe incident was detected within approximately three minutes of the first signs of impact through a combination of automated monitoring and on-call observation. Once the contributing migration was identified, it was paused, and dependent services recovered shortly thereafter. Time to mitigation was approximately 33 minutes, and full resolution followed approximately 30 minutes later
\n\n\n\nAs follow-up, we are implementing several improvements to reduce the likelihood and blast radius of a similar event. Migrations against large, high-traffic tables will be more tightly aligned with low-traffic windows and will use dynamic throttling that adapts to live cluster load. We are adding automated circuit breakers that will pause in-flight migrations when latency or connection utilization on the underlying database crosses safe thresholds, and we are extending our monitoring so that migration-induced pressure (i.e., write rate, lock time, and connection saturation) triggers alerts before customer impact occurs. In parallel, we are reviewing connection-pool capacity to ensure adequate headroom is maintained while migrations are running.
\n\n\n\nMay 05 13:37 UTC (lasting 3 hours and 49 minutes)
\n\n\n\nMay 06 07:19 UTC (lasting 2 hours and 25 minutes)
\n\n\n\nOn May 5 and May 6, GitHub Actions was degraded across two related incidents affecting hosted runners. The two events were connected: remediation work performed after the May 5 incident introduced the configuration issue that triggered the May 6 incident.
\n\n\n\nOn May 5, 2026, from 13:22 to 17:05 UTC, GitHub Actions hosted runners in the East US region were degraded. Approximately 13.5% of jobs requesting a standard runner failed and ~16% of requested larger runners with private networking pinned to East US failed or were delayed by more than five minutes. Copilot code review requests were also impacted. Approximately 8,500 code review requests timed out during this window. Affected users saw an error comment on their pull requests and were able to retry by rerequesting a review. Most runner requests were picked up by other regions automatically, but a portion of requests still routing to East US were impacted.
\n\n\n\nThis was triggered by a scale-up operation for hosted runner VMs in the East US region. This is a regular operation, but the VM create load hit an internal rate limit when VM creates pull images from storage. Existing backoff logic was not triggered because of the response code returned in this case. The rate limiting and VM creation failures were mitigated by reducing load to allow for recovery and allowing queued work to be processed. By 15:34 UTC, queued and failed job assignments were mostly mitigated, with less than 0.5% of runner assignments impacted between 15:34 and full recovery at 17:05.
\n\n\n\nOn May 6, 2026, from 06:45 to 09:15 UTC, GitHub Actions Standard Ubuntu hosted runners were again degraded, and approximately 17.1% of jobs requesting a standard runner failed. The issue was caused by unexpected configuration data introduced during remediation work for the previous day’s incident, which blocked new allocations as daily load ramped up. We removed the problematic data at 08:51 UTC, allowing allocations to resume and runner pools to scale back up and recover.
\n\n\n\nWe are improving our system’s throttling behavior when limits occur, improving our controls to more quickly mitigate similar situations in the future, and reviewing all limits end-to-end for similar operations. In addition, we are updating the filter logic for this allocation data to be resilient to abnormal data shapes and improving monitoring to alert when allocations are blocked, allowing the team to respond before customer impact starts.
\n\n\n\nMay 06 11:21 UTC (lasting 38 minutes)
\n\n\n\nOn May 6, 2026, between 11:02 and 11:13 UTC, users were unable to start or view Copilot cloud agent or remote sessions. During this time, all requests to the session API returned errors, preventing users from creating new sessions or viewing existing ones. The issue was caused by a configuration change to the service’s network routing that inadvertently removed the ingress path for the service. The team reverted the change at 11:13 UTC which restored service. The incident remained open until 11:59 UTC while the team verified full recovery. We are taking steps to improve our deployment validation process to prevent similar configuration changes from impacting production traffic in the future.
\n\n\n\nMay 06 15:25 UTC (lasting 3 hours and 39 minutes)
\n\n\n\nOn May 6, 2026, between 15:12 and 19:02 UTC, creation of new pull request review threads on github.com failed. This included new line comments and file comments on pull requests. Existing pull requests and previously created comments were unaffected.
\n\n\n\nThis incident was caused by a 32-bit integer key reaching its maximum value in a Vitess lookup table used during pull request thread creation. The primary table was migrated to a 64-bit integer key, but the Vitess lookup table remained 32-bit. Once the values in the primary table passed the available 32-bit ID space attempts to create new review threads began failing, resulting in a near 100% failure rate for new thread creation requests. We mitigated the issue by updating the impacted lookup table definitions across all shards to use 64-bit integer column types, increasing the available ID range, and restoring normal operation. Service was fully restored once the schema changes competed globally.
\n\n\n\nTo help prevent similar incidents, we are expanding existing monitoring of database columns to include Vitess lookup tables and enabling earlier detection of any tables approaching a column size limit.
\n\n\n\nMay 07 05:02 UTC (lasting 1 hour and 54 minutes)
\n\n\n\nOn May 7, 2026, between 04:12 and 06:13 UTC, Copilot cloud agent and Copilot code review agent sessions for pull requests were delayed or failed to start.
\n\n\n\nDuring the impact window, new Copilot coding agent sessions triggered by pull requests were not created, while review agent sessions dropped by ~50% from the baseline.
\n\n\n\nThe issue was caused by follow-up recovery work from a separate pull request incident. As part of that recovery, we ran a large database migration, which caused replication delays on several replica hosts.
\n\n\n\nAlthough those replicas were not serving user traffic, our safeguards correctly treated the elevated replication lag as a signal to slow down writes to the affected database cluster. As a result, some pull request background processing was temporarily delayed. That processing is responsible for sending the internal events that Copilot agents use to begin work, so affected agents did not start until the database replicas caught up.
\n\n\n\nThe system recovered once replication lag returned to normal and pull request processing resumed. We are making critical background processing more resilient to replication lag so it degrades gracefully and keeps essential events flowing under strain, reducing the chance of similar secondary impact during future recovery work.
\n\n\n\nMay 15 08:13 UTC (lasting 35 minutes)
\n\n\n\nOn May 15, 2026, from 07:43 to 08:48 UTC, GitHub Actions experienced a degradation that caused workflow runs to fail or experience delayed starts for a subset of customers. The incident was triggered by a planned failover of supporting infrastructure used by GitHub Actions. During that operation, an automated service discovery update did not propagate correctly, which caused traffic to be routed incorrectly and increased request timeouts in a core dependency for workflow orchestration.
\n\n\n\nAt peak impact, 42% of Actions runs failed. Downstream services that depend on Actions workflow execution were also impacted, including GitHub Pages and Copilot cloud services. At 08:12 UTC, responders manually corrected the service discovery routing issue. Timeout and failure rates recovered shortly after, and we continued monitoring until full stabilization was confirmed across all affected services. The incident was marked resolved at 08:48 UTC.
\n\n\n\nTo prevent recurrence, we are taking several steps. First, we are implementing failover guardrails that validate service discovery state before completing failover operations. Second, we are strengthening verification checks. Finally, we are improving dependency resilience to reduce timeout cascades during infrastructure events.
\n\n\n\nMay 26 10:57 UTC (lasting 2 hours and 21 minutes)
\n\n\n\nOn May 26, 2026, between 10:40 and 12:56 UTC, GitHub Actions jobs were degraded. From 10:40 to 12:16 UTC, all newly queued runs failed to start. From 12:16 to 12:56 UTC, runs that required downloading actions for their workflows continued to fail. GitHub Pages, Copilot code review, Copilot coding agent, Octoshift, and GitHub Enterprise Importer were also impacted due to their dependency on GitHub Actions.
\n\n\n\nThis was caused by our automated account review system incorrectly suspending the service account used by GitHub Actions to authenticate workflow runs and download actions.
\n\n\n\nWe mitigated by restoring the account at 12:16 UTC, marking it exempt from further automated review at 12:20 UTC, and redeploying a related service at 12:48 UTC to flush cached account state. Full recovery was confirmed at 12:56 UTC.
\n\n\n\nDuring this incident, a small number of issues, pull requests, comments, and discussions were marked as hidden when the service account was disabled. No data was lost. All content hidden because of this incident has been restored and full search index restoration was completed.
\n\n\n\nTo prevent a recurrence, we have added an allowlist of all service accounts that cannot be suspended by automated systems, and ensuring these protections are enforced consistently across all account management tooling. We are also improving diagnostic tooling for accounts and reducing cache propagation delays to shorten time to mitigate similar incidents in the future.
\n\n\n\nMay 28 19:01 UTC (lasting 1 hour and 40 minutes)
\n\n\n\nOn May 28, 2026, between 18:27 and 20:41 UTC, the GitHub Copilot service was degraded due to an issue with the Responses API of an upstream provider affecting the GPT-5.2, GPT-5.3-Codex, GPT-5.4, and GPT-5.5 models. Requests routed to these models via the Responses API returned elevated error rates, which also affected Copilot coding agent and Copilot code review. No other models were impacted.
\n\n\n\nWe mitigated the incident by shifting traffic away from the affected models while the upstream provider deployed a fix.
\n\n\n\nGitHub is working to improve automated failover for the affected models and strengthen monitoring to prevent similar incidents in the future.
\n\n\n\nFollow our status page for real-time updates on status changes and post-incident recaps. To learn more about what we’re working on, check out the engineering section on the GitHub Blog.
\nThe post GitHub availability report: May 2026 appeared first on The GitHub Blog.
\n"},{"json_class":"Feedjira::Parser::AtomEntry","@author":"Natalie Guevara","@title_type":"html","@raw_title":"Making secret scanning more trustworthy: Reducing false positives at scale","@url":"https://github.blog/security/making-secret-scanning-more-trustworthy-reducing-false-positives-at-scale/","@links":["https://github.blog/security/making-secret-scanning-more-trustworthy-reducing-false-positives-at-scale/"],"@entry_id":"https://github.blog/?p=96621","@updated":{"json_class":"Time","s":1780703813,"n":0},"@published":{"json_class":"Time","s":1781193600,"n":0},"@categories":["AI & ML","LLMs","Security","Secret Scanning"],"@summary":"Alerts are more trustworthy and actionable when noise is reduced. See how we improved the verification step with context-aware LLM reasoning.
\nThe post Making secret scanning more trustworthy: Reducing false positives at scale appeared first on The GitHub Blog.
\n","@content":"\nSecret scanning plays a critical role in protecting developers and organizations. It helps catch exposed credentials early and prevents small mistakes from turning into real incidents.
\n\n\n\nAt GitHub’s scale, even small inefficiencies create real friction. Too many false positives make alerts harder to trust.
\n\n\n\nWhen alerts feel noisy, developers spend more time triaging and less time fixing real issues. Over time, this slows down remediation and reduces confidence in the system.
\n\n\n\nTo address this challenge, GitHub collaborated with Microsoft Security & AI’s Agents Offense team to bring more contextual reasoning into GitHub’s secret scanning verification. The collaboration applied the verification approach from Agentic Secret Finder, a broader detection and verification system developed to understand potential secrets in context, not just whether they match a secret-like pattern. This helped GitHub explore ways to reduce low-value alerts while preserving the coverage you expect from secret scanning.
\n\n\n\nGitHub secret scanning combines pattern-based detection with AI-based detection to identify potential secrets. Pattern-based detection catches known secret formats, such as partner patterns for tokens and API keys. AI-powered generic secret detection expands coverage to unstructured secrets like passwords that don’t match a known provider pattern.
\n\n\n\nGitHub already has industry-leading precision for provider-pattern secret detection at massive scale, processing billions of pushes and protecting tens of millions of developers across millions of repositories.
\n\n\n\nAs GitHub expanded into AI-powered secret detection, the next challenge was bringing the precision of AI-detected secrets closer to the same high standard as provider-pattern detections. This collaboration focused on combining GitHub’s large-scale detection pipeline with LLM-based contextual verification to improve alert quality and developer trust.
\n\n\n\nSecret scanning is most useful when you can quickly tell which alerts need action.
\n\n\n\nGitHub already has safeguards to reduce noise, but some secret-like values need more context to determine whether they represent a real exposure. To make those alerts easier to trust, we added more reasoning to the verification step.
\n\n\n\nBy looking at how a detected value appears in code, the system can better separate real exposures from values that only look sensitive. This helps you spend less time investigating low-value alerts and more time fixing the issues that matter.
\n\n\n\n![\"Flow](\"https://github.blog/wp-content/uploads/2026/06/blog-post-1.png?resize=1024%2C576\")
This approach builds directly on the existing system. Detection continues to generate candidates, and the verification step evaluates them. More context-awareness makes this system better at distinguishing real secrets from noise.
\n\n\n\nThe result is higher precision without changing upstream detection logic or reducing coverage.
\n\n\n\nA key challenge in verification is deciding what context to provide.
\n\n\n\nA small snippet of code is often not enough to determine whether something is a real secret. At the same time, passing entire files or repositories introduces too much noise and increases cost and latency.
\n\n\n\nInstead of giving more context, we’re giving better context.
\n\n\n\nRather than send large amounts of code, we extract a small set of high-signal information that helps explain how the value is used. For example, we look for cases where a value is assigned to a variable and later passed into an API request, authentication header, database client, or cloud SDK call. Pattern matching can tell us that a value looks like a secret, but it can’t tell us whether the value is actually being used as one. The surrounding usage context helps the model distinguish real exposures from false alarms, such as random UUIDs or opaque strings, without reviewing the full file or repository.
\n\n\n\n![\"A](\"https://github.blog/wp-content/uploads/2026/06/blog-post-2.png?resize=1024%2C576\")
It’s natural to assume that improving accuracy requires analyzing more of the codebase. But the opposite is true.
\n\n\n\nMost false positives can be resolved with focused, file-level context. What matters is not how much code the model sees, but whether it has the right signals.
\n\n\n\nIn many cases, you can determine whether a value is a real secret by looking at how it is used within a single file. Values that resemble placeholders, test data, or unused configuration can often be filtered out without deeper analysis.
\n\n\n\nThis keeps the system both effective and practical: high accuracy, low latency, and the ability to scale across large codebases.
\n\n\n\nWe evaluated this approach on hundreds of customer-confirmed false positive alerts.
\n\n\n\nOur target was a 65% reduction. The result was 75.76%, exceeding that goal while maintaining strong detection performance.
\n\n\n\nIn practice, this means significantly less noise and a higher proportion of alerts that require action.
\n\n\n\n![\"False](\"https://github.blog/wp-content/uploads/2026/06/blog-post-3.png?resize=1024%2C576\")
This improvement shows up directly in the developer experience. With fewer irrelevant alerts, it becomes easier to trust what you see. Less time is spent triaging noise, and real issues can be prioritized and fixed faster.
\n\n\n\nWe’re continuing to evaluate this approach on larger datasets and live traffic, while improving how context is extracted and used for verification.
\n\n\n\nReducing false positives has been a consistent need at scale. This work focuses on improving signal quality where it matters most, making alerts easier to trust and act on.
\n\n\n\nThe goal is simple: fewer distractions, clearer signals, and faster action on real risks.
\n\n\n\nGet started by running the risk assessment for your organization today, or learn more about secret scanning.
\nThe post Making secret scanning more trustworthy: Reducing false positives at scale appeared first on The GitHub Blog.
\n"},{"json_class":"Feedjira::Parser::AtomEntry","@author":"Natalie Guevara","@title_type":"html","@raw_title":"Give GitHub Copilot CLI real code intelligence with language servers","@url":"https://github.blog/ai-and-ml/github-copilot/give-github-copilot-cli-real-code-intelligence-with-language-servers/","@links":["https://github.blog/ai-and-ml/github-copilot/give-github-copilot-cli-real-code-intelligence-with-language-servers/"],"@entry_id":"https://github.blog/?p=96610","@updated":{"json_class":"Time","s":1780702410,"n":0},"@published":{"json_class":"Time","s":1781107200,"n":0},"@categories":["AI & ML","GitHub Copilot","GitHub Copilot CLI"],"@summary":"Install and configure LSP servers for GitHub Copilot CLI, replacing brute-force grep/decompile with real code intelligence.
\nThe post Give GitHub Copilot CLI real code intelligence with language servers appeared first on The GitHub Blog.
\n","@content":"\nEver watched GitHub Copilot CLI extract a JAR file to a temporary directory, grep through .class files, and piece together an API signature from raw bytecode? The agent is resourceful, but without a language server, that’s the best it can do.
The Language Server Protocol (LSP) is the standard that powers go to definition, find references, and type resolution in editors like VS Code. It works just as well in the terminal. The LSP Setup skill automates the installation and configuration of LSP servers for Copilot CLI, so the agent gets precise, structured answers about your code instead of relying on text search heuristics.
\n\n\n\nIn this post, you’ll learn how the skill works under the hood, see the configuration format it generates, and get set up for any of the 14 languages it supports today.
\n\n\n\nWithout an LSP server, the agent in GitHub Copilot CLI reverse-engineers API information through text search and binary extraction. For a Java project, that might look like:
\n\n\n# Find the dependency JAR \nfind ~/.m2/repository -name \"*httpclient*.jar\" \n \n# Extract it to a temp directory \nmkdir /tmp/httpclient && cd /tmp/httpclient \njar xf ~/.m2/repository/org/apache/httpcomponents/httpclient/4.5.14/httpclient-4.5.14.jar \n \n# Search extracted class files for a method \ngrep -r \"execute\" --include=\"*.class\" .For Python, the agent might cat files inside site-packages. For TypeScript, it walks node_modules. These text-based approaches work for simple cases, but they’re doing pattern-matching over raw text rather than true semantic analysis, so they miss generics, overloads, and transitive types, and can’t see compiled bytecode at all. That’s exactly the gap a language server close.
An LSP server solves this structurally. When the agent sends a textDocument/definition request for a symbol, the language server returns the exact source location, fully resolved type, and signature.
When triggered, the skill executes a seven-step workflow:
\n\n\n\nThe agent uses ask_user with a set of choices to determine which language the user needs LSP support for. This drives all subsequent steps.
The agent runs uname -s (or checks $env:OS / %OS% on Windows) to determine the target platform. Install commands vary by operating system. For example, brew install jdtls on macOS versus downloading from eclipse.org on Linux.
The skill includes a reference file (references/lsp-servers.md) with curated data for 14 languages: install commands per operating system, binary names, and ready-to-use config snippets. The agent reads this file and selects the matching entry.
The agent asks whether the config should be:
\n\n\n\n~/.copilot/lsp-config.json—applies to all repositorieslsp.json at the repository root or .github/lsp.json—scoped to a single projectRepository-level configuration takes precedence when both exist.
\n\n\n\nThe agent runs the appropriate install command. For example:
\n\n\n# TypeScript on any OS \nnpm install -g typescript typescript-language-server \n \n# Java on macOS \nbrew install jdtls \n \n# Rust on any OS \nrustup component add rust-analyzerThe agent writes or merges an entry into the chosen config file. The format uses a lspServers object where each key is a server identifier:
{ \n \"lspServers\": { \n \"java\": { \n \"command\": \"jdtls\", \n \"args\": [], \n \"fileExtensions\": { \n \".java\": \"java\" \n } \n } \n } \n} Key rules the skill enforces:
\n\n\n\ncommand must be on $PATH or an absolute pathargs typically includes \"--stdio\" for standard I/O transport (some servers like jdtls handle this internally)fileExtensions maps each extension (with leading dot) to a language identifierThe agent runs which <binary> (or where.exe on Windows) to confirm the server is accessible, then validates the config file is well-formed JSON.
The skill comes with a set of predefined language servers for several programming languages. If the coding agent faces one that it is not mapped out already, it will search for an appropriate server and walk you through manual configuration.
\n\n\n\nOnce an LSP server is configured, the CLI agent can:
\n\n\n\nnode_modulesThis means the agent spends less time on tool calls and produces more accurate code on the first pass. For you, that’s less time waiting while the agent decompiles a JAR file or greps through node_modules to answer a question your IDE already knows, and fewer wrong turns built on a misread signature. The agent reasons about your code with the same structured understanding you get from go-to-definition in your editor, so you can hand it bigger, gnarlier tasks and trust the result.
\n\n\n\n~/.copilot/skills/ by running:unzip lsp-setup.zip -d ~/.copilot/skills//exit first. Then relaunch copilot so it picks up the new skill./exit, then relaunch), run /lsp to check the server status, and try go-to-definition on a symbol from one of your dependencies.The skill is part of the Awesome Copilot project. It’s open source, so contributions and feedback are welcome!
\n\nThe post Give GitHub Copilot CLI real code intelligence with language servers appeared first on The GitHub Blog.
\n"}]}