🌍 The Numbers Before the Products 1:00
Jay Parikh, who runs GitHub plus the broader CoreAI org at Microsoft, opened with the 2026 Octoverse figures rather than the product news. The framing is deliberate: the products announced later in the hour are pitched as a response to load, not as a new direction.
| Metric | On stage | Octoverse 2026 (verified) |
|---|---|---|
| Developers on GitHub | 225 million+ | 225M+ — US 38.3M, India 32.0M, China 12.4M ✓ |
| Pushes, trailing 12 months | 17.9 billion | 17.9B — more than 2024 and 2025 combined ✓ |
| Commits, trailing 12 months | 34.3 billion | 34.3B — more than 3× two years earlier ✓ |
| Merged pull requests | 1.3 billion | 1.3B — ~3.5 million per day ✓ |
| Public contributions | "2.5" (unclear unit) | 2.5 billion, more than double 2025's 1.12B ✓ |
| Public + open-source repos | 566 million, +30% YoY | Not in the Octoverse post — unverified |
| New developer cadence | One per second, two years running | Consistent with Octoverse ✓ |
Two numbers carry the real narrative, and neither was on a slide: in September 2026 alone the platform absorbed 7.38 billion commits, more than five times the year before, and more than 40% of pull requests opened in September started from an agent's first draft — up from 17% in March, or roughly 110 million agent-started PRs in a single month. Actions ran 1,440 jobs per second (124 million a day, more than 3× last year).
Parikh also named community projects as the human counterweight to the graphs — among them the OpenQuake Engine from the Global Earthquake Model Foundation, which does seismic hazard and risk analysis in the open (AGPL-3.0, 465 stars). The other two project names in the transcript could not be matched to a canonical repository, so they are not repeated here.
🧭 The Thesis: The SDLC Is Collapsing 3:26
The conceptual core of the keynote is one sentence: "the SDLC is no longer linear — in fact, the SDLC is collapsing." Work is triggered by a signal (a colleague's request, a production event, a failing check) rather than by a ticket moving through stages, and developers jump between stages depending on the task while agents absorb the implementation and verification work.
He reduces the target to three properties, which the rest of the hour maps onto products:
| Property | What it means on stage | Announcements that answer it |
|---|---|---|
| Velocity | Idea to production, quickly and cost-effectively | Copilot app, Projects, Fusion, Automations |
| Intelligence | Assemble context platform-wide; keep learning | Memory, Dreaming, Code Search ("GitHub intelligence") |
| Quality | Catch security issues and bugs before they land | Code scanning, push protection, code review Max, Agent Merge |
The strategic claim hidden in the middle is about openness: "we are making the primitives available so that you can make them into your own agentic software delivery system." The named ecosystem partners are Datadog, Figma and Cloudflare. That is the honest framing of a platform play — the value sits in the integration surface, so the surface has to stay pluggable. It also sets up the tension the rest of the keynote never resolves: the more of the delivery loop GitHub owns, the less the "openness" is about choice of tools and the more it is about GitHub being the place those tools are invoked from.
🖥️ The Copilot App and Connectors 7:16
Cassidy Williams (Sr. Director, Developer Advocacy) demoed an issue — a "coffee passport" loyalty feature — inside the GitHub Copilot app, the agent-native desktop client. The demo's first act is not coding: it is answering the open product questions on the issue ("what counts as a visit?", "what happens on repeat visits?") without leaving the app.
That is what connectors are for. Parikh describes them as managed services that "sit in a Copilot app or whatever surface" and connect to Slack, Work IQ, Vercel, Netlify and Sentry — authenticate once, use everywhere. Williams points at the verified badge in the Customize tab, which marks the GitHub-managed connectors where you never re-authenticate per device.
The same release also ships computer use in public preview on macOS and Windows: Copilot can read app content, click controls and type inside applications that have no API, CLI or MCP integration — with per-action approval and an org-level kill switch. It is the least-discussed item in the hour and probably the one with the widest blast radius, because it is the only feature that reaches outside the repository and the browser into arbitrary desktop software.
The session model matters more than the window chrome: one session, started on the phone, resumed in the app, in VS Code, in the CLI or on github.com. Parikh's line — the same harness that has "been rolled out across all of Microsoft" — is the actual product: a shared agent runtime with per-surface skins.
🎛️ Canvases: The Browser That Isn't 11:35
The best line in the keynote is a bit of stagecraft: Williams opens what looks like a browser, the agent starts clicking around a passport UI, and then she says it — "this looks like a browser, but it isn't… this is where you all go 'ooh'." It is a canvas: an agent-controllable surface created from the plus button, available as browser canvases, terminal canvases and custom canvases.
Why this is more than a demo trick: a browser agent normally has to be given a URL, a viewport and permissions, and then hopes the page renders the same way. A canvas is the agent's own instrumented surface — the agent that wrote the feature can drive the feature and observe the result directly, which is exactly what the demo does at 10:55 when it logs into a demo account and tests the passport end-to-end.
Then comes the honest engineering admission: the app under test had been rewritten from Java to SvelteKit ("get it? the coffee house… too early?"), so the agent's saved instructions were stale even though the code had moved. That sets up the next section.
🧠 Copilot Fusion: Routing Instead of Picking 9:49
"What model do I pick?" is the question Parikh refuses to leave with the developer. Copilot Fusion replaces the model picker with an effort level and routes per task. It is the one major announcement of the hour that is generally available today.
Three execution patterns
- Single — one model solves the task directly.
- Cascade — an efficient model drafts; a quality check decides whether to accept or escalate to a stronger model.
- Critique — one model drafts, a second reviews, the first revises.
On top of that sit three effort levels the developer chooses: Standard (versatile models, everyday coding), High (capable models, harder reasoning) and Max (the most capable models, most demanding tasks). Administrators can restrict which models Fusion may draw on, set each model's effective policy state, and make Fusion the default via enterprise managed settings.
| Claim on stage | What GitHub's changelog says |
|---|---|
| Fusion Max scored 60 on the Artificial Analysis Coding Agent Index | Confirmed — "Copilot Fusion Max scored 60, within two points of Claude Code with Opus 5.5 Max" |
| "Half the cost per task" | "About half the average API cost per task, using about half as many tokens" |
| "40% less time per task" | Confirmed — "about 40% less time per task" |
| 30% off "through the end of November" | "For a limited time" — the changelog does not name an end date |
| Available broadly | GA on all Copilot plans in VS Code, Copilot app, Copilot CLI, JetBrains; more clients later |
Fusion is the productionized descendant of Project HydraFusion plus Copilot's auto model selection. A separate changelog the same day put local models into Fusion on an opt-in experimental preview: on Windows, MAI Code 1.1 Flash can be downloaded and configured through Windows ML; on macOS and Linux you can point Fusion at a local OpenAI-compatible server running MAI Code 1.1 Flash or Qwen3.8 Flash Next. Routing decisions still happen in the cloud — local inference does not mean an offline session, and the changelog is explicit that local models may carry weaker safety protections.
An AT&T engineer is quoted in the changelog with the practical version of the pitch: developers used to pick a big model for a hard task and forget to switch back, so token efficiency degraded; Fusion removes that friction. That is the real value proposition — not better peak quality, but less waste in the long tail of everyday tasks.
🌙 Dreaming, Memory and Code Search 12:42
The most quietly important feature of the keynote is the one with the silliest name. Copilot Dreaming exists because custom instructions rot: Parikh's framing is that they "are great for about 3 weeks and then the codebase moves," after which outdated instructions hurt more than they help.
In the demo, Dreaming opened a pull request that cleaned up the instruction file for the post-Java world — reviewed like any other diff — plus memory updates recorded as personal and team preferences. The stage version understates the mechanism, so here is the documented one:
| Dream type | What it maintains | How changes land |
|---|---|---|
| Personal memory curation | Your preferences, from your agent conversations | Memories added/updated/removed automatically |
| Repository customization | Repo-scoped memories, skills, instruction files | Proposed in a pull request; files unchanged until merged |
| Code review customization | Recurring accepted review feedback → review guidance | Internal review guidance, no PR |
Availability is where the stage was silent: Dreaming is in public preview and opt-in. Individuals enable personal curation in settings and repository dreams per repository; organisations and enterprises enable it through Copilot policies, with enterprise admins able to delegate that choice downward. Dream runs consume AI credits.
Dreaming is one third of what GitHub calls GitHub intelligence, the "context and learning layer" built on the graph of GitHub data. The other two:
- Memory — now generally available on paid plans, remembering preferences and repo conventions across the app, CLI, VS Code, cloud agent, code review, Slack, Teams and Mobile. GitHub's own preview telemetry: among Copilot CLI sessions where memory was used, 93% showed better adherence to developer preferences and 42% showed more efficient workflows. Vendor-reported, not independently audited.
- Code search beyond your checkout — exact, symbol, regex and semantic search across related repos, surfaced through
/research. The example given is tracing how retries for failed payments are implemented across a payments service, a shared library and background workers before changing anything.
📁 Copilot Projects: One Goal, Many Repos 15:20
Burke Holland (Principal Cloud Advocate, Microsoft) demoed Projects on a Surface Laptop borrowed from Parikh, with four coffee-shop repositories attached as context. The pattern is worth internalising, because it is where orchestration beats chat:
- Set a goal, not a prompt — "customers can reorder their usual with one tap," plus design mocks, a Slack thread and notes from the legal/compliance call, each attached as context rather than pasted as text.
- Fire and steer — Holland keeps sending follow-ups while agents work. He is not steering a single loop; he is talking to an orchestrator that spins up sub-agents per request while keeping project-wide context.
- Agents run locally or in the cloud — "we can shut the laptop and move on." Requested PRs appear in the project overview as agents finish.
- Artifacts beyond code — a library of pixel-perfect demo videos, generated by Copilot from a skill, so marketing has material before the code ships. An automation regenerates them daily when a new feature lands.
The demo peaked at eight agents working a single project. The most quotable line of the hour is the reason the feature exists: "nobody likes micromanaging agents."
⚙️ Automations as a Squad of Specialists 22:58
Damian Brady (Staff Developer Advocate) took over for the quality-and-security half, starting with a bug: the "order ahead" feature stops taking orders before a café closes and the site never says so. He starts the fix from his phone, the session spins up in a cloud sandbox, and he picks it up in VS Code — the session-continuity pitch in one motion.
Then the real idea. Rather than clicking "create issue" or "fix with Copilot" on a Sentry alert, he shows Copilot Automations: AI-powered workflows that run in the cloud, triggered manually, on a schedule, by an event, or — new — through the REST API so external systems (Jira, Sentry, PagerDuty) can fire them.
| What's new in Automations (Oct 28, 2026) | Detail |
|---|---|
| Triggers | API triggers + 24 new GitHub events across issues, PRs, discussions and security alerts (including merge conflict, review dismissed, review thread resolved, code scanning alert created) |
| Chaining | Automations can trigger other automations, via "Can be triggered by: Users and Copilot" or run-succeeded/run-failed triggers |
| Tools | 20 new GitHub tools (attachments, retry workflows, merge PRs, comment updates, hide/unhide, discussions) plus tools from custom MCP servers |
| Permissions | Per-automation tool allowlist — e.g. can create PRs, cannot merge them |
| Cost controls | AI-credit limits per run, day, week and month |
| Self-improvement | Automations learn from outcomes and propose changes to their own prompts — reviewed and approved by you before applying |
The architecture insight is in Brady's second repository, where a chain of specialist automations does one job each: watch signals and create issues → triage → reproduce with screenshots → fix → verify the fix against the original request. That is the "squad of agents" idea expressed as composable triggers rather than a monolith — and it is only auditable because each hop is a separate, reviewable workflow with its own caps.
The self-improvement loop is the glossed-over part. It works off implicit signals already on GitHub: did people change the labels the triage automation applied, accept its review comments, merge its PRs. A weekly "improvement automation" analyses those signals and proposes prompt/tool/trigger refinements. Human approval stays in the loop — but note what is being optimised: acceptance, not correctness. An automation can learn to be agreeable.
🛡️ Security at Agent Speed 25:01
Brady's security sequence is short but contains the most interesting technical demo of the hour, because it is the only one where a feature blocks something in real time.
Push protection that doesn't need a pattern
He commits a secret locally and pushes. AI push protection catches it before it reaches the repository, with no pattern supplied in advance — built with Microsoft Applied Sciences, a classifier that reads how a candidate secret is used in surrounding code and blocks changes whose format matches nothing known.
The documented status: public preview, off by default, and only available where both push protection and AI-detected secret scans are already enabled. Early results are striking — the classifier "more than doubled the number of pushes where push protection caught a secret," with user-reported precision rivalling issuer-defined detectors. Two caveats the stage skipped: it consumes AI credits, and agents must be authorised before bypassing a block.
Scanning what CodeQL can't see
- Code scanning for AI applications (public preview, GHAS licence, github.com only) — detects agent-specific risks including indirect prompt injection (OWASP's top LLM risk), sensitive information disclosure and excessive agency, and flags agent code paths where untrusted content can reach a model holding tool or data access, with mitigation guidance posted in the PR.
- AI Scan for repositories (public preview) — an agentic scanner that explores the whole repo on the default branch within a fixed time budget, covers languages CodeQL doesn't, and skips findings CodeQL already reports. Alerts land in the same code-scanning backlog and can be fixed with agentic autofix. Billed as Code Security AI credits; no Copilot licence required.
- Agentic autofix on an existing finding — vulnerability context handed to the agent, output is a PR with a suggested fix.
The framing that deserves a mention: adding agents to your codebase has created a new class of architecture risk — untrusted input reaching a tool-holding model — and that risk is invisible to rule-based analysis because it is a dataflow property of agent wiring, not a code smell. Code scanning for AI applications is the first mainstream product to treat "how your agent is wired" as a security surface.
✅ Review: Max, Stacked PRs, Agent Merge 26:37
The problem statement is arithmetic: more agents → more PRs → more reviews than humans can read. Parikh's number for Copilot code review is 200 million findings surfaced since launch last year, and today's addition is depth.
Copilot code review Max runs several independent review agents across models from different providers, then an aggregation agent reconciles findings, resolves disagreements and double-checks accuracy. It joins Lite and Balanced as a third effort level. GitHub claims Max "posted the highest F1 score on ReviewBench for high-severity issues."
| Capability | Status (changelog) | Notes |
|---|---|---|
| Code review Max | Public preview | Slower, more AI credits; settable per PR, repo, org or enterprise, with an admin-set maximum |
| Copilot approvals | GA | Approval counts toward required approvals; dismissed on new commits; off by default; admins can scope which file paths Copilot may approve |
| Stacked pull requests | Shown live | UI change → endpoint → data change, mergeable together or one at a time |
| Agent Merge | Now on github.com | "Watch and fix": fixes failing Actions workflows and merge conflicts in a cloud dev environment; combines with auto-merge |
The stack of features is really one workflow: an agent opens a PR, Copilot reviews it as a peer reviewer (27:17), Agent Merge keeps it green while it waits (28:48), and auto-merge lands it when checks pass. Brady's justification for trusting the last step is the honest one: "because we have all of that security and code quality process in place" — automation at the merge gate is only as safe as the gates above it.
Also worth watching: Copilot as an approver changes what a review queue means. When approvals are on and Copilot has signed off, a human review is no longer the binding constraint — the binding constraint becomes whether you configured the paths Copilot may approve correctly.
💰 Enterprise: Copilot Included 30:38
The commercial announcement is delivered in one line: GitHub Enterprise customers can use all Copilot features without a separate subscription, paying only for AI credits. It got the loudest applause of the keynote, and it is the change with the most procurement consequences.
| Question | Answer (changelog, Oct 28) |
|---|---|
| Who can get it now? | Enterprises working with a GitHub or Microsoft account team — sales-assisted, GitHub Enterprise Cloud |
| Self-serve? | Not yet: "opening to self-serve customers in stages"; current subscriptions unaffected |
| Users without an Enterprise licence? | Copilot Standalone at $10/user/month |
| Included AI credits? | No monthly AI credits per seat — usage is metered from the first request against the enterprise budget |
| What still works with zero budget? | Code completion and next edit suggestions; Chat, code review and Copilot in the cloud need budget. An exhausted budget never removes the seat. |
| Existing plans? | Copilot Business and Copilot Enterprise remain available to buy |
Read past the headline and the model is a shift from seat-counting to consumption management: one pool, one budget, policies and alerts you probably already have. It removes the "how many seats?" negotiation and replaces it with "what is our monthly AI budget, and who can spend it?" — which is why the cost-control features in Automations (per run/day/week/month credit caps) ship in the same release.
🏗️ Rebuilding Git for Agents 31:25
Parikh acknowledges the year's reliability problems directly — "there are times this year when we struggled with these things… that's not meant to be an excuse, we will and we must do better" — and then spends nine minutes on why the fix is architectural rather than more servers.
Capacity added so far this year
| Resource | Added |
|---|---|
| CPU cores | 4 million |
| High-speed storage | 160 PB |
| Network capacity | 50 Tb/s |
| Azure migration | Multi-region deployment, expected complete early next year |
Why Git became the bottleneck
April Leonard (VP of Engineering) supplies the mechanism, and her quote is the best engineering line of the day: "my agents complained about the traffic. I had to tell them: you're not in traffic, you are traffic."
- September 2026: 7.38 billion commits, more than 5× a year earlier. Pushes grew 4.9× year over year, from 0.69B to 3.35B per month.
- An agent in a tight loop commits after nearly every action, so per-push latency becomes the agent's speed limit — milliseconds a human never notices are a throughput ceiling for a fleet.
- Trunk-based development, release trains and merge queues funnel all of it onto one ref, and each push multiplies into thousands of reads from CI and code scanning.
- The old write path used a three-phase commit with a quorum where every replica participated in every write — so a push was only as fast as its slowest replica.
The fix, in three principles
| Principle | Implementation | Effect |
|---|---|---|
| Simplify the primitives | Reference updates are the only thing that truly needs agreement | Shrinks the critical path of a push |
| Decouple storage from compute | Authoritative data in Azure Blob Storage; read-serving caching servers stay ephemeral and scale with demand | Capacity added without touching the write path |
| Minimize coordination | Per-reference serialisation — lock only the branch being updated, not the repository — with a specialised replicated log for the small reference transaction | Agents on different branches write in parallel (3–4× throughput before the architecture change) |
The result, verified across the engineering post and the keynote: 5,000 agent processes ("the 5,000 angriest coding agents," Parikh says) were pointed at one monorepo and sustained 7,200 writes per second — about 180× the previous ceiling of dozens of pushes a second on a single repository. On reads, GitHub's own load-testing harness hit its limits before the new architecture did.
Then a detail that separates a demo from a migration: for roughly 100 of the busiest repositories, even 25 milliseconds between data centres mattered, so those were handled first; nearly every repository has already moved to Azure. Everyone should be on the new architecture by early next year.
The real-traffic check came from OpenClaw, one of the busiest open-source projects on GitHub (~393K stars, MIT), and its creator Peter Steinberger: "GitHub changed how the git objects are stored and it'll affect us in a way that our agents will be able to operate much much faster… Many times our agents do silly things like polling CI." The next step he points at — GitHub telling you when something is ready instead of you polling — is a platform primitive, not a Git one.
The closing infrastructure list is shorter but tells you where the other ceilings are: the AI gateway (trillions of tokens, tuned for prompt caching and latency), Actions (billions of minutes a month, with a hardened control plane and multi-cloud compute announced separately), and networking (more edge sites, quadrupled backhaul to Azure, TLS tuning for agent traffic).
⚠️ Keynote vs Changelog: Where the Stage Was Generous
Keynotes compress availability. This table is the correction sheet — every row is a line from the stage compared with the same-day changelog or docs.
| Announcement | On stage | Actual status |
|---|---|---|
| Copilot Fusion | Launched, 30% off to end of November | GA; discount is "for a limited time" with no stated end date |
| Copilot Projects | "Available to everyone" | Public preview, in the Copilot app |
| Connectors | Managed services, sign in once | Public preview, 26 services, admin policy gating |
| Copilot Dreaming | Presented as shipped behaviour | Public preview, opt-in, consumes AI credits |
| Code review Max | "Deepest level of review yet" | Public preview; approvals are GA |
| Code review "for everyone, no subscription" | Stated on stage | Not in the Oct 28 entries — unverified |
| Enterprise inclusion | "Starting today" | Sales-assisted today; self-serve "in stages" |
| AI push protection | Demoed as protection by default | Off by default, public preview, requires two prerequisites |
| Memory | Implied by Dreaming | GA on paid plans |
| New Git architecture | 7,200 writes/s benchmark | Real, with full migration "early next year" |
None of these is a scandal — public previews are how platform features ship now. But the practical difference between "available" and "public preview" is whether you can put it in a compliance-reviewed workflow on Monday, and that difference is exactly what a keynote compresses away.
🧾 Claims Checked
| Claim | Verdict | Source |
|---|---|---|
| 225M developers; 17.9B pushes; 34.3B commits; 1.3B merged PRs | ✅ Verified | Octoverse 2026 post |
| 2.5 billion public contributions | ✅ Verified (2.5B, up from 1.12B) | Octoverse 2026 post |
| 566M public/open-source repos, +30% YoY | ⚠️ Not found in the Octoverse post | — |
| Fusion Max scored 60, within 2 points of Opus 5.5 Max, half cost, 40% less time | ✅ Verified as GitHub's own claim | Fusion changelog; blog post |
| Fusion's three patterns (single, cascade, critique) and three effort levels | ✅ Verified | Fusion changelog + docs |
| Code review surfaced 200M findings since launch | ⚠️ Speaker-reported; not in the changelog text reviewed | Keynote |
| Max posted the highest F1 on ReviewBench for high-severity issues | ✅ As stated by GitHub; not independently re-run | Blog post + changelog |
| Memory improved preference adherence in 93% of CLI sessions | ⚠️ Vendor-reported preview telemetry | GitHub intelligence changelog |
| Git: 7,200 writes/s with 5,000 agents, ~180× previous ceiling | ✅ Verified | Keynote + Git infrastructure post |
| September 2026: 7 billion commits | ✅ Actually 7.38B, more than 5× YoY | Git infrastructure post |
| Pushes grew 4.9× YoY (0.69B → 3.35B/month) | ✅ Verified | Git infrastructure post |
| 4M CPU cores, 160 PB storage, 50 Tb/s network added | ✅ Verified | GitHub blog post |
| Enterprise: Copilot included, no separate subscription | ✅ With the sales-assisted caveat | Enterprise changelog |
| Peter Steinberger / OpenClaw | ✅ Verified (transcript rendered it "Peter Steinberg") | github.com/openclaw/openclaw |
| OpenQuake Engine / Global Earthquake Model Foundation | ✅ Verified (AGPL-3.0, 465 stars) | github.com/gem/oq-engine |
🔑 Key Takeaways
- The unit of work moved from the file to the fleet. Every announcement assumes dozens of concurrent agent sessions per developer; the keynote's own numbers (40% of PRs agent-started in September) say that is already the median workflow, not the future one.
- Fusion sells waste reduction, not peak quality. Within two points of Opus 5.5 Max at about half the cost and 40% less time is a routing win; billing per model at standard rates means the guarantee is about averages, not ceilings.
- Memory + Dreaming + Code Search is the layer above the model. None of these is a better LLM; all three attack rediscovery, drift and single-repo blindness. That is where durable product value sits when models are commodities.
- Dreaming is opt-in and credits-metered, and it edits your repo through PRs. Personal memories change automatically; checked-in instructions only change when you merge. Treat the PR as a real review gate.
- Connectors collapse MCP setup to one sign-in across 26 services. It is public preview, admin-gated, and the largest reduction in agent-context friction announced this year.
- Automations are the composition primitive. API triggers, chaining, MCP tools, per-tool permissions and credit caps turn "agents" into auditable multi-step pipelines where each hop is separately reviewable.
- Security moved into the push path. A context-aware classifier that blocks secrets with no known pattern, and code scanning that flags prompt injection and excessive agency, are the first mainstream products treating agent wiring as a security surface.
- Copilot as approver changes the review bottleneck. With approvals GA, the binding constraint becomes how well you scoped the paths Copilot is allowed to approve.
- Enterprise Copilot is now a budget conversation, not a seat-count conversation. No included credits, metered from request one, completion survives an exhausted budget — plan the spend controls before the rollout.
- Git was the real bottleneck, and it was an architectural one. Per-reference locking, storage/compute decoupling and a replicated reference log took a ceiling of dozens of pushes per second to 7,200 — 180× — and that is the number that makes fleets of agents viable.
- Availability is the story the stage hides. Of the major announcements, only Fusion, Memory, approvals and the cloud session experience are GA; Projects, Connectors, Dreaming, code review Max, AI Scan and push protection are previews.
🔗 Resources & Links
- GitHub Universe 2026: Evolving every layer of the stack — Jay Parikh's keynote post
- Octoverse 2026: commits, pushes, reach new highs — the numbers in section one
- Building Git infrastructure for agent-scale development — the three principles and the 7.38B-commit month
- The bridge to agent-scale Git infrastructure — per-reference serialisation
- Docs: GitHub Copilot Fusion
- Changelog: Copilot Fusion GA
- Changelog: Copilot app Universe releases (Projects, computer use)
- Docs: working with Copilot Projects
- Docs: About GitHub Copilot Dreaming
- Docs: About GitHub Copilot Memory
- Changelog: GitHub intelligence (Memory, Dreaming, Code Search)
- Changelog: GitHub-verified MCP servers (connectors)
- Changelog: Automations — triggers, tools, cost controls
- Changelog: Automations learn from outcomes
- Changelog: Code review Max and approvals
- Changelog: Agent Merge
- Changelog: AI push protection
- Changelog: Code scanning for AI applications
- Changelog: AI Scan for repositories
- Changelog: Enterprise includes Copilot
- Changelog: connected Copilot cloud experience
- Changelog: Fusion local-model routing (experimental)
- GitHub Copilot app
- openclaw/openclaw — the real-traffic test partner
- gem/oq-engine — OpenQuake Engine