GitHub Octoverse 2026: AI Agents Now Start Over 40% of Pull Requests as Surging Load Strains Infrastructure

Generative AI in software development is moving beyond helping developers type code toward handing the work itself to AI agents. Instead of writing code line by line, developers now describe what they want fixed or achieved and delegate changes spanning an entire repository to an agent. This shift is changing not only how software is built but also putting unprecedented load on GitHub, the code-sharing platform.

GitHub's annual report, "Octoverse 2026", published on October 28, 2026, puts concrete numbers on that change. Code pushes, commits, and pull requests have surged, and the use of AI agents has expanded in a short time. At the same time, GitHub has been unable to keep up with the growing processing load and has suffered repeated large-scale service outages. Read alongside the technical documents on its infrastructure that the company has published, the report shows that the spread of AI agents is forcing changes not only in software development productivity but also in the design of the systems underneath it.

17.9 billion pushes a year: the scale of development in the AI agent era

Octoverse 2026 covers the 12 months from October 1, 2025, to September 30, 2026. The statistics include both public and private repositories and, unless otherwise noted, are aggregated on that basis. Previous reports focused mainly on public activity and covered September through the following August, so GitHub recalculated the 2024 and 2025 figures using the same definition and period as this year's. Readers comparing these numbers directly with those in earlier annual reports should keep the difference in methodology in mind.

On a consistent basis, activity in 2026 far exceeded the previous two years. Annual code pushes reached 17.9 billion, more than the 11.9 billion combined from 2024 (5.2 billion) and 2025 (6.7 billion). Commits across public and private repositories also reached 34.3 billion, more than triple the 10 billion in 2024. The frequency with which code changes are sent to GitHub has risen sharply in just two years.

The 2024 and 2025 figures for pushes, commits, pull requests, and Actions job runs use the recalculated values GitHub published in Octoverse 2026. Contributions to open source is a separate metric covering public repositories, and the source material does not give a comparison figure for 2024.

Activity around review and automation is also growing. In 2026, 1.3 billion pull requests (PRs) were merged, an average of about 3.5 million per day. Public contributions to open source rose from 1.12 billion in 2025 to 2.5 billion in 2026. This count includes not only code pushes but also creating issues, creating and reviewing PRs, and taking part in discussions. Even if a single push contains multiple commits, it counts as one contribution, so total commits and contributions are not the same metric.

GitHub's developer population continues to grow as well. As of September 2026, the number of developers worldwide passed 225 million. By country, the United States led with 38.3 million and India followed with 32 million; each added more than 10 million developers over the past year. Japan ranked fifth in the world with 7.15 million, behind the US, India, China, and Brazil.

{
  "type": "bar",
  "title": "主要国のGitHub開発者人口（2026年9月時点）",
  "unit": "百万人",
  "categories": ["米国", "インド", "中国", "ブラジル", "日本", "英国", "インドネシア", "ドイツ"],
  "series": [
    {
      "name": "開発者数",
      "values": [38.3, 32.0, 12.4, 10.2, 7.15, 6.47, 6.34, 6.30]
    }
  ],
  "caption": "GitHubのユーザープロファイルに登録された所在地に基づく集計",
  "source": "GitHub Octoverse 2026"
}

Activity on GitHub jumped especially from June 2026 onward. GitHub's data shows development activity rising gradually from January, then accelerating sharply after June. The timing coincides with improvements in large language model (LLM) performance and the maturing of the harnesses and development tools that support agents. AI agents no longer merely suggest code in one-off chats; they sustain work across multiple days and call on other agents with specialized roles. The ability to run multiple tasks in parallel in the cloud, not just in local environments, is also thought to have contributed to the surge.

About 55% of commits since June came from repositories newly created in 2026. The expansion is not driven by new developers alone, however. Developers who pushed code over the past 12 months had been on GitHub for an average of 36 months, and more than 75% of developers who created a PR in August also pushed code in September. The number of repositories each developer is involved in has also risen by an average of 10% over the past year. New projects are increasing, and existing developers are active in more repositories as well.

