GitHub Copilot Enterprise: A Guide to Spaces and the Usage Metrics API

What Is GitHub Copilot Enterprise?

GitHub Copilot Enterprise sits at the top of GitHub’s Copilot plan hierarchy.

Compared to GitHub Copilot Business or Pro+, Enterprise focuses heavily on governance, organizational context, and measurement capabilities. It is designed for companies operating large engineering environments rather than individual developers or small teams.

Two capabilities matter most in practice:

1. Custom organizational context through Spaces
2. Organization-wide telemetry through the Usage Metrics API

Those two features shift Copilot from “smart autocomplete” into something closer to an internal AI engineering platform.

The companies getting the most value from GitHub Copilot Enterprise treat it like a key component of internal infrastructure. They configure organizational context carefully, measure adoption continuously, and adjust policies based on usage data rather than assumptions.

For a broader look at GitHub’s ecosystem, I recommend reading our Introduction to GitHub Products guide.

How Enterprise differs from Business and Pro+

GitHub Copilot Enterprise expands on the Business subscription with additional features like:

• Organization-level usage metrics
• Expanded governance controls
• Enterprise-wide policy inheritance
• Larger premium request allocations (1,000 vs 300 in the Business tier)
• Additional model access and management

Enterprise requires GitHub Enterprise Cloud in addition to the Copilot Enterprise subscription itself. This adds an additional cost per user, so make sure your organization actually needs governance, telemetry, and enterprise-level administration.

Note: Business subscribers access the Usage Metrics API at the organization level (/orgs/{org}/…). Enterprise subscribers additionally access enterprise-wide aggregate reports (/enterprises/{enterprise}/…) covering all organizations in one view.

Who GitHub Copilot Enterprise is for

GitHub Copilot Enterprise targets organizations already operating mature GitHub environments.

Typical Enterprise customers include:

• Large engineering organizations
• Regulated industries
• Multi-team platform engineering groups
• Companies with internal development standards
• Organizations requiring centralized governance

Note that this does not inherently improve Copilot’s performance. I think this distinction matters because many teams initially over-purchase. They assume Enterprise equals “better Copilot,” when the reality is that Enterprise mostly adds governance and measurement tooling.

Copilot Spaces: Custom Context for Your Organization

Copilot Spaces solve one of the biggest weaknesses in generalized AI coding assistants.

Out of the box, Copilot understands public programming knowledge reasonably well. It does not automatically understand your internal APIs, architecture decisions, coding conventions, deployment workflows, or onboarding documentation.

Spaces provide a curated organizational context that Copilot can reference during conversations and coding assistance.

In practical terms, Spaces help Copilot answer questions like:

• “How do we structure API handlers internally?”
• “What authentication library does our platform team recommend?”
• “Which deployment workflow should this microservice use?”
• “What naming conventions does our backend team follow?”

What Spaces support

Spaces support a broader range of organizational content than the older Knowledge Bases system.

Supported content types include:

• Code files
• Markdown documentation
• JSON files
• Uploaded files
• Images
• GitHub Issues
• Pull requests

Each content type contributes differently.

Code files help Copilot understand implementation patterns. Markdown files provide architecture explanations and onboarding guidance. Pull requests expose review discussions and historical engineering decisions. That combination gives Copilot better awareness of your organization’s development practices.

One subtle but important point is that Spaces are not simply vector databases attached to GitHub. They include sharing controls and organizational governance workflows designed for enterprise environments.

The Knowledge Bases sunset

GitHub sunset the older Copilot Knowledge Bases feature on November 1, 2025.

Spaces replaced Knowledge Bases with:

• Broader content support
• Better sharing controls
• Improved administration
• More flexible organization-level management

You will still find outdated documentation and blog posts referencing Knowledge Bases. Be careful when following older tutorials because many endpoints and workflows changed during the 2025 to 2026 transition period.

Creating and Configuring Copilot Spaces

From an administration perspective, Copilot Spaces are fairly straightforward to create. The challenge comes with managing dozens or hundreds of them across teams.

The structure you choose early tends to stick. I’ve seen organizations accidentally create “documentation sprawl” inside Spaces because nobody established ownership rules up front.

Anyone can create a Copilot Space, so let's test out making one in our personal repo. These steps are similar on the Enterprise level, with a few different pages.

Setting up a Space

Creating a Space generally follows this workflow:

1. Navigate to the Copilot Spaces page in your Enterprise administration area
2. Create a new Space

3. Select repositories and content sources, including MCPs and other useful tools

