The GitHub Blog
type: channel
description: Updates, ideas, and inspiration from GitHub to help developers build and design software.
date: 2026-05-14T02:10:16Z
update period: hourly
update frequency: 1
update base: 2000-01-01T12:00+00:00
generator agent: https://wordpress.org/
items: Dungeons & Desktops: 10 roguelikes that never die (because their communities won’t let them)
items: GitHub Copilot individual plans: Introducing flex allotments in Pro and Pro+, and a new Max plan
items: Dungeons & Desktops: Building a procedurally generated roguelike with GitHub Copilot CLI
items: GitHub for Beginners: Getting started with OSS contributions
items: Why age assurance laws matter for developers
items: How researchers are using GitHub Innovation Graph data to reveal the “digital complexity” of nations
items: Improving token efficiency in GitHub Agentic Workflows
items: Agent pull requests are everywhere. Here’s how to review them.
items: Validating agentic behavior when “correct” isn’t deterministic
items: Welcome to Maintainer Month: Celebrating the people behind the code

Dungeons & Desktops: 10 roguelikes that never die (because their communities won’t let them)
type: item
creator: Lee Reilly
date: 2026-05-13T16:00:00Z
subject: Application development
subject: Developer skills
subject: Gaming
subject: Open Source
subject: game development
subject: open source
description: Roguelikes don’t die. They fork, mutate, get argued over, rewritten, abandoned, and revived again. Sometimes all at once. The post Dungeons & Desktops: 10 roguelikes that never die (because their communities won’t let them) appeared first on The GitHub Blog.
encoded: The first version of NetHack was released in 1987 as a heavily modified descendant of Hack, itself based on Rogue, a Unix-era experiment built for character-based terminals around 1980. The term “roguelike” later emerged in the early 1990s. This is also when Usenet communities, like rec.games.roguelike, were founded. Players and developers gathered there to trade ideas, variants, and philosophies inspired by Rogue’s design. <img data-recalc-dims="1" fetchpriority="high" decoding="async" height="640" width="1024" src="https://github.blog/wp-content/uploads/2026/05/Screenshot-2026-05-08-at-2.44.35-PM.png?resize=1024%2C640" alt="" class="wp-image-95913" srcset="https://github.blog/wp-content/uploads/2026/05/Screenshot-2026-05-08-at-2.44.35-PM.png?w=1060 1060w, https://github.blog/wp-content/uploads/2026/05/Screenshot-2026-05-08-at-2.44.35-PM.png?w=300 300w, https://github.blog/wp-content/uploads/2026/05/Screenshot-2026-05-08-at-2.44.35-PM.png?w=768 768w, https://github.blog/wp-content/uploads/2026/05/Screenshot-2026-05-08-at-2.44.35-PM.png?w=1024 1024w, https://github.blog/wp-content/uploads/2026/05/Screenshot-2026-05-08-at-2.44.35-PM.png?w=288 288w" sizes="(max-width: 1000px) 100vw, 1000px" /> Screenshot of Rogue courtesy of the Retro Rogue Collection. The player “@” can be seen above a food item “%” and a jelly monster “J”. That lineage helps explain something unusual about the genre. NetHack was developed collaboratively over networked systems before most people even had internet access. Angband required a coordinated relicensing effort decades later just to become fully open source. And Pixel Dungeon was declared “complete”… and then immediately forked by the community into dozens of new games. Recently, I built a small experiment that turns a GitHub repository into a roguelike dungeon. That idea came from the gaming genre that has been evolving in the open for decades, shaped as much by players as by developers. Many of the games that defined roguelikes are still …

