Copilot Automations go team-wide, billed to the repo owner, not the creator

GitHub is rolling out shared Copilot Automations, which let a team build and maintain cloud-run AI workflows together. According to the official changelog, a shared automation belongs to the repository, and its AI credits are billed to the repository owner.

What changes when an automation belongs to the repo

Copilot Automations combine prompts, triggers and tools into workflows that Copilot runs autonomously in the cloud, using only the tools the creator has allowed. Until now they were personal: only their author could see or edit them, and they ran on that person’s identity and AI credits. GitHub says that suits jobs like drafting standup updates but not workflows a whole team depends on.

The changelog lists the rules for the shared type:

• Visibility: everyone who can read the repository can view a shared automation, while editing is open to people with write permission.
• Billing: AI credits go to the organization or user that owns the repository, not to the person who created it.
• Identity: actions on GitHub are attributed to Copilot rather than to an individual.
• Continuity: because the automation belongs to the repository, it does not stop when its author departs. A change history shows how the tools, triggers and prompt evolved.

GitHub’s examples include reproducing a bug as soon as an issue is opened, capturing screenshots of the changes when a pull request is marked ready, and starting an investigation when a monitoring tool detects a production incident.

Who can use it, and what admins must switch on

GitHub is staging the rollout across the Pro, Pro+, Max, Business and Enterprise tiers of Copilot, and warns that availability may vary as it progresses. Once it reaches an account, a user can create one in any repository where they have write access. The option appears when creating an automation on github.com, in the GitHub Copilot app or in Visual Studio Code: pick Shared under Type. The type cannot be changed afterward, so a personal automation cannot be promoted later.

For repositories owned by an organization, an administrator must first enable the policy named “Allow use of Copilot cloud agent billed to the organization”. Without it, shared automations will not run there. The changelog gives no prices, no limits on how many automations a repository can hold, and no regional details.

The cost question sits with the repository owner

Moving billing from the author to the owner changes who watches the meter. An event-driven automation, such as one firing on every opened issue, spends credits whenever the trigger fires, and the changelog does not say how runs are metered or capped. That matters given the pricing shift GitHub announced the same day: GitHub Enterprise now includes Copilot for every licensed user, with usage metered against an enterprise budget from the first request. Under that model, a busy shared automation draws on a budget that administrators already have to manage, and our reporting noted that GitHub described usage against the budget as the main thing to manage.

The same day, GitHub also extended where agents run. VS Code cloud sessions let Copilot agents keep working after you close the laptop, and sessions can be resumed from the editor, the desktop app, GitHub Mobile, github.com or the terminal. Shared automations extend the same idea from a single developer’s session to triggers that fire without anyone present.

A different bet than xAI’s shared bots

Rivals are converging on the shared-agent model. xAI said this week that its own sales team runs on shared Grok Bots that quote and approve deals. There are differences. Those bots work under each user’s own permissions, with extra limits on sensitive actions, such as barring reps from approving their own discounts, and xAI presents them as internal tools rather than a product. GitHub’s design goes the other way on identity: actions are attributed to Copilot, which simplifies ownership but makes the audit trail less personal. The changelog does not describe how permissions are scoped beyond the allowed tools, or what review step, if any, sits between an automation and a change in the repository.

The changelog also offers no usage figures, and its claims about what automations can do are GitHub’s own and not independently verified. Teams weighing the feature will want to see how runs are billed and how many credits typical triggers consume before wiring one to a high-traffic repository.