These changes also show up in the use of automated development infrastructure. GitHub Actions ran an average of 1,440 jobs per second in 2026, about 124 million per day and roughly 45.4 billion for the year, more than triple the previous year's total. PRs merged by Dependabot, which automates dependency updates, exceeded 30 million, about double 2025. Automation is growing across the whole development process, not just AI code generation but also testing, builds, security scanning, and dependency updates.

Over 40% of PRs now start with agents, and the role of code review is changing

One of the most notable findings in Octoverse 2026 is the degree to which AI agents are involved in creating pull requests. In March 2026, PRs that began with a first draft created by an agent made up 17% of the total; by September that figure exceeded 40%. In September alone, agent-initiated PRs reached 110 million, about six times the March level. A workflow in which a developer specifies the change, an agent generates the code, and a human then reviews it is spreading quickly.

These percentages are based on agent usage that GitHub was able to detect. GitHub tallies observable signs of use, such as PR creation by agents, as "agent signals." Some usage falls outside what can be detected, such as a developer using AI to write code in a local environment. A PR with no detected signal therefore cannot necessarily be assumed to have been written without AI.

PRs involving agents also differ in the breadth of what they change. The share containing changes spanning multiple files was 87% for agent-initiated PRs versus 79% for PRs without an agent signal. AI agents are being used for changes that affect multiple files, not just a single function or configuration.

The path from PR creation to merge has also changed. In February 2026, the share merged within two weeks was 83% for agent-initiated PRs, below the roughly 86% for the comparison PRs. By September, the comparison group was roughly flat at about 86%, while agent-initiated PRs rose to 90%. Changes generated by agents are now being merged in a shorter time.

Still, an improved merge rate alone does not prove that the quality of AI-generated code has improved. Teams may have improved their review processes, or the kinds of work delegated to agents may have changed. And because PRs without agent signals also include undetected AI use, the two sets of figures should not be treated as a pure comparison of human and AI performance.

GitHub Copilot usage trends also support the view that delegating work to agents is spreading. Among Copilot's monthly active users, the share using agent features rose from 35% a year earlier to 55%. In particular, usage of the "Copilot cloud agent," which works independently after a developer assigns a task, grew 230% year over year, far outpacing the 85% growth in interactive agent chat. Developers are not just asking AI questions; they are entrusting it with carrying out specific tasks.

The range of work entrusted to agents is widening too. New public repositories mentioning interoperability or reverse engineering rose from about 30,000 in 2025 to more than 130,000 in 2026, growth of over 300% year over year, indicating rising interest in areas such as ensuring compatibility with existing systems and reimplementing protocols. However, this figure counts repositories containing related terms and does not show that AI agents were used in every such project.

Meanwhile, the faster code is generated, the heavier the burden of human review becomes. To address this, GitHub launched a public preview of "Stacked pull requests" on July 30, 2026. The feature lets developers split related changes into small PRs and review them in order while preserving dependencies, and more than 264,000 developers had used it by September. Usage of AI-powered code review and GitHub Advanced Security also each grew more than 90% year over year.

The volume of security processing is rising as well. Push protection, which prevents sensitive information such as API keys and passwords from being pushed to repositories by mistake, performed 5.8 billion scans during the year, about four times the previous year. As AI agents can generate large volumes of changes, development organizations are required to have the ability not only to write code quickly but to verify changes and ensure their safety, more than ever before.

Surging development load triggers major outages, and GitHub overhauls its storage foundation

The expansion of agent-driven development is placing heavy load on GitHub's own infrastructure. Monthly commits jumped from 1.4 billion in April 2026 to 2.9 billion in August and 7.4 billion in September. That is more than a fivefold increase over the five months from April to September, and September's commits reached about six times those of the same month a year earlier. As multiple agents now change code at the same time alongside human developers, the processing capacity GitHub needs has changed dramatically in a short time.