GitHub Copilot individual plans: Introducing flex allotments in Pro and Pro+, and a new Max plan
type: item
creator: Natalie Guevara
date: 2026-05-12T17:35:41Z
subject: Company news
subject: News & insights
description: Starting June 1, our lineup of individual plans will update based on your feedback. The post GitHub Copilot individual plans: Introducing flex allotments in Pro and Pro+, and a new Max plan appeared first on The GitHub Blog.
encoded: We’ve heard your questions about whether the included usage in each GitHub Copilot plan will go far enough when we transition to usage-based billing on June 1st. Longer agent runs, multi-step work, and more capable models will all put pressure on the usage amounts detailed in our original announcement. We’re updating the individual lineup based on that feedback. Pro and Pro+ will include more total usage at the same price through a new flex allotment, and we’re introducing Max, a new plan for sustained, high-volume Copilot work. What’s included The individual Copilot lineup will span Free, Pro, Pro+, and Max, with usage-based billing across all plans. Free will continue to include a limited number of code completions each month, plus limited chat and agent usage with auto mode. For paid plans, monthly included usage comes in two parts: Base credits: matched 1:1 with your subscription price. These never change. Flex allotment: variable additional usage on top of your base. Flex allotments will vary over time. Below are the individual plans as of June 1, 2026: Plan Price Base Flex Total included usage Pro $10/month $10 $5 $15 Pro+ $39/month $39 $31 $70 Max $100/month $100 $100 $200 How it works Your base credits are used first. If you go beyond your base, the flex allotment is applied automatically at the same rates across your IDE, github.com, and the CLI. You don’t need to turn anything on or manage a separate bucket; your dashboard will show what’s available and what you’ve used. And if you use everything included in your plan, you can purchase more usage and keep going. Code completions and next edit suggestions remain unlimited on paid plans and don’t consume credits. Why flex can change The flex allotment is a variable part of your included usage; it is designed to adapt as the economics of AI evolve, including model pricing, new models, and improvements in efficiency. Your base credits, which are 1:1 to your subscription price, will always stay the same. What t…

Dungeons & Desktops: Building a procedurally generated roguelike with GitHub Copilot CLI
type: item
creator: Lee Reilly
date: 2026-05-12T15:00:00Z
subject: AI & ML
subject: Application development
subject: Gaming
subject: GitHub Copilot
subject: gaming
subject: GitHub Copilot CLI
description: Learn how one Hubber used GitHub Copilot CLI to build an extension that turns any codebase into a unique, roguelike dungeon. The post Dungeons & Desktops: Building a procedurally generated roguelike with GitHub Copilot CLI appeared first on The GitHub Blog.
encoded: I got nerd-sniped into the GitHub Copilot CLI Challenge and made a questionable decision: I turned my codebase into a roguelike dungeon. It started with a simple prompt: Build a GitHub CLI extension in Go that takes the current repository and turns it into a playable roguelike dungeon, with dungeons generated with BSP [snip]. And then /yolo . The result is GitHub Dungeons, a terminal game that generates a dungeon from your codebase. Rooms, corridors, and enemies, all built from your repo and rendered right in your terminal. You navigate with arrow keys, fight bugs, and hunt for the exit. Every repository produces a different map. Every commit reshapes the layout. And if your HP hits zero, you start over. <img data-recalc-dims="1" loading="lazy" decoding="async" height="432" width="1024" src="https://github.blog/wp-content/uploads/2026/05/Screenshot-2026-05-01-at-3.53.00-PM.png?resize=1024%2C432" alt="Screenshot of 'gh dungeons'" class="wp-image-95698" style="width:755px;height:auto" srcset="https://github.blog/wp-content/uploads/2026/05/Screenshot-2026-05-01-at-3.53.00-PM.png?w=1351 1351w, https://github.blog/wp-content/uploads/2026/05/Screenshot-2026-05-01-at-3.53.00-PM.png?w=300 300w, https://github.blog/wp-content/uploads/2026/05/Screenshot-2026-05-01-at-3.53.00-PM.png?w=768 768w, https://github.blog/wp-content/uploads/2026/05/Screenshot-2026-05-01-at-3.53.00-PM.png?w=1024 1024w" sizes="auto, (max-width: 1000px) 100vw, 1000px" /> 💡 Fun fact: /yolo (“you only live once”) is a Copilot CLI command (an alias for /allow-all). Fitting, since roguelikes are built around permadeath. You really do only get one life. Roguelikes trace back to games like Rogue in the 1980s – terminal-based adventures where each run generated a new dungeon, and death meant starting over. That combination of procedural generation, permadeath, and text-based interfaces (later formalized in things like the “Berlin Interpretation”) makes the genre feel surprisingly modern, and a perfect fit for t…