4. Adding sources can be done by clicking the “+ Add sources” button on the right side

5. You can choose to share the space or set up sharing settings at this stage

6. Verify Copilot can reference the content during chat interactions

A note for enterprise users: your administrator can turn off the sharing of personal Spaces. So if you are using your own account, it can affect your ability to share a Copilot Space that doesn't use the enterprise’s repositories.

After setup, administrators should test the Space with practical prompts.

For example:

How does our authentication middleware handle token refresh logic?

Or:

Show me an example of how our backend services structure database migrations.

If Copilot cannot answer accurately, the issue is usually one of:

• Missing repositories
• Poor documentation quality
• Incorrect permissions
• Insufficient indexing time

Sharing and access controls

Spaces support two main visibility models:

• Individual Spaces
• Organization-wide Spaces

Members of an enterprise can have their individual spaces managed by the larger enterprise settings. Enterprise admins can also centrally manage preview and feature availability policies. 

Private Spaces work well for experimental teams or sensitive internal initiatives. Organization-wide Spaces make sense for engineering standards, onboarding documentation, or company-wide frameworks.

One mistake I see frequently is over-centralization. A single, gigantic company-wide Space can become noisy and difficult for Copilot to use effectively.

Organizing Spaces by team or domain

There is no universally correct organizational structure.

Common patterns include one space per team, one space per product area, or shared standard spaces. Each one has a different scope and basically uses the same settings space differently.

One Space per team

Useful when engineering groups operate relatively independently.

Examples:

• Platform engineering
• Data engineering
• Mobile development

One Space per product area

Useful for organizations structured around products rather than departments.

Examples:

• Payments
• Analytics
• Infrastructure
• Customer platform

Shared standards Space

Many organizations maintain a separate shared Space for:

• Security guidelines
• Coding conventions
• Deployment workflows
• Architecture standards

In practice, hybrid approaches usually work best. Each team might get its own space, with larger standard spaces being shared amongst the teams.

The Copilot Usage Metrics API

Spaces solve the context problem. The Usage Metrics API solves the measurement problem. It replaced several older telemetry systems that GitHub retired during the 2026 API consolidation. 

Without clear measurements, organizations quickly lose visibility into whether Copilot adoption is succeeding. Leadership wants evidence that the investment improves developer workflows rather than simply adding another subscription line item.

The dashboard reached general availability in February 2026 and is accessible via your enterprise account → AI Controls → Copilot → Metrics → Copilot usage metrics in the Insights tab.

Copilot Usage Metrics Dashboard example from github.blog

What the API measures

The Usage Metrics API exposes several categories of operational telemetry.

Common metrics include:

• Active users
• Suggested lines of code vs Accepted lines of code
• IDE usage patterns
• Model usage
• Agent interactions
• Language breakdowns

This gives organizations a much more nuanced picture than simple seat counts.

A team with 100 assigned seats but only 15 active users has a very different adoption profile than one with consistent daily usage and high acceptance rates.

The 2026 API transition

GitHub retired multiple earlier telemetry APIs (User-level Feature Engagement Metrics API, Direct Data Access API, Copilot Metrics API) during the 2025 to 2026 transition period, with them fully sunset by April 2026.

These included:

• The legacy Metrics API
• Feature Engagement APIs
• Direct Data Access APIs

The newer Usage Metrics endpoints, available since February 2026, consolidated those reporting systems into a more unified model, which includes versioning these APIs in the event of breaking changes.

This matters because many older blog posts and GitHub examples still reference deprecated endpoints. Whenever you work with the Usage Metrics API, always verify the documentation against GitHub’s latest API references before building automation around it.

Querying the Usage Metrics API

Now that we understand the purpose of the usage metrics API, let’s talk about how we actually use it in practice.

Authentication and permissions

GitHub Copilot Usage Metrics endpoints generally require you to set up a few permissions for your Personal Access Token (PAT). This can be done either through the classic PAT or fine-grained PAT.

• For the classic PATs, you’ll need to have your enterprise admin provide you with the following permissions: manage_billing:copilot and read:org. 

• For the fine-grained access tokens, you will need to ensure you’re using the GitHub app user access token or installation access token with the Enterprise Copilot metrics enterprise permissions (read) permission set.

Typically, using fine-grained tokens is preferred because they reduce unnecessary permission exposure.

Organization-level endpoints

The two most common organization-level reports are:

• organization-1-day

• organization-28-day

One-day organization-level report

The one-day report works well for operational monitoring and short-term trend analysis. Historical data is available going back to October 10, 2025, and can be accessed for up to one year from the current date.

