# GitHub adds Copilot projects and usage-based enterprise access at Universe 2026 > GitHub says Copilot projects support parallel agent work across repositories, while a new enterprise purchasing option charges for AI credits without a separate Copilot subscription. Canonical URL: https://www.devobs.io/news/news-event-15f3eabdb34a8fbb4f69b0e0/ By: Nina Patel Published: 2026-10-28T20:27:21.607Z Updated: 2026-10-28T20:27:21.607Z Event date: 2026-10-28 Section: Developer tools GitHub announced multi-repository Copilot projects and a usage-based purchasing option for GitHub Enterprise customers at Universe on October 28, 2026. In its [same-day announcement](https://github.blog/news-insights/company-news/github-universe-2026-evolving-every-layer-of-the-stack/), the company framed these changes as a move toward coordinating software delivery across agents and repositories, rather than generating code alone. ## What GitHub says is available According to GitHub, Copilot projects became available in the GitHub Copilot app on October 28. The feature supports fully managed, parallel agent sessions across multiple repositories, with a shared place to track progress and direct the work. GitHub also announced that GitHub Enterprise customers can access all Copilot features without buying a separate Copilot subscription, paying instead for the AI credits they consume. The option was available through GitHub Sales on the announcement date. Self-service access was described as “coming soon,” without a date. Existing Copilot Business and Copilot Enterprise customers can keep their current plans or switch to the new option. The company also introduced Copilot Fusion, which it says determines how to execute tasks across one or more models, and Copilot code review Max, positioned for deeper reviews. The announcement does not specify a preview or general-availability designation for either product. ## What teams should evaluate The practical question is whether parallel agent sessions help a team deliver an accepted change—not simply whether more sessions can run at once. For work spanning repositories, evaluation should include the effort needed to integrate and review the results. Before increasing concurrency, teams should define which repositories agents may access, how cross-repository changes will be validated, who approves the results and what spending threshold triggers a review. These are evaluation criteria, not a claim that the announcement establishes built-in controls for each one. For a pilot, track AI-credit spending alongside integration and review effort per accepted change. That offers a more decision-useful comparison than counting generated code alone. ## Infrastructure migration targets early 2027 In the [same announcement](https://github.blog/news-insights/company-news/github-universe-2026-evolving-every-layer-of-the-stack/), GitHub reported adding 4 million CPU cores, 160 PB of high-speed storage and 50 Tb/s of network capacity during 2026 up to that point. Separately, the company said its migration to a multi-region Azure deployment remained underway, with completion expected in early 2027. It described three principles behind its new Git architecture: simplifying primitives, separating storage from compute and minimizing coordination. The added capacity is a reported investment; the migration completion date is a target. The announcement does not provide measured reliability gains from the migration, so teams should not treat that roadmap as evidence of improved service reliability. ## Source references -