GitHub for Beginners: Getting started with OSS contributions
type: item
creator: Kedasha Kerr
date: 2026-05-11T16:00:00Z
subject: Developer skills
subject: GitHub
subject: GitHub for beginners
subject: open source
description: Learn how to find opportunities to contribute to the open source community. The post GitHub for Beginners: Getting started with OSS contributions appeared first on The GitHub Blog.
encoded: Welcome back to GitHub for Beginners. So far, we’ve discussed GitHub Issues and Projects, GitHub Actions, security, GitHub Pages, and Markdown. This time we’re going to talk about open source software and how to contribute to that community. By the end of this post, you’ll know what open source is, how to find projects to work on, how to read an open source repository, as well as start making your first contributions. So let’s get started! As always, if you prefer to watch the video or want to reference it, we have all of our GitHub for Beginners episodes available on YouTube. What is open source? Open source software (OSS) refers to software that features freely available source code. In contrast with “closed source software,” OSS is publicly available for anyone to use and build upon. This means that all of the work, including the codebase and communication between users, is available for everyone to see. If you’re just getting started in the world of software development, browsing and contributing to open source projects is a great way to dip your toes into large, impactful projects used by countless users worldwide. GitHub is the home for open source software, so let’s look at how to find projects you can contribute to. How to find OSS projects to work on Contributing to an open source software project for the first time can be daunting—we’ve all been there! The first step is to look for projects in a language that you know which are accepting new contributors. One of the ways you can do this is to ask GitHub Copilot Chat for help. Navigate to github.com and select the Copilot icon to open a chat window. In the bottom-left corner of the chat window, use the combo box to select Ask. Enter a prompt like the following, but remember to update it for a language you’re comfortable with. I’m looking for a list of open source projects written in TypeScript that are accepting new contributors. Search GitHub and narrow down the list to repositories that use the good first…

Why age assurance laws matter for developers
type: item
creator: Margaret Tucker
date: 2026-05-08T16:30:00Z
subject: News & insights
subject: Policy
subject: maintainers
subject: open source
subject: policy
description: Youth safety requirements are moving down the tech stack to operating systems and app stores—raising new questions for open source developers. The post Why age assurance laws matter for developers appeared first on The GitHub Blog.
encoded: Policymakers around the world are advancing age assurance proposals to protect children and teens online. Some approaches restrict minors’ access to certain services or content, while others would require devices, operating systems, or app stores to collect age information and pass age signals to apps and websites. These proposals are driven by serious concerns, but without appropriate scoping, they risk imposing burdensome requirements on open source software and developer infrastructure services that do not present the same risks to minors as consumer-facing platforms. In this blog post, we’ll provide an overview of what developers should know and how to engage. The harms these laws aim to address are serious and deserve attention. Grooming for sexual purposes, exposure to violent content, and online bullying are just some of the risks young people are facing online. At the same time, participation in online communities, including open source software development, can be an important part of a young person’s education and social life. When trying to strike a balance between freedom and protection, policymakers are not always aware of how their proposals could affect developers or how the open source ecosystem operates. “Age assurance” refers to a range of approaches used to determine or estimate a user’s age. It is sometimes used interchangeably with “age verification,” which typically refers to higher-confidence methods like photo ID matching or checks against financial or identity systems. Age assurance also includes self-attestation (where users report their age) and age estimation (where age is inferred from signals, facial scanning, or behavior). These approaches span a wide spectrum, with ongoing debate about tradeoffs between accuracy, privacy, security, interoperability, and accessibility. Proposals also vary in what age thresholds trigger restrictions, the services or content covered, how parental consent should factor in, and how access is limited. While…

How researchers are using GitHub Innovation Graph data to reveal the “digital complexity” of nations
type: item
creator: Kevin Xu
date: 2026-05-08T15:00:00Z
subject: News & insights
subject: Policy
subject: Innovation Graph
subject: open source
description: Researchers share in an interview how they used GitHub data to predict GDP, inequality, and emissions in ways that traditional economic data misses, along with our Q4 2025 data release. The post How researchers are using GitHub Innovation Graph data to reveal the “digital complexity” of nations appeared first on The GitHub Blog.
encoded: One of our goals for the GitHub Innovation Graph was to facilitate research on the economic impact of open source software and developer collaboration. In a paper recently published by Research Policy, four researchers used Innovation Graph data to do just that. I’m happy to share an interview with these researchers, along with our Q4 2025 data release. The Research Policy paper examines whether the geography of open-source software production on GitHub can reveal the “digital complexity” of nations, and whether that complexity predicts GDP, inequality, and emissions in ways that traditional economic data misses. Meet the four researchers: Sándor Juhász is a research fellow at the Corvinus University of Budapest. His work focuses on economic geography, knowledge networks, and how spatial structures shape innovation. Johannes Wachs is an Associate Professor at Corvinus University of Budapest, Director of the Center for Collective Learning at the Corvinus Institute of Advanced Study, and a researcher at the Complexity Science Hub in Vienna. His work sits at the intersection of computational social science and economic geography, with a particular focus on open-source software communities. Jermain Kaminski is an Assistant Professor at the School of Business and Economics at Maastricht University. His research specializes in entrepreneurship, strategy, and causal machine learning, with a focus on how data-driven methods can improve decision-making and innovation. He is a cofounder of the Causal Data Science Meeting. César A. Hidalgo is a professor at the Toulouse School of Economics and Corvinus University of Budapest, and he is the Director of the Center for Collective Learning. He is also the creator of the Observatory of Economic Complexity and cofounder of DataWheel. Research Q&A Kevin: Thanks so much for chatting, everyone! Could you give a quick high-level summary of the paper for our readers here? Sándor: For the last fifteen years or so, economists have been mea…

