GitHub Copilot Plans: A Complete Guide to Features and Administration Across Tiers

GitHub Copilot Plans at a Glance

GitHub offers several distinct tiers for its ecosystem. Notably, the platform will complete its rollout of usage-based billing, replacing the legacy "Premium Request Unit" (PRU) framework with GitHub AI Credits in June 2026.

Under the new system, core code completions and “Next Edit” suggestions remain unlimited and do not consume credits. 

However, advanced operations like multi-file chat, agentic workflows, long-running coding sessions, and deep code reviews will consume AI Credits based on token consumption (input, output, and cached tokens) relative to the specific model's published API rates. 

Base monthly subscription prices have remained static, but the shift alters how administrators budget for overages and monitor active usage.

Individual plans: Free, Student, Pro, and Pro+

The individual tiers differ across model access thresholds, usage limits, and experimental capabilities. For instance, while the Free tier accommodates basic exploration, Pro+ provides access to GitHub Spark, an environment tailored for building AI-assisted applications.

Currently, new registrations for GitHub’s individual paid accounts, like Pro, Pro+, and Student, are paused. Existing accounts can upgrade from Pro to Pro+, but new accounts cannot sign up until GitHub completes its transition to the new usage-based AI Credits billing system.

Business and Enterprise

Business and enterprise are where GitHub Copilot plans pivot from an IDE extension into a fully audited enterprise infrastructure asset.

GitHub Copilot Business introduces essential management features:

• Centralized seat allocation and revocation.
• Organization-wide policy baselines.
• Structural audit logs and compliance event tracking.
• Content and repository file exclusions.
• Commercial intellectual property indemnification.

GitHub Copilot Enterprise adds even more control and capability:

• Copilot Spaces: A knowledge hub feature allowing developers to prompt Copilot against internal documentation, wikis, and systemic code standards.
• Enhanced GitHub.com Chat integration.
• Hierarchical policy inheritance across child organizations.

GitHub Copilot Enterprise requires an active GitHub Enterprise Cloud subscription. Because GitHub Enterprise Cloud costs $21 per user per month and the Copilot Enterprise license is $39 per user per month, the true minimum cost is $60 per user per month for Enterprise. This does not apply to the GitHub Copilot Business tier, which can be purchased natively by organizations running on GitHub Free or GitHub Team plans.

Organizations miss out on the enterprise-level benefits like policy inheritance, but still get IP indemnity, auditing, file exclusion, and organizational policy management, so it’s a good alternative for mid-sized engineering teams.

If you're thinking about an Enterprise subscription, our GitHub Copilot Enterprise guide will show you how to use its features, such as Copilot Spaces and the new Usage Metrics API.

What Separates Individual from Business Plans

Managing data, IP indemnity, and billing are the main areas where individual and business plans greatly differ. While additional features for users are great, understanding these differences is key for someone deciding between managing a stack of personal Pro licenses and a Business subscription.

Data handling and training defaults

For teams handling proprietary systems, data privacy is usually the deciding factor between personal plans and Business subscriptions.

In April 2026, GitHub changed how interaction data collection works for individual Copilot plans. For Free, Pro, and Pro+ users, interaction data can now be used for model training by default unless the user explicitly opts out.

Let's make sure we understand the distinction between code at rest and interaction data, so we know what is used for AI training:

• Code at rest: The raw code residing in your private repository is not read or ingested into public training sets.
• Interaction data: This includes prompts, chat queries, cursor context, surrounding code blocks sent via the IDE API during active editing sessions, suggestion acceptance metrics, and feedback logs.

Business and Enterprise agreements have a strict contractual guarantee that interaction data is never used for training purposes under any circumstances. No manual user intervention is required.

For a deeper look into how data is used and how you can resolve issues in Copilot, I recommend reading our GitHub Copilot Privacy and Troubleshooting guide.

IP indemnity

GitHub Copilot Business and Enterprise include intellectual property (IP) indemnification coverage for generated code. Individual plans do not.

Practically speaking, indemnity means GitHub contractually agrees to provide legal protection under specified circumstances if the generated code creates intellectual property disputes. That does not remove all legal risk, but it does change the liability conversation for commercial software teams.

A freelancer shipping code for clients should pay attention to this. The difference between “personal productivity tool” and “organization-backed development platform” becomes very real once contracts and commercial delivery enter the picture.

Billing, seats, and the shift to AI Credits

Individual billing uses self-serve methods mapped directly to individual personal accounts. Business plans centralize billing with admin-granted seats. Also, instead of individual users interacting with independent credit buckets, the organization pools its monthly allotted AI Credits based on the number of users.

Enterprise plans provide even finer control with granular budget enforcement limits, cost-center grouping, and department-level allocations to ensure a single development team's heavy agentic workflows do not exhaust the entire corporate credit allotment.

SKUs and Privacy Considerations

