The AI Usage dataset is designed to normalise five sources onto one schema so they can be reported side by side. Four of them are available today. Cursor is specified and will start producing records once it is released.
Provider | Status |
GitHub Copilot | Available |
Claude Platform | Available |
Cursor | Coming soon |
OpenAI Platform | Available |
OpenAI Codex Enterprise | Available |
Each provider publishes a different set of measures, so a field one provider does not publish is empty on its records. The field articles say which providers populate each field, and mark Cursor as coming soon.
What GitHub Copilot publishes
Copilot's coverage is uneven in ways a reader of a dashboard will notice:
Tokens: command line and desktop app only. There are no token counts for IDE work.
Model attribution: chat only. Completions carry no model.
Repository: yes, as pull request metrics on
REPOSITORYrecords.Credits: yes, on day total records.
Code outcomes: yes - suggestions, lines of code and pull request activity.
Copilot publishes nothing at all for prompt cache tokens, explicitly rejected suggestions, commits authored by the assistant, or web searches. Those fields exist in the schema because other providers publish them, and they stay empty on GitHub Copilot records.
What the other providers add
This is what each of the other integrations contributes. Cursor is not released yet, so nothing it contributes is queryable yet.
Provider | Tokens | Model | Repository | Credits | Code outcomes |
Claude Platform | yes, including the cache split | yes | no | no | yes |
Cursor | yes | yes | no | no | yes |
OpenAI Platform | yes | yes | no | no | no |
OpenAI Codex Enterprise | none | none | no | yes | code review only |
An empty measure always means the provider does not report it. It never means zero, and averaging or summing across providers over a measure only some of them publish will understate the ones that do.
Known limitations
Each of the following is expected behaviour rather than a defect. They are listed here because each one looks like a bug the first time it is seen in a report.
Applying to GitHub Copilot:
No tokens for IDE work. GitHub publishes token counts for the Copilot command line and desktop app only, so per-developer token reporting is not possible for IDE usage. Treat it as not available rather than as zero.
Web chat and GitHub Mobile are excluded from usage metrics while still consuming credits, so Copilot usage will always understate Copilot billing.
Active user counts will be lower than GitHub's own Copilot dashboard. GitHub counts users it sees only through server-side telemetry, who by its own documentation may not appear in the per-user breakdowns these records come from.
Passive code review has no equivalent in GitHub's dashboard. GitHub counts a user with both active and passive review signals as active only. Keypup keeps both as separate records, so filtering to
surface_name = code_review_activereproduces GitHub's definition.Accepted suggestions can exceed offered suggestions. A suggestion generated one day and applied the next does exactly that, so no report should assume the ratio stays below 100% on a single day. Compute acceptance rates over a window rather than per day.
Organization records overlap across organizations. Copilot attributes organization-scoped usage by membership rather than by where the work happened, so a user belonging to three organizations is counted in all three. Organization totals must not be summed across organizations. Import Copilot at enterprise level for a total that counts each user once.
Enterprise totals differ from the sum of organization totals. GitHub deduplicates users across the enterprise's organizations and attributes activity on its own timing, so
ENTERPRISEandORGANIZATIONrecords for the same day do not add up. When both an enterprise and its organizations are imported, the same activity is present in both: filter on one aggregation level.Suggested deletions are always zero. GitHub publishes the counter but documents it as not yet implemented.
Applying to the other providers:
OpenAI Codex Enterprise reports tokens only for usage priced in US dollars, and OpenAI Platform reports no credits. The two meter differently, which is why they are two separate integrations rather than one.
OpenAI Platform sees API key usage only, and OpenAI Codex Enterprise needs ChatGPT Enterprise or Edu. Platform reports requests made with your OpenAI API keys, never ChatGPT activity. Codex Enterprise reports what your ChatGPT workspace members do in Codex, and OpenAI only offers it on Enterprise and Edu: a ChatGPT Business team can connect OpenAI Platform only. The OpenAI Platform integration article explains which one to connect.
Claude Platform sees Claude Console organizations only. Claude Team and Claude Enterprise seats are not reported, and neither is a team running Claude Code against Amazon Bedrock, Google Vertex or Microsoft Foundry, even though it is spending money. See the Claude Platform integration article.
Acceptance rates are not comparable across providers. Claude Platform reports accepted and rejected proposals but never how many were shown, so its rate must be computed as accepted over accepted plus rejected - a different denominator from Copilot's and Cursor's.
Actors are not comparable across providers. GitHub identifies a person by their login; the other providers by their name or email address. The same person therefore appears as two actors when two providers are connected, and a cross-provider count of distinct actors is too high.
One limitation applies whatever is connected: currency amounts are not in this dataset. Only metered consumption units - AI credits - are carried, in credits_used. Spend belongs to billing, not usage.