GitHub Admin UI + Billing API: Better together for smarter spend decisions

GitHub's admin UI and Billing Usage API work together to help administrators investigate and manage AI spend. The UI provides initial exploration and grouping by organization or cost center, while the API enables reusable, tailored reports for recurring questions. This combined approach allows admins to spot changes, understand them, and act with targeted budgets without broad restrictions.

As a GitHub administrator, you already have a strong place to start when somebody asks, “Why did our AI spend go up?” In Metered usage , you can see the change, choose the period, and group the data by organization or cost center. That first investigation often leads to questions that are specific to your company. Finance may want a month-end report based on its own reporting calendar. An engineering leader may want to see whether an increase is spread across a team or concentrated among a few people. Answering those questions once is useful; answering them repeatedly calls for a reusable approach. The GitHub admin UI shows you where to look and gives you the controls to respond. The Billing Usage API helps you answer the recurring questions that are specific to your company. Neither replaces the other. Together, they give administrators a practical loop: spot the change in Metered usage , understand it through a reusable API-powered view, and act with a targeted budget. That means better cost control without treating every user or team as the problem. Let’s walk through this better-together approach using a common example: AI spend starts to rise, but the reason is not yet clear. Imagine that finance notices an increase in AI spend before the next close. It could be a sign that more developers are getting value from Copilot. It could also be one workload using far more than expected. At this point, nobody knows, and a broad restriction would be premature. The GitHub administrator needs to help finance and engineering answer three practical questions: The goal is not simply to reduce a number. It is to understand the increase well enough to protect useful work while addressing anything unexpected. The admin UI is the natural place to begin because it lets you explore the data before you decide what kind of report or control you need. Open Billing and licensing Metered usage and select the relevant reporting period. This first check matters. It confirms that the increase is real, shows when it happened, and gives you a shared starting point for the conversation with finance and engineering. Fig 01: Metered usage establishes the increase and the period that needs investigation. An enterprise total tells you that spend changed, but not where to look next. Group the usage by organization to see which part of the enterprise contributed most to the increase. Fig 02: Organization grouping narrows an enterprise-wide increase to an accountable business area. Suppose the octodemo organization stands out. You now know where to continue the investigation and which leaders can add context. You do not yet know whether the spend is justified, and that distinction matters. The increase could come from successful Copilot adoption, a migration, a seasonal workload, or an automated process that needs attention. An organization can contain several teams, programs, and budgets. Grouping by cost center takes the investigation one step closer to the people who understand the work behind the spend. Fig 03: Cost-center grouping identifies the financial owner of the increase. In this scenario, octodemo-org-cc has the largest increase. In only a few clicks, the admin UI has taken us from an enterprise-wide signal to the cost center that needs a closer look. For a one-time question, this may be enough. Now imagine that finance asks for the same analysis every month, with a fixed reporting period and a ranking of spend by user. That is the point where the API adds value. It does not replace the investigation you just completed; it helps you repeat and extend it. The Billing Usage API gives you access to the data behind a more tailored report. You can use filters to match the period finance cares about, focus on the cost center you found in the UI, and build a view that can run again tomorrow or next month. Fig 04: Billing usage endpoints and time filters provide the inputs for a reusable report. Before writing code, state the question the report needs to answer. In this example, it is: Which users in the selected cost center account for the most net spend during this reporting period? That one question keeps the report focused. It also determines the workflow: The prototype uses year , month , and optional day filters so the output matches the finance period. It also accepts a cost-center filter. Because the admin UI has already pointed us to octodemo-org-cc , there is no reason to start with every member of the enterprise. There is one API behavior to understand before building the report. The organization billing endpoints return an aggregate when the user filter is omitted. To create a spend-by-user ranking, the workflow makes a filtered request for each selected user and usage type. For example, this request asks for Eve's AI credit usage in July 2026: curl -L \ -H "Accept: application/vnd.github+json" \ -H "Authorization: Bearer $GITHUB TOKEN" \ -H "X-GitHub-Api-Version: 2026-03-10" \ "https://api.github.com/organizations/octodemo/settings/billing/ai credit/usage?year=2026&month=7&user=eve" The response contains one or more usage items, with amounts such as grossAmount , discountAmount , and netAmount . The prototype adds the netAmount values to calculate Eve's AI credit total for the period. It then runs the equivalent premium-request query and combines the two totals. We can now see one user's contribution during the same period we investigated in the UI. Repeating the request for the members of the selected cost center gives us the ranking that finance asked for. For a production workflow, a few practical details matter: For a daily check, the report can use a narrow period and write a timestamped output. At finance close, the same workflow can produce the month-end rollup. The question stays the same; only the reporting window changes. The result is a custom Spend by User view that brings the organization, cost center, reporting period, AI credit usage, premium-request usage, and total net spend into one place. Fig 05: A company-specific dashboard exposes per-user concentration inside the selected cost center. In the illustrative data, the octodemo organization has 22 users and $3,651 in total net spend for July 2026. The octodemo-org-cc cost center accounts for $2,700 of that amount. Two users stand out: | User | AI credit net spend | Premium-request net spend | Total net spend | |---|---|---|---| eve | $900 | $600 | $1,500 | adam | $600 | $400 | $1,000 | Together, Adam and Eve account for $2,500 of the $2,700 attributed to that cost center. That is approximately 93% of its total in this example. These figures are demonstration data, but they show why the extra view is useful. Instead of reacting to a $2,700 cost-center total, the administrator can talk to the owners of two workloads and understand what the spend supported. Concentration does not automatically mean waste. Adam and Eve may be doing approved, high-value work. The dashboard tells the business where to ask the next question; the people involved provide the context needed to answer it. The API has helped us understand the increase, but it does not make the decision for us. Return to Billing and licensing Budgets and alerts to review the available controls and choose the narrowest one that fits what you learned. Fig 06: Budget scopes turn the investigation into a targeted governance decision. A cost-center user-level budget applies the same per-user amount to every current and future member of that cost center. This is useful when the group needs a different baseline from the rest of the enterprise. For example, the administrator might give octodemo-org-cc additional per-user headroom because its work legitimately uses more AI credits. This avoids raising the universal user-level budget for everyone. A user-level budget counts both included and paid AI credit usage. It is always a hard stop for the individual. It does not reserve part of the shared pool, and it does not replace the cost center's paid-usage budget. If Adam or Eve has an approved role that requires more capacity, an individual user-level budget can replace the cost-center baseline for that person. The exception stays limited to the person who needs it instead of increasing the budget for the whole cost center. Fig 07: Cost-center baselines and individual overrides preserve useful work without widening access for everyone. The precedence is straightforward: In practice, you can set a universal baseline, add more headroom for a cost center with a clear business need, and use individual overrides for documented exceptions. At this point, the better-together pattern becomes clear: Each surface does the job it is best suited to do. The UI makes it easy to explore and manage GitHub. The API lets you repeat a company-specific analysis without rebuilding it by hand. Used together, they give finance, engineering, and administrators the same evidence before a control changes. A useful dashboard should lead to a useful conversation. Decide who receives the report, how often they review it, and what happens when a user or cost center stands out. For example: Over time, the conversation can move from “Who spent this?” to “What outcome did this spend support, and does the current policy still fit?” When the same users repeatedly appear at the top, leaders can inspect the workload, remove waste, validate business value, or approve more capacity. When usage becomes broadly distributed, the cost-center baseline may need adjustment instead. The report makes those patterns visible over time. The story above introduces each surface when it becomes useful. This table summarizes their roles. | Surface | Primary role | Best used for | Important limitation | |---|---|---|---| Metered usage | Interactive investigation | Finding the affected period, organization, and cost center | Manual exploration is not a reusable company-specific report | Billing Usage API | Programmatic usage retrieval | Scheduled reporting, time-sliced analysis, and per-user views | Per-user attribution requires filtered requests and careful handling of pagination and failures | Custom Spend by User view | Company-specific interpretation | Ranking users and aligning usage to internal ownership | Concentration is evidence to investigate, not proof of waste | Budgets and alerts | Governance controls | Cost-center baselines and individual overrides | A broader budget cannot override a user who has reached their ULB | The practical takeaway is simple: begin with exploration, automate only the question worth repeating, and adjust policy after the data has context. That sequence keeps governance precise while preserving useful AI work.