Understanding the various protections for data privacy and SKUs is important. The architectural boundaries governing data flow, legal protections, and tracking across the various tiers are summarized below:

April 2026 training policy changes

The shift from an opt-in model to an opt-out framework for individual plans underscores a primary vector for compliance leakage. The interaction data payload automatically captured during an active IDE session includes:

• Detailed chat histories and prompt context.
• Multi-line code suggestions and local acceptance rates.
• Active editor cursor context, which frequently pulls adjacent file context, import statements, and variable declarations from open editor tabs.

Imagine a developer uses a personal Copilot Pro account while working inside a corporate repository. If training remains enabled, interaction data tied to that work session may enter GitHub’s training ecosystem. This scenario is a common reason organizations adopt Business plans.

Choosing the right SKU for your privacy requirements

Depending on the level of work, you may need different SKUs. 

• Solo developer/side projects: Free or Pro tiers offer maximum flexibility. Simply opt out within your personal privacy settings if working on proprietary code.
• Freelancers/contractors: The Business plan provides a defensive barrier. Client agreements often explicitly forbid data transmission to external LLM providers; a dedicated organization seat protects your contracts.
• Corporate teams with compliance mandates: The Business tier represents the standard baseline, ensuring isolation of data pipelines and enabling administrative governance.
• Regulated industries (finance, healthcare): The Enterprise tier is generally mandatory, allowing integration with specialized security configurations, strict data residency requirements, and localized fine-tuning layers.

Excluding Specific Files from Copilot

Implementing GitHub Copilot file exclusion rule sets is one of the most effective ways to defensively secure an environment. Content exclusion prevents the local IDE agent from processing specific file contents, making them completely invisible to inline completions, chat boxes, and background agentic operations. 

Note that GitHub Copilot CLI, Copilot cloud agent, and Agent mode in Copilot Chat in IDEs do not support content exclusion.

Configuring exclusion rules

Administrative teams can apply exclusion configurations at either the global Organization Settings panel or targeted individual Repository settings. You simply go into the settings for the repo or the organization by clicking on the Settings button in the top right.

Choose “Code and automation” under the Copilot settings on the sidebar. You will then fill in your exclusions under the “Paths to exclude in this repository” box like this:

# Ignore the /src/some-dir/kernel.rs file in this repository.
- "/src/some-dir/kernel.rs"

# Ignore files called secrets.json anywhere in this repository.
- "secrets.json"

# Ignore all files whose names begin with secret anywhere in this repository.
- "secret*"

# Ignore files whose names end with .cfg anywhere in this repository.
- "*.cfg"

# Ignore all files in or below the /scripts directory of this repository.
- "/scripts/**"

The organization repo level is similar, except the setting will be under “Repositories and Paths to exclude” using the following format:

REPOSITORY-REFERENCE:
  - "/PATH/TO/DIRECTORY/OR/FILE"
  - "/PATH/TO/DIRECTORY/OR/FILE"
  - …

Keeping the REPOSITORY-REFERENCE is important as part of the settings. Common configuration baselines should prioritize hard credentials, production orchestration profiles, sensitive proprietary algorithmic modules, or highly regulated compliance folders.

How exclusions apply across Copilot features

When an exclusion match occurs, the data isolation is absolute across all Copilot subsystems:

• Inline completions: Blocked from generating context inside the file or drawing context from it to populate adjacent files.
• Copilot chat/agents: The system returns a notice stating the file cannot be reviewed due to organizational policy restrictions.

Standard local IDE engines work the same. Quality-of-life tools like text parsing, internal syntax highlighting, and localized IntelliSense compile normally because the file exclusion layer applies explicitly to external Copilot telemetry streams. 

Administrators must thoroughly test path patterns using staging repositories; malformed wildcards can fail open, exposing data you intended to isolate.

Organization-Wide Policy Management

Enforcing GitHub Copilot organization policy management guarantees that corporate security is determined by the administration team instead of individual developer preferences.

Available policy settings

Organizations can control several settings for developers:

• Feature toggles: Globally activate or suppress Copilot Chat inside development environments, command-line interfaces (via the Copilot CLI), or advanced agentic code-review systems.
• Public code filter: A legal control mechanism that blocks Copilot from returning code suggestions that closely match public open-source repositories on GitHub, reducing open-source licensing compliance risks.
• Model choice restrictions: Restrict which models (e.g., specific GPT or Claude variants) developers can select, allowing you to manage latency, credit consumption, and performance. For a closer look at the models available through GitHub's platform, see this practical guide to GitHub Models.
• Custom organization instructions: Inject standard markdown policy files that append corporate coding patterns, security frameworks, and architectural paradigms to every prompt sent by your developers.

If your team is less familiar with GitHub's organization and permission model, the Intermediate GitHub Concepts course provides useful background. For engineering groups expanding into command-line tooling, see our GitHub Copilot CLI Tutorial.