GitHub said it added 4 million CPU cores, 160 petabytes (PB) of high-speed storage, and 50 terabits per second (Tb/s) of network bandwidth in 2026 to meet demand. Even so, these large-scale expansions did not prevent service outages. In August 2026 in particular, multiple services essential to development, including GitHub Actions, authentication, and APIs, went down for long periods.

According to the incident report GitHub published on August 20, the August 17 outage lasted 7 hours and 47 minutes. A critical infrastructure component in a US central data center could not cope with surging traffic, and the failure spread to authentication and other processing. The impact extended beyond the github.com web interface to major features including GitHub Actions, the REST/GraphQL APIs, pull requests, issues, and Copilot. Earlier, on August 6, GitHub Actions had suffered a 10-hour-42-minute outage.

GitHub explained that for both outages the root cause was insufficient capacity, not code or configuration changes. In other words, core components could not be scaled enough before demand exceeded the system's capacity. UK outlet The Register reported, based on external data reconstructed from GitHub's status page, that availability over the prior 90 days had fallen to about 84% as of May 7, 2026. However, this figure is an independent tally of outage time and is not the same metric as the uptime or SLA attainment rates GitHub publishes for individual services.

Agent-related features have also suffered outages caused by load surges. According to the April 2026 availability report, in the Copilot coding agent outage on April 9, about 84% of new session requests were delayed. Queue wait times that are normally about 15 to 40 seconds reached up to 54 minutes, and about 22,700 workflow creations were delayed or failed. The cause was a flaw in the rate-limit implementation: a limit that should have applied per individual installation was applied across all users. A client-side update that sent access to internal APIs soaring to three to four times normal levels also worsened the outage.

Following these problems, GitHub concluded that adding hardware alone would not meet future demand and began reexamining the structure of the system itself. In the official announcement about GitHub Universe 2026 on October 28, 2026, Jay Parikh, who leads Microsoft's CoreAI division, explained that adding capacity is important but not enough to reach the goals, and that architectural changes became necessary.

At the center is a redesign of the Git storage foundation. According to a technical explanation GitHub published on October 6, the traditional system kept repository data on multiple storage servers and ensured consistency through a distributed quorum when writing. However, a mechanism that serializes write processing per repository has a limitation: when a large volume of writes hits the same repository, processing becomes concentrated.

In an environment where human developers push changes relatively infrequently, this approach rarely caused major problems. In an environment where thousands of agents update separate branches within the same repository, however, write processing tends to pile up in a single queue. The old design also had another problem: adding replicas to spread read load increased the number of targets to synchronize on writes, so strengthening read capacity slowed write processing.

To remove these constraints, the new architecture GitHub is building introduces two main changes. First, it subdivides write locking from the whole repository down to individual references such as branches and tags. Second, it separates the storage responsible for durable data persistence from the compute resources that handle requests, so each can be scaled independently.

In a technical explanation published on October 21, GitHub reported that reference-level locking improved write throughput by three to four times in internal tests simulating real traffic. Separately, internal benchmarks of the full next-generation architecture confirmed up to 35 times the write throughput. However, the two results measure technologies at different stages, and a 35-fold performance improvement has not been achieved across the existing production environment. Specific measurement conditions and third-party reproduction results have not been made public.

The new architecture aims to use Microsoft Azure object storage as the durable home for data, with a configuration in which the compute resources handling reads can be scaled up and down as needed. Even if a read-only processing node is lost to a failure, it can recover by fetching data from durable storage, reducing the need to rebuild a complete repository replica as before. Furthermore, when multiple agents write to different branches at the same time, reference-level control can reduce unnecessary waiting.

These mechanisms are still being rolled out in stages, though. As of October 21, 2026, 99.99999% of repositories on GitHub are configured with a replica on Azure, but migration from the legacy storage foundation is not fully complete. For some of the most write-intensive repositories, cross-region communication latency is a constraint on migration. GitHub plans to complete the move to a multi-region configuration on Azure by early 2027 and intends to introduce the new storage design in stages.