The below curl command will call the one-day report metric API and return a JSON response with download links for the usage reports. You will need to make sure to include YOUR_TOKEN for the bearer auth and to pick a DAY for the specific day you want for the report in YYYY-MM-DD format.

curl -L \
 -H "Accept: application/vnd.github+json" \
 -H "Authorization: Bearer <YOUR_TOKEN>" \
-H “X-GitHub-Api-Version: 2026-03-10” \
"https://api.github.com/enterprises/ENTERPRISE/copilot/metrics/reports/enterprise-1-day?day=DAY"

The URLs in download_links are signed and time-limited, which means they expire shortly after retrieval. Your workflow must fetch the download URL and immediately pull the file in the same run; you cannot store these URLs for later use.

The response you get might only contain download_links and report_day, but this is the full potential schema:

{
  "type": "object",
  "title": "Copilot Metrics 1 Day Report",
  "description": "Links to download the Copilot usage metrics report for an enterprise/organization for a specific day.",
  "properties": {
    "download_links": {
      "type": "array",
      "items": {
        "type": "string",
        "format": "uri"
      },
      "description": "The URLs to download the Copilot usage metrics report for the enterprise/organization for the specified day."
    },
    "report_day": {
      "type": "string",
      "format": "date",
      "description": "The day of the report in YYYY-MM-DD format."
    }
  },
  "required": [
    "download_links",
    "report_day"
  ]
}

28-day organization-level report

The 28-day report helps identify broader adoption patterns and longer-term usage changes. The commands are very similar, with a small change to use the 28-day API.

Example request:

curl -L \
 -H "Accept: application/vnd.github+json" \
 -H "Authorization: Bearer <YOUR_TOKEN>" \
-H “X-GitHub-Api-Version: 2026-03-10” \
https://api.github.com/enterprises/ENTERPRISE/copilot/metrics/reports/enterprise-28-day/latest

You will get a similar response, except there will be a  response_start_day and response_end_day.

Organization-level report structure

The JSON reports for both the organizational one-day and 28-day might look something like this:

[
  {
    "user_id": 1001,
    "user_login": "octocat",
    "day": "2026-05-14",
    "organization_id": "999",
    "team_id": 42,
    "slug": "frontend"
  },
  {
    "user_id": 1001,
    "user_login": "octocat",
    "day": "2026-05-14",
    "organization_id": "999",
    "team_id": 43,
    "slug": "backend"
  },
  {
    "user_id": 1002,
    "user_login": "hubot",
    "day": "2026-05-14",
    "organization_id": "999",
    "team_id": 42,
    "slug": "frontend"
  }
]

As you can see, this gives you a high-level overview of the users within a particular organization, their team, and their team tags. 

User-level endpoints

User-level reports provide more granular adoption visibility. This means you can understand how individuals are using Copilot at a very high level.

Common endpoints include:

• users-1-day

• users-28-day

• user-teams-1-day

These reports help administrators identify:

• Highly active users
• Low adoption teams
• Training opportunities
• Department-level usage trends

These requests are very similar to the organization-level one-day and 28-day reports; they simply point to a different API.

One-day user-level report

Example users-1-day API call:

curl -L \
  -H "Accept: application/vnd.github+json" \
  -H "Authorization: Bearer <YOUR-TOKEN>" \
  -H "X-GitHub-Api-Version: 2026-03-10" \
  "https://api.github.com/enterprises/ENTERPRISE/copilot/metrics/reports/users-1-day?day=DAY"

28-day user-level report

Example users-28-day API call:

curl -L \
  -H "Accept: application/vnd.github+json" \
  -H "Authorization: Bearer <YOUR-TOKEN>" \
  -H "X-GitHub-Api-Version: 2026-03-10" \
   https://api.github.com/enterprises/ENTERPRISE/copilot/metrics/reports/users-28-day/latest

One-day user-teams-level report

A user-teams-1-day endpoint also exists, which maps each user to their team memberships. It contains no usage metrics itself; its purpose is to serve as a join key when you want to aggregate the per-user data by team.

User-level report structure

The level of detail inside these reports is much higher, given that they point to a particular user’s usage data:

[{
  "code_acceptance_activity_count": 1,
  "code_generation_activity_count": 1,
  "day": "2025-10-01",
  "enterprise_id": "1",
  "loc_added_sum": 8,
  "loc_deleted_sum": 0,
  "loc_suggested_to_add_sum": 10,
  "loc_suggested_to_delete_sum": 0,
  "totals_by_cli": {
    "last_known_cli_version": {
      "cli_version": "1.0.8",
      "sampled_at": "2025-10-01T00:01:43.000Z"
    },
    "prompt_count": 2,
    "request_count": 2,
    "session_count": 2,
    "token_usage": {
      "avg_tokens_per_request": 4400.0,
      "output_tokens_sum": 5000,
      "prompt_tokens_sum": 3800
    }
  },
  "totals_by_feature": [{
    "code_acceptance_activity_count": 1,
    "code_generation_activity_count": 1,
    "feature": "code_completion",
    "loc_added_sum": 8,
    "loc_deleted_sum": 0,
    "loc_suggested_to_add_sum": 10,
    "loc_suggested_to_delete_sum": 0,
    "user_initiated_interaction_count": 0
  }],
  "totals_by_ide": [{
    "code_acceptance_activity_count": 1,
    "code_generation_activity_count": 1,
    "ide": "vscode",
    "last_known_ide_version": {
      "ide_version": "1.85.0",
      "sampled_at": "2025-10-01T00:00:02.000Z"
    },
    "last_known_plugin_version": {
      "plugin": "",
      "plugin_version": "",
      "sampled_at": "2025-10-01T00:00:02.000Z"
    },
    "loc_added_sum": 8,
    "loc_deleted_sum": 0,
    "loc_suggested_to_add_sum": 10,
    "loc_suggested_to_delete_sum": 0,
    "user_initiated_interaction_count": 0
  }],
  "totals_by_language_feature": [{
    "code_acceptance_activity_count": 1,
    "code_generation_activity_count": 1,
    "feature": "code_completion",
    "language": "unknown",
    "loc_added_sum": 8,
    "loc_deleted_sum": 0,
    "loc_suggested_to_add_sum": 10,
    "loc_suggested_to_delete_sum": 0
  }],
  "totals_by_language_model": [],
  "totals_by_model_feature": [],
  "used_agent": false,
  "used_chat": false,
  "used_cli": true,
  "user_id": 1,
  "user_login": "login1",
  "user_initiated_interaction_count": 0,
  "etl_id": "green",
  "day_partition": "2025-10-01",
  "entity_id_partition": 1
}]

These metrics are most valuable as team-level adoption signals. Acceptance rates and usage counts are operational signals, not developer quality measurements.

For the full potential metrics you might see, visit the GitHub usage metrics data documentation for the most up-to-date measured metrics.

The user-level reports include CLI interaction data. If your teams use Copilot through the command line, our GitHub Copilot CLI Tutorial covers setup and common workflows.

Building a Copilot Reporting Workflow

Calling the API manually is useful for experimentation and understanding the schema. To be actionable, it’s better to create an automated workflow.

The teams getting the most value from Copilot Enterprise typically build lightweight reporting pipelines that combine usage telemetry with internal engineering metrics.

Key metrics for proving ROI

Not every Copilot metric matters equally. The most useful metrics tend to include:

• Active user growth
• Acceptance rate trends
• Suggested versus retained code
• PR cycle time improvements
• IDE engagement frequency

GitHub has published benchmarks such as:

• 55% faster task completion
• 88% code retention rates

Those numbers show significant productivity improvements. Your results will vary by team and workflow, which is exactly why the Usage Metrics API exists. A backend infrastructure team may interact with Copilot differently from a frontend prototyping team.

From raw data to a team dashboard

A lightweight reporting workflow often looks like this:

1. Scheduled API call
2. Store responses in a database or spreadsheet
3. Transform data into reporting tables
4. Visualize metrics in an existing BI platform

The stack itself matters less than consistency.

Even a simple workflow using scheduled Python scripts and CSV exports can provide useful operational visibility.

Example architecture:

GitHub API

  ↓

Scheduled Python Script

  ↓

PostgreSQL / CSV / Spreadsheet

  ↓

Power BI / Tableau / Looker

Final Thoughts

GitHub Copilot Enterprise is really about building up your infrastructure for AI-ready code. Spaces provide the organizational context that makes Copilot more useful inside real engineering environments. The Usage Metrics API provides the telemetry needed to understand whether adoption is succeeding.

The organizations getting the strongest results from Copilot Enterprise tend to share a common pattern:

• They curate internal context carefully
• They monitor adoption continuously
• They treat Copilot governance seriously
• They measure outcomes instead of assuming productivity gains

That mindset matters far more than simply assigning seats.

If you want to deepen your Copilot and AI skills, I recommend taking our Software Development with GitHub Copilot course or the full AI for Software Engineering skill track.