If you’ve used slash commands in the GitHub Copilot CLI, you already know how powerful a quick / can be. In the GitHub Copilot app, slash commands take that idea further, giving you shortcuts for managing sessions, navigating projects, and customizing your Copilot workflow. What are slash commands? Slash commands are text shortcuts you type directly into the GitHub Copilot app’s chat composer. Start by typing / and an autocomplete menu appears, showing the commands available in your current context. It’s a small character with a lot of potential, opening the door to shortcuts that help you work with Copilot in new ways. If you’re coming from the CLI, here’s the key difference: CLI slash commands are designed around a terminal-first workflow. Things like adding directories, setting your working directory, and managing terminal access happen through commands. This makes sense, because the CLI lives inside your terminal where there’s no visual interface. 💡 Tip: If you’ve used slash commands in the Copilot CLI, you’ll notice some familiar faces. Commands like /clear and /model work in both places. But the GitHub Copilot app-specific commands are tailored for the multi-session workflow that the desktop app provides. The app, on the other hand, provides a visual interface for managing context. File access commands like /add-dir or /cwd aren’t needed since the app manages project context automatically. App slash commands are more about workflows. You can navigate between sessions, manage projects, and control how the agent works. Why use slash commands? Slash commands may look like simple shortcuts, but they can change how you interact with Copilot. They help you move faster, stay focused, and quickly access the workflows you need. Instead of digging through options or breaking your focus to find the right tool, you can type a command and keep moving. A single / opens up the list of slash commands that can help you move faster, explore new ideas, and get the most out of the app. Let’s take a look at some of the slash commands available in the GitHub Copilot app and how they can fit into your everyday workflows. Before you write code, make a /plan Good code starts with a good plan. /plan helps you break down a task before you start writing code, think through your approach, identify potential challenges, and decide what needs to happen next. It also switches your session into Plan mode, which you can also select from the Mode dropdown in the chat composer. Plan a new feature. Break down new feature ideas before jumping into implementation. Have Copilot identify files, components, and dependencies so you have a clearer path forward. /plan I need to add two-factor authentication to our application. Help me break down the work involved, identify what files need to change, and outline an implementation approach. Prepare for a large refactor. Map out complex changes before touching your code. Uncover potential risks and develop an incremental approach for making large changes safely. /plan We want to refactor our notification system code to make it easier to support new channels like push notifications. Help me understand the changes needed and create an incremental migration plan. Triage and fix bugs. If you know something is wrong but aren’t sure where to start, /plan can help you explore possible causes and outline the steps needed to diagnose and resolve the problem. /plan Users are reporting that our checkout flow randomly fails after payment processing. Help me investigate possible causes and create a plan to diagnose and fix the issue. Let Copilot play devil’s advocate with /spar Sometimes the best way to validate an idea is to challenge it. /spar is like that one teammate who raises their hand and asks, “Have we thought about what happens when this goes wrong?” It helps you pressure-test your approach by having Copilot question your assumptions and point out potential risks or tradeoffs before you commit to a solution. Here are a few ways you can use it: Validate an architecture choice. Pitch your plan to use Redis for caching and have Copilot question your invalidation strategy, scalability, or whether another approach better fits your workload. /spar I’m planning to use Redis as a caching layer for our product API. Challenge my approach and point out any scalability or consistency concerns I may have missed. Compare implementation options. Ask Copilot to debate the pros and cons of REST versus GraphQL, or synchronous versus asynchronous processing, based on your application’s requirements. /spar Help me decide between REST and GraphQL for a customer-facing API. Ask questions, challenge my assumptions, and recommend which approach fits best for an app with mobile clients. Review a migration plan. Walk through a database migration or infrastructure change and have Copilot identify edge cases, risks, or rollout concerns before you begin. /spar I’m migrating our database to a new managed service with minimal downtime. Poke holes in my migration plan and identify any risks or edge cases I should account for. Challenge a performance optimization. Share an optimization you’re considering and ask Copilot to point out hidden bottlenecks, unintended side effects, or simpler alternatives. /spar I’m planning to lazy load most of the components on my site to improve initial load time. Critique my approach and tell me where it could hurt user experience or introduce unnecessary complexity. /autopilot take the wheel Once you have a /plan, the next step is turning that idea into working code. /autopilot helps you work through implementation, make changes, and iterate as needed. Instead of managing each individual step, give Copilot a goal and let it work through the steps needed to complete the task. It also switches your session into Autopilot mode, which you can also select from the Mode dropdown in the chat composer. Implement a new feature. Hand off a task and let Copilot work through the implementation steps. /autopilot Add support for exporting user reports as CSV files. Identify the files that need changes, implement the feature, and update any relevant tests.