Enterprise-level policy inheritance

In large-scale corporate environments, the policy engine follows a rigid hierarchical inheritance cascade: Enterprise Policy > Organization Policy > User Preferences

Enterprise administrators can choose to lock policies globally across all smaller business units, like teams, permit selective organizational overrides, or completely delegate control down the hierarchy. For instance, the enterprise might have global settings to lock down specific model usage settings.

On a team level, it might restrict the financial services division to strict public code filters while allowing an internal software R&D division more flexible experimentation.

Audit Logs

When compliance auditors need verification of your software supply chain or security teams trace a data leak, GitHub Copilot audits the record of platform modifications.

Copilot events in the audit log

The system records a comprehensive ledger of management operations, logging:

• Explicit seat assignments, revocations, and billing group changes.
• Modifications to the public code duplication filter.
• Alterations to file and directory exclusion patterns.
• Feature enablement states (e.g., turning on agentic code review modes)

The granularity depends entirely on your subscription. While Business tiers focus on organization-scoped action event streams, Enterprise accounts unlock systemic cross-organization forensic telemetry.

Searching, filtering, and exporting

Audit log streams are natively accessible through the Organization Settings panel. Administrators can query the interface using specific action qualifiers:

# Filter logs to identify who adjusted Copilot access privileges
action:copilot.cfb_seat_assignment_created

# Identify changes made to systemic exclusions within a date window
action:copilot.content_exclusion_updated created:2026-05-01..2026-05-31

Enterprise accounts support streaming these audit events directly into external Security Information and Event Management (SIEM) systems (such as Splunk or Datadog) for automated alerting and centralized immutable preservation.

Managing Copilot Seats with the REST API

Manually provisioning user seats through a UI dashboard works fine for small teams, but quickly breaks down under high-volume corporate onboarding workflows. Using the Github Copilot REST API seats endpoints allows you to treat identity and access management entirely as code.

This is one of my favorite parts of Copilot administration because it turns licensing into something engineering teams can actually automate cleanly.

Key API endpoints

Common API workflows include:

• Listing seat assignments
• Assigning seats
• Removing seats
• Retrieving usage metrics
• Reading organization Copilot settings

Authentication generally requires:

• Fine-grained personal access tokens
• GitHub App permissions
• Organization admin privileges

To access these management pathways, your integration scripts must authenticate using a Personal Access Token (PAT) with elevated admin:org scopes or execute via a authorized GitHub App with explicit organization-level Copilot management privileges. 

For a deeper look at programmatic platform integrations, I recommend taking our GitHub Foundations skill track. 

Common automation patterns

Some practical patterns include:

• Automated identity onboarding: Connecting an HR information system (like Workday or Okta) directly to GitHub via webhooks. When an engineer joins a specified team, a script fires a POST request to auto-provision their Copilot workspace.

• Inactive seat reclamation: A scheduled Cron script queries active seat utilization via the API. If a user has not interacted with Copilot for over 30 days, the script executes a DELETE command to reclaim the license, preserving the corporate credit pool.

• Financial dashboards: Pulling daily allocation and consumption telemetry to feed internal BI platforms (such as Tableau) for clear department-level cost-center cross-charging.

Example: Assigning a Copilot seat with Python

The following script demonstrates how to programmatically assign an organization seat to a specific developer using Python:

	import requests
	# Identity Configuration
TOKEN = "YOUR_ORGANIZATION_ADMIN_PAT"
ORG = "your-corporate-org"
USERNAME = "target-developer-user"

url = f"https://api.github.com/orgs/{ORG}/copilot/billing/selected_users"

headers = {
    "Authorization": f"Bearer {TOKEN}",
    "Accept": "application/vnd.github+json",
    "X-GitHub-Api-Version": "2022-11-28"
}

payload = {
    "selected_usernames": [USERNAME]
}

response = requests.post(url, json=payload, headers=headers)

if response.status_code == 201:
    print(f"Successfully allocated Copilot seat to {USERNAME}.")
else:
    print(f"Failed allocation. Status: {response.status_code}")
    print(response.json())

Final Thoughts

GitHub Copilot’s plan structure looks simple from the pricing page. Once you start managing teams, the differences become much more substantial.

Privacy boundaries, training policies, auditability, and governance controls often matter more than raw model access. That is why GitHub Copilot Business vs Enterprise discussions usually become security and operations conversations rather than purely engineering ones.

If I were advising a team today, I would start with governance requirements first:

• Do you need contractual privacy guarantees?
• Do you need audit logs?
• Do you need centralized policy management?

After that, I would optimize for usage volume and feature access.

To deepen your team's technical capabilities and prepare for official certifications, explore these advanced learning pathways:

• Software Development with GitHub Copilot Course
• AI for Software Engineering Skills Track
• The GitHub Certification Guide for Data Professionals