It cannot be said that the spread of AI agents is the sole cause of GitHub's outages, but GitHub's own incident reports and technical documents confirm that the sudden increase in processing load exposed the limits of existing systems. What matters next is how much the new architecture actually improves capacity in the production environment, and whether the frequency and scope of outages shrink. For development organizations that depend heavily on GitHub, the availability of the code management platform, not just the performance of AI agents, needs to be built into operational design.

From a single model to coordinated models: how Copilot Fusion changes the cost structure of AI development

Alongside the growing use of AI agents, the way developers choose AI models is also changing. According to Octoverse 2026, among GitHub Copilot users who select models themselves, the share using multiple models rose from 50% in May 2026 to 61% in September. The number of distinct models used by paid-plan users also grew from 29 in May to 47 in September. In September, no single model accounted for more than 25% of all requests.

A closer look at model selection shows developers matching models with different characteristics to different purposes. In requests where users explicitly specified a model, general-purpose models accounted for 38%, models strong at advanced reasoning and planning 37%, and fast, lightweight models 25%. This tally excludes requests made through Copilot's automatic model selection, internal use by GitHub and Microsoft, and requests for monitoring or testing purposes. It therefore reflects usage trends when developers choose models themselves, not Copilot's total inference volume.

{
  "type": "bar",
  "title": "Copilotで明示的に選択されたリクエストのモデル分類比率",
  "unit": "%",
  "categories": ["汎用モデル", "高度な推論・計画モデル", "高速・軽量モデル"],
  "series": [
    {
      "name": "リクエスト比率",
      "values": [38, 37, 25]
    }
  ],
  "caption": "2026年9月のモデル利用状況を基にした分類。自動モデル選択によるリクエストなどは対象外",
  "source": "GitHub Octoverse 2026"
}

To automate this kind of model switching, GitHub made a new feature, "GitHub Copilot Fusion," generally available on October 28, 2026. According to GitHub's official announcement, Copilot Fusion is not a new standalone AI model but a runtime routing and orchestration mechanism that picks the right model for a task and, when needed, coordinates multiple models. It aims to reduce the need for developers to switch models manually for each task and to balance output quality against cost.

Copilot Fusion uses three execution patterns depending on the task. "Single" completes processing with one model. "Cascade" generates a first answer with an efficient model, evaluates its quality, and hands off to a higher-performance model if necessary. In "Critique," one model reviews an answer written by another, and the first model revises based on the result. Rather than calling multiple models for every task, the mechanism chooses a processing method according to the difficulty of the work.

Instead of model names, developers choose among three effort levels: "Standard," "High," and "Max." Standard emphasizes a balance of quality, cost, and response speed for everyday development work, while High handles tasks such as fixing complex bugs and changes spanning multiple files. Max is the setting for tasks that require the most advanced reasoning. Copilot Fusion is available in Visual Studio Code, GitHub Copilot CLI, the Copilot app, and JetBrains IDEs.

The predecessor to this feature was "Project HydraFusion," released as a research preview on September 4, 2026. According to GitHub, about 60,000 sessions were routed through the CLI and the Copilot app during the preview. In GitHub's internal evaluation, on the coding benchmark "TerminalBench 2.1," it maintained results equal to or better than a configuration based on Claude Opus 5 while cutting estimated cost by 67%. However, that figure comes from an offline evaluation run by GitHub, and the same reduction does not necessarily apply to all development work.

Verification results from an outside evaluator have also been published for the generally available Copilot Fusion. In an evaluation Artificial Analysis released on October 28, 2026, Copilot Fusion Max, the top setting, scored 60.0 on the "Coding Agent Index v2.0." The comparison configuration of Claude Code with Claude Opus 5.5 Max scored 61.7, a gap of 1.7 points.