The same question keeps coming up in maintainer conversations: what do you do when the pull request queue fills with work written by agents? It’s something Nicholas Tindle, founding AI engineer at AutoGPT, also deals with every day. I spoke with him in May for Maintainer Month. At the time of the interview, AutoGPT had over 180,000 stars and around 150 open pull requests. A big chunk of those pull requests were written by agents, including Copilot, OpenClaw, and AutoGPT’s own internal tooling, among others. Most maintainers I talk to have the same reaction: close the door. Turn off pull requests. Don’t tax the team with reviewing slop. Nicholas saw an upside: It’s basically somebody else paying for your compute. Nicholas Tindle, founding AI engineer at AutoGPT The way he sees it, if a contributor wants to spend their tokens improving your project, let them. Just make it so the only way through the door is the way that works for you. Your docs aren’t the problem. Discovery is. AutoGPT tried the obvious thing first. Better contributor guidelines. Better docs. A whole wiki dedicated to working with the repo. None of it moved the needle. It turns out the tools aren’t going to go read your docs unless they’re told to. That’s the part a lot of us get wrong. We treat documentation like the agent will go find it. It won’t. Agents read what’s in front of them, at the level of the directory they’re working in. So AutoGPT started putting instructions where agents look. First CLAUDE.md files, because Claude was generating pull requests without enough repository-specific context. The commit trailer made each one easy to spot, because they announced themselves in the commit trailer. Then they hit the next wall: Copilot and Codex ignore Claude files, because they’re not Claude. So they centralized the standard AGENTS.md and pointed Claude files at it. Here’s the nuance I found most useful. AGENTS.md is scoped to a directory. A skill can be discovered outside that directory. (If you haven’t shipped one: a skill is an instruction file with a description that tells the agent when to load it. The agent scans descriptions up front and pulls in the full instructions when the task matches.) AutoGPT’s AGENTS.md sits beside the code it governs. That placement matters as much as the instructions themselves. If you’re writing backend tests and you think about doing front-end stuff, a skill may load dynamically. It’s not going to know what directory to go look in for an AGENTS.md file, but the skill can tell it that. Their front-end engineer got tired of the same class of broken pull request, so they wrote a guide, and shipped it as a skill in the repo. The description contained trigger phrasing: write a Storybook test if your component lives in these folders. Now every harness that touches the repo discovers it automatically. The backend enforces its own version of the rule the same way: hit 80% coverage or don’t open the pull request. Gates that actually work These are the gates you can adapt for your project. Enforce the pull request template, loudly. AutoGPT tells agents that pull requests not matching the template get closed automatically with zero hesitation. They built the tooling to actually do it, then found they didn’t need to run it. At AutoGPT, the rule changed agent behavior before the automation ever ran. The agents followed the template. Human contributors sometimes needed more room, which Nicholas treats as a feature: If you don’t follow the template, I know you’re probably a person, and I’m going to be kinder. The test plan trick. The template requires a test plan, and its wording casually mentions testing the pull request. That phrase triggers a skill called test PR, which installs agent browser (with permission), spins up the app, and executes the change. The agent set out to fill in a checkbox and ended up running the code. They almost never get pull requests that don’t work anymore. What they get now is pull requests that work but don’t fit the roadmap, which is a much better problem to have. Make CI a wall, not a suggestion. Codecov coverage thresholds are required checks. The agent opens the pull request, checks back a few minutes later, sees it can’t merge, loads the testing skill, and writes the tests. Nobody had to ask. Use the CLA as a human detector. AutoGPT is dual licensed, but Nicholas argues every project should do this, MIT included. Signing requires a browser and a GitHub OAuth flow on a separate domain. Agents are bad at that today, and for good reason: most maintainers do not want an agent logged into GitHub in a browser with broad account access. If your CLA is not signed after a week, we close the pull request with a comment that says sign the CLA, reopen when you’re done. That gate works because it puts a human back in the loop. A CLA is one option. A code-of-conduct checkbox can do the same job. Require a commit SHA before resolving a review thread. Some agents mark every review thread as resolved without touching the code. AutoGPT’s fix is a pr-address skill in the repo that declares the only valid sequence: fix, commit, push, reply, then resolve. The reply has to link the fixing commit, with the full SHA pulled from git rev-parse HEAD after committing, so the agent can’t recycle an old one. The skill even names the anti-patterns: “Acknowledged” is not a fix, and neither is citing a commit that doesn’t touch the flagged line. The gate they turned off When a check fails, AutoGPT had an agent read the run and comment on what broke. Their first version wired Claude Code into GitHub Actions and authenticated it inside the workflow, which meant one more broad credential living in CI. Running Copilot in the workflow gets the same result without that. Nicholas is a fan: It’s unbelievable. I’m so

The GitHub Actions incident on Thursday, August 6, was unacceptable in both its impact and particularity of its duration. Availability continues to be our top priority across all of GitHub. However, with this incident, we have fallen short of our commitments to you. We know how heavily customers rely on actions, and a prolonged outage like this one has a real impact on your productivity and on your trust in us. We continue to work through a deeper root cause analysis (RCA) on the incident, as there were many aspects in play that we want to fully understand before calling the investigation complete. We’ll update the public summary when our investigation is complete, and we will include the complete details in our August availability post to be published in September. Aside from immediate repair items discovered through our investigation, we are accelerating our architectural roadmap in GitHub Actions, aligned to our ongoing efforts around isolation, resiliency, and scale. It’s worth noting that the GitHub Actions service at the core of the aforementioned incident is still fully running in our data centers, a contributing factor to the lack of capacity we experienced. While the majority of actions runs on Azure, we hadn’t yet prioritized migrating launch service, the component that bridges the monolith to actions, due to its generally asynchronous nature and ability to queue work in response to issues. Unfortunately, as outlined in the public summary, cascading failures led to an unacceptable delay in recovery. This is why we are accelerating our move of GitHub Actions to Azure, where we will have more headroom and capabilities to absorb spikes. On our broader efforts, last month, we shared how a deliberate pause and stronger stability controls changed the way we move production traffic into Azure. In July, those controls allowed us to resume that work with greater confidence while continuing to reduce shared dependencies across GitHub. The short version of July: GitHub is becoming less dependent on shared infrastructure and individual datacenter locations, giving us more capacity to absorb growth and making failures easier to isolate. This month, more than half of monolith read traffic ran in Azure Central US, authentication data began leaving our oldest shared database, and dedicated services removed substantial load from that shared path. GitHub can now serve a larger share of customer requests from independent Azure capacity, reducing reliance on any single datacenter while preserving performance. Monolith read traffic served from Azure Central US peaked at 52.75% on July 28—the first time we consistently remained above the halfway line. Git traffic in Azure reached 47%, up from 43% in June, and 29% of all repositories now have a second replica in Central US, making failover less disruptive when a region degrades. Just as important, the stability validation process introduced after May’s incident is now part of every major traffic expansion, helping us increase capacity without increasing customer risk. We also reduced shared failure points behind critical customer workflows. The first authentication tables moved from our oldest shared database to dedicated infrastructure, proving the migration pattern for the remaining work. Authentication and permission checks now place substantially less pressure on that shared path: at peak, the dedicated user service offloads more than one million queries per second, while 80% of a major authorization lookup has moved to the isolated service path. Repository content traffic now runs fully from Central US on dedicated infrastructure, and the dedicated pull request service, which already serves anonymous traffic, reached 99.87% parity with the monolith for authenticated reads as we progressively roll all traffic to it. Together, these changes make it less likely that pressure or failures in one part of GitHub will affect unrelated customer activity. GitHub can now absorb more workload growth before shared infrastructure becomes a source of degradation that affects customers. One production change cut total query time on the artifacts table in half, while caching in the Git authorization path reduced authorization service load by 18.2%, even as request volume grew. Search is also less exposed to the capacity constraints that contributed to earlier incidents: all production search workloads now serve from Central US with additional headroom during demand or infrastructure stress. We are also changing how we measure and operate reliability. In addition to infrastructure health, we are increasingly measuring the health of important customer workflows such as pull requests so teams can identify degradation earlier. We are continuing to replace high-risk manual production activity with automation, review controls, and operational safeguards, so customer experience is less dependent on perfect human execution. Crossing 50% is the midpoint, not the finish. The next phase is about building enough independent Azure capacity to serve all production traffic and, ultimately, withstand the loss of a region without failure. This quarter, we are targeting 70% of read traffic and 30% of write traffic in Central US while bringing every production service online there. Moving database primaries will unlock write traffic; a second Azure region will provide the foundation for regional resilience. We now have a line of sight to get dotcom production traffic out of our datacenters by the end of CY2026. The eight incident write-ups that follow are the other half of this picture—what the system did well, what it did not, and what we have already changed as a result. The principle continues to guide us: availability, then capacity, then features. July 8, 2026 (lasting 7 hours and 4 minutes) On July 8, 2026, between 15:07 and 22:13 UTC, multiple GitHub services—including the Web UI, REST API, GraphQL API, Actions, Packages, Copilot, and Git operations—were unavailable across data-resident Enterprise Cloud environments and returned 5xx errors. Affected users experienced page-load and login failures, failed API requests, queued or rejected Actions workflow runs, and unavailable package registry endpoints. During the peak hour, approximately 84% of active tenants across the affected production environments had a majority of their requests fail, and the peak 5xx error rate reached approximately 96% in the most affected environment. Our automated monitoring detected elevated 5xx

