Custom workspace-level billing reference for GitHub Copilot AI Usage

[cicorkls]

🏷️ Discussion Type

Product Feedback

💬 Feature/Topic Area

Copilot in GitHub

Body

Custom workspace-level billing reference for GitHub Copilot AI Usage

Summary

Allow GitHub Copilot clients to attach a configurable billing reference to AI usage based on the active workspace, project, repository, or solution.

The billing reference should be exposed as an additional dimension in AI Usage reporting and APIs, alongside existing dimensions such as user, model, and date.

The mechanism should work independently of where the source code is hosted and should therefore support GitHub, Azure DevOps, GitLab, internal Git servers, other source-control systems, and purely local projects.

For GitHub Enterprise Cloud customers, the billing reference could optionally be mapped to an existing GitHub Enterprise Cost Center.

Problem

In enterprise development environments, developers often work on multiple products, customer projects, organisational units, or internal initiatives during the same billing period.

User-level AI usage does not provide enough information to answer an important cost-accounting question:

Which customer, project, product, or organisational unit caused the AI consumption?

A single developer may work on several projects during the same day. As a result, attributing all AI usage only to the user makes project-based cost accounting and chargeback difficult.

This affects use cases such as:

• project-based cost accounting
• customer chargeback
• internal cost allocation
• product-level AI cost monitoring
• project budgeting
• AI consumption governance

Repository-based reporting alone would also not fully solve the problem because source code is not necessarily hosted on GitHub.

Developers may use GitHub Copilot in Visual Studio Code, Visual Studio, JetBrains IDEs, or other supported development environments while working with code hosted on:

• GitHub
• Azure DevOps
• GitLab
• internal Git servers
• other source-control systems
• local repositories
• local projects without source control

The cost-allocation context should therefore originate from the local development workspace or project context, not from the source-code hosting platform.

Proposed solution

Allow a workspace, repository, solution, or project to define a custom billing reference that the GitHub Copilot client attaches to AI usage events.

For example:

# .copilot/billing.yml

billing-reference: "engineering_customer-a_machine-control"

The billing reference should be an arbitrary organisation-defined identifier. GitHub should not prescribe a specific format or hierarchy.

For example, an organisation might use a convention such as:

<organisation-unit>_<customer>_<project>

but it could equally use a project number, numeric cost center, ERP identifier, GitHub Enterprise Cost Center ID, or another internal reference.

Expected behaviour

When a developer sends a request to GitHub Copilot:

1. The Copilot client determines the active workspace, project, repository, or solution.
2. The client checks whether a billing reference is configured.
3. If present, the billing reference is attached to the Copilot usage event.
4. GitHub stores the billing reference together with the AI usage data.
5. AI Usage reporting and APIs expose the billing reference as an additional dimension.
6. If no billing reference is configured, the existing attribution behaviour remains unchanged.

Conceptually:

VS Code / Visual Studio / JetBrains
                │
                ▼
      Active workspace/project
                │
                ▼
        .copilot/billing.yml
                │
                ▼
         Billing reference
                │
                ▼
          Copilot request
                │
                ▼
            AI Usage

AI Usage reporting

The billing reference should be available as a filter and grouping dimension in AI Usage.

For example:

Date
User
Model
Billing reference
AI credits

A report could look like:

User          Model          Billing Reference                           AI Credits
----------------------------------------------------------------------------------
developer-a   GPT-5          engineering_customer-a_machine-control      342
developer-a   Claude         engineering_customer-b_test-platform        128
developer-b   GPT-5          digital-manufacturing_internal_cmp          415

This would allow organisations to analyse AI consumption independently of individual developers.

For example, the AI Usage UI could provide:

User:              All
Model:             All
Billing reference: engineering_customer-a_machine-control
Period:            August 2026

Usage API

The billing reference should also be available through the relevant GitHub Billing or Copilot Usage APIs.

For example:

{
  "date": "2026-08-29",
  "user": "developer-a",
  "model": "GPT-5",
  "billing_reference": "engineering_customer-a_machine-control",
  "ai_credits_used": 42.73
}

This would allow organisations to integrate GitHub Copilot usage with existing:

• ERP systems
• project controlling
• cost accounting
• customer billing
• Power BI reporting
• FinOps processes

Independent of source-code hosting

An important requirement is that the feature must not depend on the repository being hosted on GitHub.

For example:

VS Code
│
├── Azure DevOps repository
│   └── engineering_customer-a_machine-control
│
├── GitLab repository
│   └── engineering_customer-b_test-platform
│
└── Local workspace
    └── digital-manufacturing_internal_cmp

All of these workspaces should be able to use the same billing-reference mechanism.

The GitHub Copilot client already operates in the local development environment and is therefore the appropriate place to determine this context.

IDE support

The feature should behave consistently across GitHub Copilot integrations, including:

• Visual Studio Code
• Visual Studio
• JetBrains IDEs
• other current and future Copilot-enabled development environments

The configuration should ideally be part of GitHub Copilot itself rather than being specific to one IDE.

Multiple repositories and workspaces

Development environments can contain multiple workspace folders or repositories.

Where possible, the billing reference should be determined based on the workspace, repository, solution, or project associated with the context used for the Copilot request.

For requests involving multiple billing references, GitHub could:

• use the active project as the primary reference,
• mark the request as multi-project,
• or fall back to a configured default billing reference.

The exact behaviour could be controlled by organisation or enterprise policy.

Enterprise governance

For managed environments, administrators should optionally be able to control how billing references are used.

Possible controls include:

• allow or disable workspace-defined billing references
• define permitted billing references
• define optional validation rules
• define default billing references
• centrally assign billing references
• prevent developers from overriding centrally managed values
• map billing references to external accounting systems
• optionally map billing references to GitHub Enterprise Cost Centers

This would allow organisations to use the feature without losing governance over cost allocation.

Optional GitHub Enterprise Cost Center integration

The proposed billing reference should not require GitHub Enterprise Cloud or GitHub Enterprise Cost Centers.

It should work as a generic AI Usage dimension.

For GitHub Enterprise Cloud customers, however, GitHub could optionally support a mapping between a billing reference and an existing Enterprise Cost Center.

Conceptually:

Billing reference
        │
        ▼
GitHub Enterprise Cost Center
        │
        ▼
Native GitHub cost allocation

This would allow the same mechanism to support both:

1. reporting and external cost allocation
2. native GitHub Enterprise billing

The Enterprise Cost Center integration should therefore be optional rather than a prerequisite.

Minimum viable implementation

The first version would not need to modify GitHub's actual billing allocation.

A useful minimum viable implementation would simply:

1. allow the Copilot client to read a billing reference from the current workspace
2. attach the value to AI usage events
3. store the value
4. expose it in AI Usage reporting
5. expose it through the Usage API

Conceptually:

Workspace
    │
    ▼
Billing reference
    │
    ▼
Copilot request
    │
    ▼
AI Usage event
    │
    ├── User
    ├── Model
    ├── AI credits
    └── Billing reference

Organisations could then implement their own chargeback and cost-allocation processes without requiring GitHub to implement the complete accounting workflow.

Why a billing reference instead of only repository reporting?

Repository-level AI Usage would already be useful, but it does not cover all enterprise scenarios.

A billing reference provides an additional abstraction layer:

Repositories / Solutions / Workspaces
                  │
                  ▼
           Billing Reference
                  │
                  ▼
        Customer / Project / Cost

Several repositories may belong to the same project:

customer-a/backend      ─┐
customer-a/frontend     ─┤
customer-a/firmware     ─┼─► engineering_customer-a_machine-control
customer-a/integration  ─┘

The source-code hosting system also becomes irrelevant.

This makes billing references better suited to project controlling and chargeback than repository names alone.

Related requests

There are already related requests for improving Copilot usage attribution:

• GitHub Community Show AI usage per Repo #203480 — Show AI usage per Repo
• GitHub Community Metered Usage Reporting for Copilot Doesn't Include Repository Information #197564 — repository information in metered Copilot usage reporting, including internal cost-management use cases
• GitHub Community How can I track my GitHub Copilot usage per repository or project? #164101 — How can I track my GitHub Copilot usage per repository or project?
• Add a command to save AI stats to a file microsoft/vscode#292307 — Add a command to save AI stats to a file

These requests address important parts of the same problem, particularly repository-level visibility.

This proposal extends the concept by introducing a custom workspace-level cost-allocation dimension that:

• is independent of repository hosting
• can group multiple repositories under one billing reference
• works with local projects
• works across IDEs
• supports organisation-specific accounting structures
• and can optionally integrate with GitHub Enterprise Cost Centers

Business value

AI consumption is increasingly becoming a measurable engineering cost, similar to:

• cloud resources
• CI/CD compute
• build infrastructure
• test infrastructure
• development environments
• other metered engineering services

As AI adoption grows, engineering organisations need to answer not only:

How much AI did this developer use?

but increasingly:

Which customer, product, organisational unit, or project generated these AI costs?

A custom billing-reference dimension in GitHub Copilot AI Usage would make this possible without coupling cost allocation to source-code hosting or requiring GitHub Enterprise Cost Centers.

[github-actions[bot]]

💬 Your Product Feedback Has Been Submitted 🎉

Thank you for taking the time to share your insights with us! Your feedback is invaluable as we build a better GitHub experience for all our users.

Here's what you can expect moving forward ⏩

• Your input will be carefully reviewed and cataloged by members of our product teams. 
  • Due to the high volume of submissions, we may not always be able to provide individual responses.
  • Rest assured, your feedback will help chart our course for product improvements.
• Other users may engage with your post, sharing their own perspectives or experiences. 
• GitHub staff may reach out for further clarification or insight. 
  • We may 'Answer' your discussion if there is a current solution, workaround, or roadmap/changelog post related to the feedback.

Where to look to see what's shipping 👀

• Read the Changelog for real-time updates on the latest GitHub features, enhancements, and calls for feedback.
• Explore our Product Roadmap, which details upcoming major releases and initiatives.

What you can do in the meantime 💻

• Upvote and comment on other user feedback Discussions that resonate with you.
• Add more information at any point! Useful details include: use cases, relevant labels, desired outcomes, and any accompanying screenshots.

As a member of the GitHub community, your participation is essential. While we can't promise that every suggestion will be implemented, we want to emphasize that your feedback is instrumental in guiding our decisions and priorities.

Thank you once again for your contribution to making GitHub even better! We're grateful for your ongoing support and collaboration in shaping the future of our platform. ⭐

[Reksy-app]

Worth spelling out why Enterprise Cost Centers cannot cover this even as a partial workaround, because it strengthens the case here rather than weakening it.

For AI credits, GitHub allocates to the cost center containing the user who triggered the usage, or failing that the organisation that granted that user's Copilot license. The precedence chain is direct user assignment, then enterprise team, then organisation. There is no repository, workspace or project dimension anywhere in that chain, so a cost center can only ever slice spend the same way user-level reporting already does.

The closest thing available today is assigning enterprise teams to cost centers, since team membership stays current automatically as people join and leave. That gets you customer-level attribution when a developer is dedicated to one customer for a whole period, and it falls apart in exactly the scenario described here, a developer touching three projects in a day.

One detail that makes that workaround worse than it first looks: cost center membership changes are not retroactive. Adding a member charges future usage to the cost center, removing one sends future usage back to the enterprise, and usage already booked cannot be reallocated. Project-based chargeback would mean moving people between teams before the work happens rather than reconciling afterwards, which is not realistic. That seems like a reasonably strong argument that the dimension has to be attached at the usage event, as proposed. More on how the allocation and precedence rules resolve: https://olumia.dev/blog/github-copilot-cost-centers