This comparison is based on Artificial Analysis's agent comparison data. Token consumption is given as about 7.2 million in the company's explanatory article and about 7.3 million in the comparison data, owing to differences in rounding. API cost is an estimate based on tokens consumed in the benchmark and does not represent subscription fees or a company's total operating cost.

What stands out in these results is the balance between performance and cost. Copilot Fusion Max kept an overall score close to the Claude Code and Opus 5.5 Max configuration while holding average API cost per task to about half. Token consumption was also roughly halved, showing that combining multiple models can create a cost structure different from always using the highest-performing model.

A close overall score does not mean equivalent performance on every coding task, however. In Artificial Analysis's evaluation, Copilot Fusion Max scored 71 on "Terminal-Bench 4.0" but 51 on "FrontierCode," which evaluates code changes to a repository, below the 56 for Claude Code + Opus 5.5 Max. On "SWE-Atlas-QnA-AA," which evaluates question answering about repository contents, Copilot Fusion Max scored 57 against 66 for the comparison. In other words, it performed strongly on work involving terminal operations, but gaps remain in code changes and repository understanding.

The time figures also need to be read in light of the evaluation conditions. GitHub says Copilot Fusion Max processed tasks in about 40% less time than the comparison, and Artificial Analysis's comparison page lists 36.1 minutes against about 60 minutes. These are averages on a specific benchmark, however, and do not directly predict working time in real development settings. Results may vary with the size of the repository, the difficulty of the task, and the combination of models called.

The pricing structure also differs from using a single model. According to GitHub's official documentation, Copilot Fusion itself carries no additional charge, but each model used internally is billed at its own standard rate. Through November 30, 2026, GitHub is giving paid Copilot plan users a 30% discount on Fusion's model usage charges. Standard is available on all Copilot plans, while High and Max are limited to eligible plans such as Pro+, Max, Business, and Enterprise.

That 63% of paid Copilot users had used the automatic model selection feature at least once as of September 2026 also points to demand for this kind of mechanism. Going forward, competition is likely to hinge not only on the performance of a single model but also on mechanisms that route work among models by task and on how cheaply the required quality can be secured. Companies adopting it will also need to deal with operational issues unlike those before, such as fluctuations in charges from calling multiple models, confirming which model was selected, and administrator-imposed usage limits.

AI agents reach construction and manufacturing, and TypeScript's presence grows

Octoverse 2026 shows that the spread of AI agents extends beyond the software industry. For the first time, GitHub analyzed which industries public repositories relate to. Specifically, it took a random sample of public repositories created from 2022 to 2026 and classified them with a multilingual embedding model using repository names, descriptions, topics, READMEs, and similar text. Industries were classified using the North American Industry Classification System (NAICS).

The results show that public repositories grew sharply even in industries that had previously had relatively weak ties to software development. Using 2022 as the baseline, mining, quarrying, and oil and gas extraction grew about 65-fold, construction about 18-fold, and administrative and support services about 17-fold. Professional, scientific, and technical services grew about fivefold, and manufacturing about 2.8-fold.

{
  "type": "bar",
  "title": "2022年比の産業別公開リポジトリ増加倍率",
  "unit": "倍",
  "categories": ["鉱業・石油・ガス採掘", "建設業", "事務・支援サービス", "専門・科学・技術サービス", "製造業"],
  "series": [
    {
      "name": "増加倍率",
      "values": [65, 18, 17, 5, 2.8]
    }
  ],
  "caption": "NAICS分類に基づく公開リポジトリ数の変化。2022年時点の母数が小さい分野では増加倍率が大きくなりやすい",
  "source": "GitHub Octoverse 2026"
}

The roughly 65-fold figure for mining is large, but it should be noted that the number of repositories in 2022 was small. When the original base is small, even a handful of new projects can produce a large growth multiple. This classification is also an estimate based on repository descriptions and similar text, and it does not directly show the number of pieces of software actually running in each industry. Even so, it confirms that public activity related to software development is spreading to fields outside information and communications.