Opening a new AI tool can feel a little like staring at a blank page. You know you want help with something, but figuring out exactly what to ask can be its own task. The good news is that you don’t need to write the perfect prompt to get started. A prompt is simply a description of what you want to accomplish. Start with what you know, give Copilot some context, and refine the request as you go. Let’s walk through what it looks like to start your first task in the GitHub Copilot app. Start with the right context Before you can ask Copilot to make a change, it needs something to work on. Agent sessions can be connected to a GitHub repository or a folder on your local machine, giving Copilot access to the code and files it needs for the task. From the GitHub Copilot app home screen, you can select a project you’ve worked with before or add a new one. If you’re working on code that’s only on your computer, you can add a local folder instead. Either way, connecting a project gives the session the context it needs to work with your codebase. Once your project is selected, you’re ready to write your first prompt. Describe what you want in plain English You don’t need to learn a special syntax or figure out the perfect way to phrase your request. Start by describing the change you want to make. For example: Add a most-funded sort option to the games list. That’s enough to get started. Copilot can examine the project, find the relevant parts of the codebase, and work on the requested change. If the first attempt isn’t quite what you had in mind, you can provide additional details or ask for changes. Prompting is an iterative process, so you don’t have to anticipate every detail before you begin. The best prompt is often the one that gets you moving. Choose the right model when you need it The GitHub Copilot app also lets you choose which AI model handles your task. Different models have different strengths, and some are better suited to complex reasoning while others can handle simpler tasks more quickly. If you’re just getting started, the default model is a good place to begin. You don’t need to understand every difference between the available models before you can use the app. As you work, you can switch models when a task requires more complex reasoning or when the first approach isn’t giving you the results you need. Think of the model selector as another tool you can reach for when the task calls for it, rather than something you need to configure before every session. Use whatever input feels natural Typing isn’t the only way to write a prompt. The GitHub Copilot app includes built-in voice input, which can be useful when you’re thinking through a problem out loud or have a longer request to describe. Your speech is converted into text in the prompt box, where you can review and edit it before sending it. That means you can think out loud without immediately committing to the first version of your request. Sometimes it’s easier to explain what you want than to type it out. Voice input gives you another way to get that idea into the session. Customize how the work runs You can also change how your session handles the work. From the session title, you can select a different agent or enable remote control for the session. Different agents can be configured for different types of work, so you can choose the one that best fits the task you’re working on. Remote sessions give you another kind of flexibility. Instead of running the work only on your local machine, you can access the same session from the web. You can start a task, close your laptop, and return to the session later from another device without losing your place. These options aren’t things you need to configure before your first prompt. They’re there when you need more control over how a task is handled. Start small and iterate Your first prompt doesn’t need to be perfect. Start with a small change you’d like to make in a project you already know, describe what you want in plain language, and see what happens. From there, you can refine the request, try a different model, or adjust how the session runs. The more you use the app, the more natural these choices become. The important part is getting started. Pick a project, give Copilot a task, and see where it takes you. Get started with the GitHub Copilot app > The post GitHub Copilot app for Beginners: Write your first prompt appeared first on The GitHub Blog. ​ AI & ML, GitHub Copilot, GitHub Copilot app, GitHub Copilot app for Beginners The GitHub Blog

How many tabs do you have open alongside your pull request? Imagine picking up a new issue in your product’s free-trial onboarding flow: make the “invite your teammates” step optional. Support keeps flagging the step as a friction point as signups increase. Quick win, right? From scoping to deployment, you need answers to these four questions: Is this even the right change? Are the dependencies I’m touching clean? How do I roll it out safely? Is it safe to deploy right now? Each answer lives in a different tool, so working through the pull request means carrying the same context across four places. GitHub agent apps bring the tools you need to answer those questions to where you’re already working, powered by the same platform and harness as our own Copilot cloud agent. The illustrative walkthrough below shows how you can use services you already depend on, such as Amplitude, Endor Labs, LaunchDarkly, and PagerDuty to answer these questions and complete this request, without ever leaving GitHub. 1. Before you build it Support says the “invite your teammates” step is annoying for customers who are onboarding with your product, but they haven’t given an indication of who has complained or whether those complaints lead to churn. You’d be right to be skeptical. So instead of opening Amplitude and building a query to confirm your hunch, you ask the Amplitude agent right from the Agents tab: @amplitude[agent] is completing the team invite step correlated with success later in the funnel? Break it down by segments we’re measuring. The split comes back clear: team users who finish the step are more likely to retain later, while solo users don’t have that correlation. A rescope is now justified: defer the step for solo signups and keep it for teams. Access to product insights is now within GitHub, enabling course correction before any code is written. 2. As you build it Copilot opens a draft pull request for the change. The implementation also updates dependencies used by the onboarding flow. Instead of waiting for a CI scan to fail later, you ask the Endor Labs agent in a comment: @endor-labs-github-agenthq[agent] is there anything I need to watch out for in the dependencies being touched by this pull request? The agent identifies the changed dependencies, checks them for known vulnerabilities and broader package risk, then reports back in the pull request. This time, everything looks clean. Nothing to remediate. Dependency review becomes a proactive check while the change is still in front of you. Much better than remediating a CI scan after it fails. 3. Rolling it out The previous finding now gets carried through to implementation: solo signups get the optional path, while teams keep the existing one. Because these segments are set at signup, a feature flag can target them directly. Ask the LaunchDarkly agent to set it up for you, the same way you’d ask a team member: @launchdarkly-agent[agent] please create a feature flag for this pull request and wire it into the code. – key: defer-team-invite – type: boolean – default: false – target: solo-intent signups – rollout: internal > 5% > 25% > 100% The agent creates the flag in LaunchDarkly and adds the code implementation as a commit you review. If the target environment requires approval, it creates an approval request instead of applying the targeting change directly. A human still decides whether the rollout moves forward. Flag setup goes from a second tool, a manual code handoff, and Slack coordination to one pull request comment and a commit you review. 4. Before you ship Review tells you the code is correct, but whether the service is in a good state for a deployment is a different question. Before merging, you ask the PagerDuty agent: @pagerduty-agent-app[agent] assess the deployment risk for this pull request against the onboarding service. Check active incidents and recent incident history, then recommend whether to proceed. The agent maps the repository to its PagerDuty service, checks for active incidents, reviews the previous 90 days, and compares the files in the pull request with areas involved in past incidents. This time, the risk is low. There are no active incidents and no meaningful correlation with the current changes. The recommendation is to proceed. Nothing dramatic happens, but that’s the point. Checking deploy risk becomes a routine step for your pull requests instead of something you do only when a release already feels dangerous. What changes You still use Amplitude, LaunchDarkly, Endor Labs, and PagerDuty. But now, you no longer need to carry the context between them, and they’ll all work directly in your GitHub workflows. As work moves from idea to production, developers can bring each service into GitHub when its context or capabilities matter. With agent apps, GitHub becomes the place where developers and agents coordinate what happens next, without developers switching contexts. Try it Agent apps are available from the GitHub Marketplace. Install one, enable it for your organization, and take it for a spin: Assign it to an issue to kick off a task. @mention it in a pull request comment for analysis or action. Select it from the Agents tab in your repository. Your tools are still your tools. Now, they show up where you are already working: on GitHub. Explore the other inaugural agent apps and start bringing your stack directly into your workflow: Packfiles’s agent reads your backlog and builds a migration strategy. reads your backlog and builds a migration strategy. Miro‘s agent connects visual collaboration with code workflows. Bright Security‘s agent autonomously handles end-to-end dynamic security testing inside GitHub. SonarQube‘s agent brings analysis, quality gates, and remediation into GitHub agent sessions. Octopus Deploy‘s agent can identify, diagnose, and resolve deployment failures. Discover agent apps in the GitHub Marketplace > The post How to bring your software delivery workflow into GitHub with agent apps appeared first on The GitHub Blog. ​ AI & ML, GitHub Copilot, Agent Apps, GitHub Marketplace The GitHub Blog