Improving token efficiency in GitHub Agentic Workflows
type: item
creator: Landon Cox
date: 2026-05-07T23:00:00Z
subject: AI & ML
subject: Automation
subject: CI/CD
subject: Enterprise software
subject: Generative AI
subject: GitHub Copilot
subject: LLMs
subject: Machine learning
subject: agentic workflows
description: Agentic workflows that run on every pull request can quietly accumulate large API bills. Here's how we instrumented our own production workflows, found the inefficiencies, and built agents to fix them. The post Improving token efficiency in GitHub Agentic Workflows appeared first on The GitHub Blog.
encoded: GitHub Agentic Workflows is like a team of street sweepers that clean up little messes in your repo. These teams significantly improve repo hygiene and quality, but as with all agentic work, cost is a growing concern for developers. And because CI jobs like agentic workflows are automatically scheduled and triggered, costs can accumulate out of view. Thankfully, making automations more efficient is easier than doing the same for interactive desktop sessions. Work done during a developer session can be hard to predict, but agentic workflows’ work is fully specified in YAML and repeats every execution. Because we maintain and use GitHub Agentic Workflows in our own GitHub repositories, we worry about token efficiency as much as our users. That is why in April 2026, we began to systematically optimize the token usage of many of the workflows that we rely on every day. This post describes what we instrumented, the optimizations we applied, and our preliminary results. Logging token usage We rely on hundreds of agentic workflows in our repos for maintenance and CI. All workflows run as GitHub Actions against real API rate limits. We are building the plane as we fly it and burning jet fuel as we go. Before we could optimize our token consumption, we needed to know how tokens were consumed. The first challenge we faced was that each agent framework (Claude CLI, Copilot CLI, Codex CLI) emitted logs in a different format, and usage data could be incomplete for historical runs. Thankfully, the agentic-workflows security architecture uses an API proxy to prevent agents from directly accessing authentication credentials. This proxy gave us a way to capture token usage across all runs in a single normalized format, regardless of agent framework. Every workflow now outputs a token-usage.jsonl artifact with one record per API call that contains input tokens, output tokens, cache-read tokens, cache-write tokens, model, provider, and timestamps. Combining this data with the rest of …

Agent pull requests are everywhere. Here’s how to review them.
type: item
creator: Andrea Griffiths
date: 2026-05-07T19:00:00Z
subject: AI & ML
subject: Generative AI
subject: GitHub Copilot
subject: AI agents
subject: code review
subject: pull requests
subject: tech debt
description: A practical guide to reviewing agent-generated pull requests: what to look for, where issues hide, and how to catch technical debt before it ships. The post Agent pull requests are everywhere. Here’s how to review them. appeared first on The GitHub Blog.
encoded: You’ve probably already approved one without realizing it. The tests passed. The code was clean. You merged it. But it was agent-generated—and that ease of approval is exactly the problem. A January 2026 study, “More Code, Less Reuse”, found that agent-generated code introduces more redundancy and more technical debt per change than human-written code. The surface looks clean. The debt is quiet. And reviewers, according to the same research, actually feel better about approving it. This isn’t an argument to slow down. It’s an argument to be intentional. There’s a difference. Agent pull requests are already saturating review bandwidth The volume is already staggering. GitHub Copilot code review has processed over 60 million reviews, growing 10x in less than a year. More than one in five code reviews on GitHub now involve an agent. That’s just the automated review pass. The pull request themselves are multiplying faster than reviewers can handle. The traditional loop—request review, wait for code owner, merge—breaks down when one developer can kick off a dozen agent sessions before lunch. Throughput has scaled exponentially. Human review capacity hasn’t. The gap is widening. You’re going to review agent pull requests. The question is whether you’ll catch what matters when you do. Who (or what) actually wrote this pull request Before you look at a single line of diff, you need a model for what you’re reviewing. A coding agent is a productive, literal, pattern-following contributor with zero context about your incident history, your team’s edge case lore, or the operational constraints that don’t live in the repository. It will produce code that looks complete. But that “looks complete” failure mode is dangerous. You’re the one who carries that context. That’s not a burden. It’s the actual job. The part of review that doesn’t get automated is judgment, and judgment requires context only you have. One note for authors If you’re opening an agent-generated pull request, ed…