Looking at usage by industry, interest in AI and actual use of agents differ. In administrative and support services, mining, healthcare, agriculture, and others, more than 40% of repositories mention AI in their README or topics, yet fewer than 3% had PRs created by agents. In construction, by contrast, about 25% of repositories mentioned AI, but agent-initiated PRs were detected in about 9%. This is the highest rate among the industries surveyed, followed by manufacturing.

The gap shows that developing AI software and using AI agents for development work are separate activities. For example, a team may be building an AI-powered analytics service while humans do most of the actual coding. Conversely, even a project not about AI itself can hand code fixes and testing to agents. However, GitHub's survey can detect only part of agent use and does not fully capture the actual usage rate in each industry.

Changes are also visible in programming language usage. By monthly active contributors in 2026, TypeScript remained first, Python second, and JavaScript third. From September 2025 to September 2026, contributors grew by 3.62 million for TypeScript, 3.23 million for Python, and 1.82 million for JavaScript, with growth in the top two languages standing out. Among major languages, Rust had the highest year-over-year growth rate, with contributors roughly doubling.

In relation to agent use, TypeScript adoption is especially high. Among repositories newly created in 2026 with detected agent signals, 35% used TypeScript as the primary language, versus 24% among repositories without detected signals. For repositories created before 2026, a similar pattern holds: 27% with signals versus 17% without.

The rate of AI involvement in merged PRs also varies by language. For TypeScript, Python, and Rust, PRs with detected AI involvement reached 40 to 44%, while for Java, C#, and C++ the figure was 21 to 34%. AI involvement is confirmed at a certain rate in all major languages, but the rate is higher in the fastest-growing ones.

GitHub points to the ease of verification through static typing and compilers as a possible factor behind this trend. In TypeScript and Rust, type checks and compile-time errors make it easier to find problems in generated code mechanically. For agents too, clear cues for verifying the code they output and fixing errors can be an advantage.

However, these statistics do not establish that AI agents chose TypeScript or similar languages on their own. In some cases developers specify the language from the start, and in others changes follow the existing language of the target repository. The observed data also cannot distinguish whether heavy AI use led to greater adoption of a language or whether developers who use that language are simply adopting AI more eagerly. A link between language characteristics and agent usage trends is certain, but its causality requires further study.

Japan's developer community is also continuing to grow amid these global changes. Japan has 7.15 million GitHub developers, ranking fifth in the world, and GitHub cited government investment in AI infrastructure and talent development in each country as drivers of growth in the Asia-Pacific region. For Japan in particular, it explained that continued investment in AI infrastructure is supporting the growth of the developer community.

How far the developer population will grow, on the other hand, is increasingly uncertain. Using past registration counts and usage trends, GitHub projected the 2031 developer population with 43 time-series and regression models. Of these, 21 models predicted growth of more than three times the 2026 level and 19 predicted growth of two to under three times, while only three predicted less than double. Many models show substantial growth, but the forecasts span a wide range, and the future developer population is not settled.

The sharp growth in 2026 has made forecasts based on earlier trends harder. If AI agents reduce the burden of writing code, people who previously had no involvement in software development may find it easier to join projects. Whether such changes will continue at the same pace, however, is unknown. The forecasts from GitHub's 43 models reflect both the large room for future growth and the uncertainty of the outlook.

What Octoverse 2026 makes clear is that AI agents are beginning to shift from peripheral tools in software development to something that carries out day-to-day work. 17.9 billion pushes a year, agent-initiated changes accounting for more than 40% of PRs, and expanding use of multiple models concretely illustrate that change. At the same time, the surge in code generation is placing new burdens on review, security verification, and infrastructure capacity. Development organizations going forward will need not only to adopt AI agents but also to put in place systems to safely verify large volumes of changes, manage the cost of using multiple models, and design operations that can withstand failures of the development platform.