The GitHub Universe 2026 schedule just dropped, and it’s full of exciting sessions, demos, and panels covering the potential of AI-powered development. If you haven’t registered yet, here’s what you need to know. This two-day event brings together some of the greatest minds in tech, with experts from companies like AMD, Figma, NVIDIA, Coinbase, Anthropic, and OpenAI leading our sessions. They’re covering everything from delegating real work to Copilot and measuring AI at enterprise scale to fine-grained security for MCP servers. You’ll also have the chance to chat with the GitHub team one-on-one, get your questions answered, and even pick up some career advice. Did we mention the Ship & Tell sessions where teams show what they’ve built, and partner booths where you can demo the latest tech? When: October 28-29 Where: Fort Mason Center, San Francisco, CA One thing first: register before August 19 and save $300 with Early Bird passes. Prices go up after that, so if Universe is already on your list, now’s the moment. The best part? You can stack savings with our group discounts. Register now Here’s a sneak peek of some of the sessions we have planned. You can jump to the full agenda right here. Be sure to mark your favorites to build your own personal calendar. Find your flow Some of the best moments at Universe happen heads-down: working through a real problem, configuring something on your own machine, and walking out with a project you can actually use. This year’s catalog leans into that with learnings you can take straight back to your repositories. A few sessions to start with: Stop prompting, start delegating: Configure Copilot to own the workKen Muse, GitHub; Mickey Gousset, GitHubLearn how the right Copilot configuration turns AI into something you can trust with complex tasks. Layer Copilot’s full stack onto a TypeScript app, and you’ll leave with a working project and a clear sense of which capability fits which task, so you can delegate more and prompt less. Inside GitHub Copilot’s coding harness: Optimizing across every modelJulia Kasper, MicrosoftShipping a coding agent that works across OpenAI, Claude, Gemini, and whatever drops next week takes a harness. See the evaluation framework the GitHub Copilot team uses to test and optimize its agent across every model: reproducible benchmarks, thousands of autonomous coding tasks, and LLM-graded assertions that catch regressions before users do. Stop waiting on your own pull requests: GitHub stacked pull requests in practiceSameen Karim, GitHubStacked pull requests let you split changes into smaller, dependent pull requests that move through review efficiently while preserving the full picture. This demo builds a stack with the GitHub CLI, reviews it on github.com, and merges each pull request as it’s ready—so you leave with a workflow you can use tomorrow. Find your people Hallway conversations, a question that reframes your whole approach, the engineer who already solved the thing you’re stuck on. This year’s agenda is filled with sessions for exactly that. Plus, hallway tracks, partner booths, and Ship & Tell sessions where teams show what they’ve actually built. A few sessions worth your time: Building AI fluency at UPSJared Hatfield, UPSGetting developers to try GitHub Copilot is simple; getting them fluent with it—using agents to plan, write, and ship real work—is the harder challenge. See how UPS moves developers from awareness to fluency, why motivation and measurement matter as much as the tooling, and where to focus first at enterprise scale. Code is the easy part: Building Home Assistant in the openFranck Nijhof, Open Home Foundation“Building in the open” usually means one thing: code on GitHub. But the hard work starts long before code—ideas, UX, design, architecture, the roadmap itself. At Home Assistant, every step happens in the open across 20,000 contributors and a dozen GitHub organizations. See how the Open Home Foundation runs its whole roadmap with issues, projects, and discussions, including the harder parts, like being wrong in public, fixing it in public, and proving you don’t have to be technical to contribute. I made my Octolamp think with GitHub Copilot CLI hooksBeatris Mendez Gandica, Nuevo FoundationWhat if your desk lamp could show when GitHub Copilot CLI is thinking? Using the native hooks system, Beatris Mendez Gandica made hers breathe green when the agent works, go white when idle, and blink red on errors. No prompting tricks, just system-level lifecycle events driving a physical light via the WLED API. In this session, you’ll see how Copilot CLI hooks work under the hood, and leave knowing how to write your own for any use case. Build what’s next Want to know what’s on the horizon? These are the talks that pull back the curtain on where AI-assisted development is heading. The view from the labs: What’s next for AI-assisted developmentCara Phillips, Anthropic; Rohan Varma, OpenAI; Kate Catlin, GitHubThe people building frontier AI models see where capabilities are heading before anyone else. This interactive panel brings leaders from Anthropic, OpenAI, and other labs that power GitHub Copilot together for a candid look at the next two years of AI-assisted development, and what it means for you. Open pull requests, don’t merge them: Fine-grained authorization for hosted MCP serversNick Taylor, PomeriumHosted MCP servers hand every agent everything its human can do: OAuth in, broad scope out, one global toggle. But what if an agent should open a pull request and leave the merge to a reviewer? See a pattern that works today: an identity-aware proxy that adds per-identity authorization in front of any hosted MCP server with no changes upstream, demonstrated live with Copilot doing exactly that. From writing code to managing agents: Scaling 50+ services at GitHubAnjuan Simmons, GitHubGitHub’s Lifecycle team traded hand-coding fixes across 50+ services for an agentic pipeline where AI agents classify issues, research codebases, write implementation plans, and open draft pull requests automatically. Get the real lessons and numbers from running it at GitHub’s own scale: how it was built with GitHub Actions and Copilot, where automation pays off most, and why engineers still