Validating agentic behavior when “correct” isn’t deterministic
type: item
creator: Gaurav Mittal
date: 2026-05-06T21:16:31Z
subject: AI & ML
subject: Generative AI
subject: GitHub Copilot
subject: LLMs
subject: Machine learning
subject: AI agents
subject: Dominator Analysis
subject: GitHub Actions
description: How to build the “Trust Layer” for Github Copilot Coding Agents without brittle scripts or black-box judgements by using dominatory analysis. The post Validating agentic behavior when “correct” isn’t deterministic appeared first on The GitHub Blog.
encoded: Modern software testing is built on a fragile assumption: correct behavior is repeatable. For deterministic code, that assumption mostly holds. But for autonomous agents like Github Copilot Coding Agent (aka Agent Mode), especially as we explore the frontiers of integrated “Computer Use,” that assumption breaks down almost immediately. As agents move beyond simple code suggestions to interacting with real environments like UIs, browsers, and IDEs, correctness becomes multi-path. Loading screens can appear or disappear, timing shifts, and multiple valid action sequences can lead to the same result. Unless our GitHub Actions workflows are robust enough to account for this variability, it’s common for an agent to succeed at a task while the test still fails—a “false negative” that halts production. This blog post explores how to move past brittle, step-by-step scripts and toward an independent “Trust Layer” for agentic validation. We will demonstrate a model that focuses on essential outcomes rather than rigid paths, providing a way to validate behavior that is explainable, lightweight, and ready for real-world CI pipelines. The challenges of agent-driven validation Imagine you’re responsible for a GitHub Actions pipeline that relies on Copilot Agent Mode to validate real-world workflows. The agent could be leveraging Computer Use, navigating within a containerized cloud environment, for the workflow validation. On Tuesday, the build is green. On Wednesday, the test fails—even though no code has changed. Here’s what happened: A minor network lag on the hosted runner caused a loading screen to persist for a few extra seconds. The agent waited, adapted, and successfully completed the tasks correctly. But your CI pipeline still flagged the run as a failure—not because the task failed, but because the execution path no longer matched the recorded script or assertion timing. The agent didn’t fail. The validation did. This surfaces three recurring pain points that create a “…

Welcome to Maintainer Month: Celebrating the people behind the code
type: item
creator: Abigail Cabunoc Mayes
date: 2026-05-05T14:30:00Z
subject: Maintainers
subject: Open Source
subject: Maintainer Month
subject: open source
description: What maintainers are telling us, what we've shipped, and how to celebrate the people behind open source. The post Welcome to Maintainer Month: Celebrating the people behind the code appeared first on The GitHub Blog.
encoded: At a Maintainer Unconference in Brussels this year, a breakout session had maintainers jotting down thoughts on the future of open source. One sticky note stood out: As AI gets better at writing code, human work around code becomes more important and more invisible. Mentoring new contributors, building trust across a community, making the judgement calls that shape a project’s direction: that’s the work that turns a repository into a living collaboration. And with the speed of AI, the people doing the work are carrying more than ever. Pull requests merged on GitHub have nearly doubled year over year, and agentic workflows are accelerating the pace even further. As one maintainer put it: How much time should I spend on something that you didn’t spend any time on? I’ve been part of Maintainer Month for five years now. The conversations I’m having with maintainers this year feel different—there’s a weariness, but there’s also innovation. Maintainers are converging on standards like agents.md, building trust systems, and designing workflows that put them back in control. In February, Ashley Wolf named the influx of low-quality contributions open source’s Eternal September. Maintainers told us exactly what they needed. We took notes. Six years ago we started Maintainer Month because the people behind open source deserve better tools, real resources, and community. This year, we’re going bigger on all three. Tools: Big releases for maintainers this month Maintainers need better ways to manage who contributes, how, and at what volume. In the Eternal September post, we shared some of the directions we were exploring. Here’s where things stand. Granular contribution limits: This one’s for every maintainer who’s watched their pull request queue turn into a firehose. This gives maintainers the ability to introduce limits on how many pull requests a new or unknown user can make in your project. No more choosing between closing the doors and opening the floodgates. You control h…