AI coding tools often begin with a chat window. While that works for quick questions or generating code, real software development rarely happens in a straight line. One minute you’re fixing a bug, the next you’re reviewing a pull request, digging into an unfamiliar part of the codebase, or exploring a new idea. The GitHub Copilot app is designed for that kind of workflow. Instead of treating AI as a single conversation, it gives you a workspace where you can manage multiple agent sessions, switch between tasks without losing momentum, and work with AI agents across the different parts of your workflow. Your work starts with a project Agent sessions are connected to a project, giving each session the repository context needed for a specific task. From the GitHub Copilot app home screen, you can choose a project you’ve worked with before or add a new one from GitHub or your local machine. Once a project is selected, you can start a session with the codebase, files, and tools needed to begin working on a task. For example, you might want to add a breadcrumb navigation component to an existing application. Instead of manually searching through files to find the right place to make the change, you can describe the update you want to make. The session can examine the project, identify relevant files, make the changes, and run tests to help validate the work. By starting each session with the project already connected, you can spend more time working and less time preparing your environment. Keep multiple threads moving Once you’ve selected a project and started an agent session, you can create additional sessions for other questions, ideas, or tasks without interrupting your existing work. Quick Chat lets you start a new conversation from the Copilot app home screen. Each conversation can focus on a different area of work, giving you a dedicated space to explore ideas, ask questions, or work through changes. For example, you can open a Quick Chat session to ask Copilot about Copilot, such as how worktrees function in the app, while another agent session continues working on a project update. You can also use Quick Chat to investigate how your codebase works, explore potential approaches, or gather context before deciding how to move forward. When you return to your original session, you can pick up where you left off, review the changes, and make any updates needed to move the task forward. Multiple sessions let you follow different threads of work without losing track of where each task stands. Make your work interactive with canvas When working on a UI change, seeing the result can be just as important as reviewing the code behind it. The GitHub Copilot app lets you open a browser canvas directly within your workflow, giving you a way to preview your application and make changes based on what you see. A canvas is a shared, interactive space built around work artifacts, such as a plan, a kanban board, a checklist, or a running application. It provides a visual representation of your work alongside your conversation, so you can move beyond a text-based view of the task. Rather than opening a new terminal and launching a separate browser, you can create a browser canvas in the GitHub Copilot app using the /create-canvas slash command. For example, after asking Copilot to update a UI component, you can create a canvas with: /create-canvas Open this app in a browser canvas This opens your application in a canvas where you can preview the result. If something needs adjusting, you can Enable Canvas Dev Mode and use Pick & Polish to select elements directly in the canvas and use them as context for your next request. You can point to a specific part of the page, request an update, and continue refining the result. Keep work moving with Agent Merge Once your changes are ready, the next step is creating a pull request and moving through the standard CI and review process. Agent Merge helps extend that workflow beyond the initial code change by monitoring the pull request and assisting with tasks that come up during review. To start an Agent Merge workflow, open the pull request options in the Copilot app and select Agent Merge. From there, you can choose which actions Agent Merge can take, such as addressing review feedback, helping resolve CI failures, or handling merge conflicts. After Agent Merge is enabled, it monitors the pull request as it moves through the review and CI process. If issues come up, it can help address requested changes and prepare the pull request for merge. Once the required checks have passed, you can choose to merge the pull request. Start exploring the Copilot app The Copilot app brings together the different parts of your development workflow in one place. Start with a project. From there, you can create separate sessions for different threads of work, create a canvas to visualize and refine your work, and keep changes moving through the pull request process with Agent Merge. There’s more to explore, including additional ways to customize and extend your workflow. The best way to learn the GitHub Copilot app is to try it yourself. Have a task that’s been sitting in your backlog? Try it with the GitHub Copilot app and see how you can explore, build, and ship with AI agents. The post GitHub Copilot app for Beginners: Getting started appeared first on The GitHub Blog. ​ AI & ML, GitHub Copilot, GitHub Copilot app, GitHub Copilot app for Beginners The GitHub Blog

In September 2025, an attacker phished the credentials of a single npm maintainer and published booby-trapped versions of chalk, debug, and around a dozen other packages that are together downloaded more than 2 billion times a week. The code rewrote cryptocurrency wallet addresses inside any browser app that loaded it. The poisoned versions were live for roughly two hours before the community caught them and npm pulled them. Two hours is a fast response. However, it is also more than enough time for an automated update tool to see the new version, open a pull request, and put it in front of your team, because version update tooling is built to grab the newest release the moment it lands. That pattern sits behind a growing share of supply chain attacks. The malicious code rides in on a brand-new release, is published to a public registry, and gets pulled into build pipelines within minutes, before a human or a scanner has even looked at it. A cooldown changes that math. Waiting a few days before adopting a new release gives maintainers, security researchers, and automated scanners time to spot a malicious version and get it pulled before it ever reaches your pull requests. For non-security version bumps, Dependabot now waits at least three days after a release is published before opening a pull request. The cooldown configuration option in the dependabot.yml still controls the behavior, though, so you can choose a different cooldown parameter that fits your project. Two kinds of Dependabot updates Dependabot is GitHub’s built-in tool for keeping dependencies secure and up-to-date, and it does two distinct jobs: Security updates respond to a known vulnerability: when an advisory is published for a package you use, Dependabot issues an alert and opens a pull request to move you to the patched version.  Version updates keep your dependencies current as new releases come out, regardless of your current version’s health.  The new three-day cooldown default applies only to version updates. Security updates still open right away, since a delay there would hold back a fix for a flaw that is already public. Everything in this article is about version updates, where the goal is staying current, and the risk is adopting a release before it has been vetted.  Case studies and GitHub Advisory Database data When attackers compromise a popular package, the poisoned version tends to have a short lifespan. It gets published, spreads through whatever installs it, and gets caught, usually within hours. The previous example was live for only two hours. Other widely used packages have followed the same arc, with compromised builds of Solana web3.js, Axios, and ua-parser-js each caught within a few hours of publication. More generally, GitHub sees this pattern directly through the GitHub Advisory Database, which catalogs open source security advisories across ecosystems. In the year ending May 2026, the database published more than 6,500 npm malware advisories, up from roughly 6,200 the year before, which adds up to approximately 18 newly cataloged malicious npm packages every day. A cooldown keeps you out of that opening window and lets a release accumulate some scrutiny before it reaches you. Why three days Published malware targeting popular packages tends to get caught fast. A review of 21 widely reported supply chain incidents between 2018 and 2026 found the same pattern: malicious versions of axios, Solana web3.js, ua-parser-js, and Ledger Connect Kit were each pulled within hours of publication, and a cooldown could have filtered out the majority of these short-lived publishes before anyone installed them. Three days as the default balances two goals: it pushes you past the window where most of these attacks live, and it doesn’t hold your dependencies back longer than necessary. Other community members have also landed on a three-day cooldown (though some go even longer), so this default behavior keeps Dependabot consistent as developers move between tools. You can always set a longer or shorter window with Dependabot’s cooldown configuration option. Defense in depth A cooldown is built for a specific pattern: a malicious version that ships, spreads, and gets caught quickly. It does little against attacks that play a longer game, including backdoors planted in releases and left dormant, maintainer sabotage, or a compromised build system. The point of the default is to remove a common and time-sensitive path, not to stand in for the rest of your defenses. Because a cooldown only addresses the fast-moving case, it should be one layer among several. Some additional steps to take include pinning dependencies with lockfiles, disabling install scripts in CI where you can, scoping the tokens in your build pipelines, and reviewing updates before they merge. If you’d like to customize your delay for highly trusted internal packages versus public registries, check out the documentation on configuring Dependabot. Or see the Dependabot configuration options reference for the full set of cooldown parameters. Where we go from here This is one step among several we are taking to harden the software supply chain for everyone who builds on GitHub. It’s on by default, so you don’t have to change anything to activate it. You can also tune it to fit your workflow. Tell us how it performs in the Dependabot community discussions. The post The case for a cooldown: Why Dependabot now waits before issuing version updates appeared first on The GitHub Blog. ​ Security, Supply chain security, Dependabot, supply chain security The GitHub Blog

I keep seeing this question: “Why would I pay for GitHub Copilot when I can call the same models through an API?” It’s a fair question. The answer depends on what work you need to own. Are you building a product feature with your own prompts, retrieval, routing, logs, security model, and billing controls? Or are you trying to get from a GitHub Issue to a reviewed pull request with the editor, repository, terminal, and organization policies already connected? Cost is part of that equation. Copilot plans include a monthly allocation of GitHub AI Credits. Metered usage is calculated from input, output, and cached tokens at the listed rate for the selected model. Raw API access and Copilot address different layers of that system. The right choice follows the work you need to own. Copilot is development tooling around the model Now take a common maintenance task: a developer starts from a GitHub Issue, inspects the repository, changes the affected files, runs the test suite in the terminal, and opens a pull request for review. The model call is one step in that workflow. The surrounding system needs the issue, the diff, repository instructions, permitted commands, and the organization’s policies. GitHub Copilot connects those surfaces across the editor, repository, pull request, issue, terminal, and organization controls. That is what the plan covers alongside model access. The billing change makes the split easier to see: code completions and Next Edit Suggestions remain included in paid plans, while AI Credits apply to more resource-intensive chat and agentic work. Cost per task therefore depends on more than the listed token rate. Context selection, tool use, retries, and the path from an issue to a reviewed pull request all affect the number of tokens spent and whether the work finishes. The same billing model gives buyers visibility. Organization plans “pool” AI Credits across the organization, and admins can set budgets and track usage in the billing dashboard. Adoption stays measurable instead of scattering across individual API keys and untracked scripts. The harness has measurable impact GitHub’s evaluation held the model, benchmark task, context window, reasoning effort, tool selection, and MCP servers constant while comparing Copilot CLI with model-vendor harnesses. Across SWE-bench Verified, SWE-bench Pro, SkillsBench, TerminalBench, and Win-Hill, Copilot reached task-resolution parity while using fewer tokens in most configurations. For TerminalBench 2.0, each agent-model configuration ran at least five times to measure cost and completion variance. Read the full agentic-harness evaluation across models and tasks.  Raw API access is for systems you own Direct API access is the right foundation when you are building a product feature, an internal agent platform, an evaluation harness, or an automation pipeline. You control the prompts, retrieval, routing, retries, logs, security model, and billing. Consider an internal agent that reads a tagged issue, retrieves company documentation, creates a change request in a separate system, and writes a complete audit record. That workflow needs its own data boundaries, event triggers, and approval points. An API gives the team the primitives to build those requirements into the product. The engineering work is real. A production system needs to decide which repository files to retrieve, how to preserve instructions, when to retry a failed tool call, where to store traces, and which credentials an agent can use. Those are system design decisions made by developers. A model endpoint does not make them for you. Agent SDKs sit between these layers. Handling orchestration, tool use, sessions and streaming, with some tradeoffs: some are tied to a single provider’s API while others work across providers. GitHub ships this layer. The Copilot SDK exposes the same agent’s runtime that powers the Copilot CLI, so you can embed a benchmarked, production tested harness instead of building one. Run it with your Copilot subscription or your own provider key. BYOK keeps the workflow and changes the bill Bring Your Own Key for Copilot, currently in public preview, lets developers make supported provider models available in Copilot Chat, Copilot CLI, and VS Code. Supported providers include Anthropic, AWS Bedrock, Google AI Studio, Microsoft Foundry, OpenAI, OpenAI-compatible providers, and xAI. BYOK models run through the same harness and the same integrations GitHub builds and maintains. Your provider takes over the token bill. GitHub still develops the tooling. Model access is a policy decision either way. Copilot supports more than 20 models, and enterprise and organization admins choose which ones are enabled for their teams, whether GitHub-hosted or connected through BYOK. A team with an existing provider contract or committed cloud spend can keep that commercial relationship while developers use Copilot in their normal workflow. Copilot CLI also supports local and external BYOK models, including OpenAI-compatible endpoints, Azure OpenAI, Anthropic, and local Ollama models. Check the current documentation on using your own API keys with GitHub Copilot (enterprise) and using your own LLM models in Copilot CLI before making purchasing or architecture decisions because BYOK is still in public preview. Choose the layer you need Choose raw API access when you are building a system that requires custom behavior, integrations, and controls. Choose GitHub Copilot when the work is software development inside the tools and repositories where a team already writes, reviews, secures, and ships code. Shipping software is the work around the code: issues, pull requests, reviews, checks, actions, and security. GitHub is where teams do that work. Copilot helps them move through it faster. See what each Copilot plan includes and how AI Credits work. The post Copilot vs. raw API access: What are you actually paying for? appeared first on The GitHub Blog. ​ AI & ML, GitHub Copilot, AI Credits, API The GitHub Blog

If you maintain an active repository, you know the feeling. You open your notifications on a Monday morning and there they are: five, 10, sometimes a dozen Dependabot pull requests, each bumping a single dependency by a single patch version. Individually, every one of them is helpful. Collectively, they’re noise. And noise is how important updates get ignored. We looked at Microsoft’s GCToolkit, an open source Java library for analyzing garbage collection logs. As of July 2026, a git log of the repository showed that 92 of its 578 commits, roughly one in six, were Dependabot version bumps, with 61 in the previous 12 months alone, sometimes several in a single day. That’s a lot of review, merge, and CI cycles spent on routine maintenance. The good news: Dependabot already ships with the features to fix this. In a recent pull request, the project changed its dependabot.yml in three small but meaningful ways, turning a daily drip of single-dependency pull requests into a predictable, grouped, monthly batch per ecosystem. Here’s what changed, why it works, and how to apply the same pattern to your own repositories, following the GCToolkit example. The problem: Good defaults, wrong cadence Here’s what GCToolkit’s configuration looked like before: version: 2 updates: – package-ecosystem: github-actions directory: “/” schedule: interval: daily open-pull-requests-limit: 10 This is a common starting point, but the daily interval here was a deliberate choice, not a default: schedule.interval is required, and GitHub’s suggested starter template uses weekly. Two things make this configuration noisy: interval: daily tells Dependabot to check for updates every weekday (Monday through Friday). For a repository that references a handful of GitHub Actions, that can mean new pull requests landing on any weekday. No grouping means every dependency gets its own pull request. Ten available updates equals 10 pull requests, 10 CI runs, and 10 review notifications. The open-pull-requests-limit: 10 line is a symptom, not a cure: it caps the flood at 10 open pull requests, but it doesn’t stop the flood. The fix: Three changes that compound Here’s the configuration after the change: version: 2 updates: – package-ecosystem: “github-actions” directory: “/” schedule: interval: “monthly” groups: monthly-batch: patterns: – “*” – package-ecosystem: “maven” directory: “/” schedule: interval: “monthly” groups: monthly-batch: patterns: – “*” Three things are happening here, and they build on each other. 1. Group everything into a single pull request The groups block is the heart of this change: groups: monthly-batch: patterns: – “*” A Dependabot group bundles multiple dependency updates into one pull request. The name (monthly-batch) is yours to choose. It shows up in the pull request title and branch name. The patterns list decides which dependencies belong to the group, and “*” is a wildcard that matches all of them. So instead of 10 pull requests, you get one pull request titled something like “Bump the monthly-batch group with 10 updates.” One branch. One CI run. One review. If the whole batch is green, you merge once and you’re done. If something breaks, it’s contained in a single, reviewable place. For larger projects, you don’t have to lump everything together. You can define multiple named groups with more specific patterns. For example, you could keep all your testing libraries in one group and your production dependencies in another, so related updates travel together and unrelated ones stay separate. Grouping keeps getting more capable, too. In a February 2026 update, Dependabot gained the ability to group updates for the same dependency across multiple directories into a single pull request. That’s aimed squarely at monorepos: if one library is pinned in a dozen services, a single bump used to open a dozen near-identical pull requests, one per directory. Now you can point the directories key (note the plural) at a list of paths, or a glob like /apps/*, and let your group collapse all of them into one: – package-ecosystem: “npm” directories: – “/apps/*” schedule: interval: “monthly” groups: monthly-batch: group-by: dependency-name patterns:Expand comment – “*” That’s the same monthly-batch group as before, now spanning every service in the repository instead of a single directory. For the full set of options, see the Dependabot options reference. 2. Slow the cadence from daily to monthly schedule: interval: “monthly” Switching from daily to monthly changes the rhythm from “whenever anything changes” to “once, on a schedule you can plan around.” Combined with grouping, this is the real noise reduction: Dependabot now opens one batched pull request per ecosystem, per month, instead of a steady trickle all month long. Monthly is the right call for a mature library where dependencies are stable and updates are rarely urgent. If you want something in between, weekly is also available, and you can pin the exact day and time with schedule.day and schedule.time. 3. Cover every ecosystem you actually use The original config only requested version updates for github-actions. But GCToolkit is a Java project built with Maven, so its application dependencies weren’t receiving Dependabot version updates. The updated config adds a second updates entry: – package-ecosystem: “maven” directory: “/” This is an easy one to miss. Reducing noise is only half the win; the other half is making sure Dependabot is watching the dependencies that matter most. Each ecosystem gets its own schedule and its own group, so your Actions updates and your Maven updates arrive as two clean, separate batches. But what about security updates? This is the question every maintainer should ask before slowing anything down, and it’s where the design really shines: by default, the groups and schedule you set here shape your version updates, not your security fixes. Dependabot security updates are raised as soon as a vulnerability with a fix is disclosed, independent of your schedule and separate from your version-update groups. So a monthly batch cadence for routine bumps doesn’t delay a critical patch. (You can batch security fixes on purpose with a group scoped to applies-to: security-updates, but even then they’re triggered by disclosures, not by your version-update schedule.) One caveat: this safety net only

In the past year, there’s been a pattern of supply chain attacks that target weaknesses in package repositories and CI/CD systems to quickly spread malware to hundreds of open source projects. This malware seeks to exfiltrate credentials both to broadly spread the attack, as well as for later exploitation. We’ve written a few times about our plans for hardening the supply chain: Our plan for a more secure npm supply chain in September 2025, Strengthening supply chain security: Preparing for the next malware campaign in December 2025, and What’s coming to our GitHub Actions 2026 security roadmap in March 2026. In this post, we’re updating you on changes we’ve implemented that directly disrupt some of the most common and impactful supply chain attack techniques. Anatomy of supply chain attacks Supply chain attacks chain together several weaknesses, and there is no single security capability that can stop them. Addressing them takes a holistic approach, prioritizing the mitigations that break the most impactful links in the attack chain. Our teams have been studying these attacks to deploy several improvements that disrupt them and limit their impact. This is possible thanks to collaboration with the security research and developer communities. The attacks vary in how they spread across the software ecosystem. However, most of these attacks follow similar techniques to gain initial access to a project, escalate privileges, and distribute across users and software. Improvements made to npm and GitHub Actions in the past few months have been focused on cutting off specific, common techniques and providing ways for customers to identify and respond to these attacks. Initial compromise Attacks start by compromising a single project, often by directly compromising a maintainer’s account or by targeting the project’s actions workflows. npm adds preventive account protection for high-impact accounts (June 2026): Frequently, attacks start with a phishing campaign targeting maintainers. With this change, high-impact npm accounts are now put into a read-only mode for 72 hours when they change their email or use a 2FA recovery code. This delay allows maintainers time to respond and recover the account before their account can be used to start an attack. Safer pull_request_target defaults for GitHub Actions checkout (June 2026): A common vulnerability in a project’s CI/CD pipelines are “pwn requests,” where a workflow triggers on pull requests from forks and then executes user-submitted and untrusted code from that fork. We changed the default behavior of actions/checkout to prevent the checkout of untrusted code from forks in commonly exploited triggers unless you explicitly opt-out (after reviewing your risk). This change and its backport to older versions cut off one of the most common vulnerable code patterns leading to code execution in GitHub Actions CI/CD workflows and initial project compromise. Control who and what triggers GitHub Actions workflows (June 2026): Maybe you’d prefer to opt-out of these risky action triggers altogether or limit who can trigger them. This new control lets you set enterprise, organization, or repository level policies on who is allowed to trigger workflows and what trigger types are allowed. These workflow execution policies provide a governable and customizable layer of least-privilege around Action workflows that reduce the attack surface of your CI/CD infrastructure. Read-only Actions cache for untrusted triggers (June 2026): After an attacker has achieved code execution in an Actions workflow, they then look to escalate to more privileged workflows (and therefore credentials) through poisoning the cache entries shared across workflows. With this change, we restrict the ability for less trusted workflows to modify the cache shared with other workflows. This directly closes a common path attackers have used to turn a vulnerability with limited impact into one that compromises highly privileged credentials used by release and publishing workflows. Exfiltrate credentials Once an attacker has access to a single package, they then focus on detecting and exfiltrating credentials to gain further access and use in later exploitation across ecosystems. npm trusted publishing now supports CircleCI (April 2026): The number one thing you can do to disrupt these attacks is to remove long-lived credentials from your CI/CD pipeline. Trusted publishing is a great way to authorize publishes to your package repository without a long-lived credential. By adding CircleCI as a trusted publishing provider, we’ve made it possible for more people to remove the credentials these attacks attempt to exfiltrate. Actions network firewall (In technical preview): This technical preview logs all outbound network traffic from your Action workflow runs so you can detect unusual behavior like pulling down malicious code or exfiltrating credentials to a new domain. Future work will enable network egress restrictions and policies to block these attacks before they lead to further escalation and exfiltration. Propagating the attack With the credentials harvested from the previous step, attackers attempt to use those credentials to distribute their malware and compromise more projects and maintainers as quickly as possible. Staged publishing for npm (May 2026): With staged publishing, it’s not enough to have credentials to publish a new package on npm; those packages are staged until additional approval and 2FA authentication is provided in the npm cli or on npmjs.com. This opt-in security control allows maintainers to ensure that any version of their package published has gone through this additional authorization. By decoupling the credentials used in CI/CD pipelines and automation from those that can publish to the registry, the attack chain from a CI/CD pipeline to malware distribution is cut off. Upcoming breaking changes for npm v12 (June 2026): To spread their malware as quickly as possible, attackers use npm install-time scripts to exfiltrate credentials instead of waiting for code to be executed by the package at runtime. With npm v12, we are rolling out a breaking change that disables these install scripts by default. Since install scripts have legitimate use within the package installation processes that several popular packages rely on, you can reenable them by approving specific scripts. Additional vectors for install-time code execution have also been blocked by disabling dependencies via git or remote URLs by default. Dependabot version updates introduce

Suppose a user searches for café and your corpus contains CAFÉ, or they type straße and you’ve stored STRASSE. To make these count as matches, you need a canonical form that erases case distinctions, so that two strings which differ only in case compare equal. That form is case folding, and it shows up wherever text is matched rather than displayed: search engines, regex (?i) flags, case-insensitive usernames and hostnames. It’s a basic operation, but at GitHub we run it a lot. Blackbird, GitHub’s code search engine, indexes over 180 million repositories—more than 480TB of source code. Every byte is case-folded before we extract ngrams and build the index, and for every potential query result, another (implicit or explicit) case folding operation is needed to locate matches. At that scale, the speed of even a basic operation starts to matter. This post is about how we made it fast, and it starts somewhere counterintuitive: the biggest win in the ASCII fast path came from removing an optimization, not adding one. It turns out to be faster to sweep the whole buffer with no branches than to stop early at the first non-ASCII byte. We open-sourced the result as a Rust crate called casefold. Folding is not lowercasing It is tempting to reach for str::to_lowercase, but lowercasing and folding are different operations with different goals: Lowercasing is for display, and it’s locale- and context-sensitive: Greek final sigma lowercases to ς at the end of a word and σ elsewhere, and Turkish I lowercases differently than English I. Case folding is for comparison, and it’s deliberately context-free and locale-independent. The point is a relation that stays stable and symmetric, so that if A folds to match B, B folds to match A in any locale. The Unicode Character Database ships an explicit CaseFolding.txt for exactly that. The two operations diverge on real characters—ß, İ, final sigma—which is why lowercasing as a stand-in silently produces wrong matches. This crate implements only the simple (1-to-1) folds—statuses C and S in CaseFolding.txt—and not the multi-character “full” folds (ß → ss) or Turkic locale folds (the dotted İ). This isn’t an unusual choice: common tools and regex engines like ripgrep make the same restriction, and being consistent across tools is important. The counterintuitive core: Don’t stop early We deal mostly with source code, so the text we fold is overwhelmingly ASCII and making it run at memory speed is the single most important thing we can do. Everything else just has to keep the rare non-ASCII path from spoiling it. The fold of an ASCII letter is trivial—A..=Z map to a..=z, everything else is unchanged—so the ASCII pass is really just “sweep the buffer, lowercase in place.” Ask any LLM for it and you might get something like this: let bytes = s.as_bytes_mut(); for (i, b) in bytes.iter_mut().enumerate() { if *b >= 0x80 { break; // non-ASCII at index i: hand the rest to the Unicode path } if b.is_ascii_uppercase() { *b += 32; // ‘A’..=’Z’ → ‘a’..=’z’ } } It looks ideal: do the cheap byte work, and the instant you hit a non-ASCII byte, break and let the “real” Unicode path take over: “only do the cheap work until you have to.” On an Apple M4 this runs at about 3 GiB/s. That sounds fine in isolation, but it is more than 15× short of “optimal” because of the if branches. Let’s delete every branch, line by line: if b >= 0x80 { break } → don’t stop at all. ORevery byte into an accumulator and test it once, after the loop: high_bit_acc |= *b. Same information (was there any non-ASCII byte?), zero branches in the body. The A..=Z range test → make it arithmetic. b.wrapping_sub(b’A’) < 26 is true exactly for A..=Z (any other byte wraps to ≥ 26), yielding a 0/1 mask with no branch. The conditional write → fold the mask into the store.| (is_upper << 5)sets bit 5—turning an upper-case letter lower-case and being a no-op on everything else—the byte is always written, never branched on. What’s left has no branch in its body and no early exit: let mut high_bit_acc: u8 = 0; for b in &mut bytes { high_bit_acc |= *b; // detect any non-ASCII byte let is_upper = b.wrapping_sub(b’A’) < 26; // branchless A..=Z test *b |= u8::from(is_upper) << 5; // set bit 5 → lowercase, else no-op } if high_bit_acc & 0x80 == 0 { return bytes; // pure ASCII: already folded in place, no second buffer } A loop with no data-dependent control flow is trivially vectorizable: LLVM emits 16-byte-at-a-time NEON and the whole thing runs at > 45 GiB/s—essentially memory bandwidth. And we come out of the pass already knowing, from high_bit_acc, whether there’s any non-ASCII work left to do. How much did each step matter? Measuring the cumulative ladder on pure ASCII (Apple M4, 5.7 KB buffer): Version  Throughput  Vectorized?  naive (break + branch test)  3.1 GiB/s  no (0 vector instrs)  → branchless test/write, keep break  2.6 GiB/s  no (0 vector instrs)  → drop the early-exit break  7.6 GiB/s  partially (25 vector instrs)  → branchless test + write (the loop)  >45 GiB/s  fully (41 vector instrs)  The early-exit is what gates vectorization: keep the break but make the body perfectly branch-free and you still get zero vector instructions (~2.6 GiB/s); a data-dependent loop exit is enough on its own to keep the loop scalar. Only once the break is gone can the compiler vectorize. The final step—making the upper-case fold branchless—then turns a partially vectorized loop (which still compiles the conditional store to a compare-blend-masked-store, ~7.6 GiB/s) into the straight-line arithmetic that hits memory bandwidth. Note: Branchless is a pessimization in scalar code. Look again at the table: making the body branchless while keeping the break (2.6 GiB/s) is actually slower than the naive branchy loop (3.1 GiB/s). The asm explains why. The branchy version only stores a byte when it actually changes one; its conditional strbis skipped for every lowercase letter, digit and space (the vast majority of real