> For the complete documentation index, see [llms.txt](https://docs.revenium.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.revenium.io/track-and-control-costs/analyze-ai-tooling-spend/github-integration.md). # GitHub Integration Connect your GitHub organization to surface PR attribution and productivity metrics alongside AI coding assistant usage in Revenium. Connecting GitHub to Revenium adds output data — shipped pull requests — to the AI Coding Dashboard. Without GitHub, the dashboard measures AI assistant activity: sessions, tokens, cost. With it, you can cross-reference that spend against what developers actually deliver, surfacing per-developer productivity metrics and attributing pull requests to AI-assisted work. ## What connecting GitHub adds Once connected, every coding assistant's tab gains four additional columns in its Value by User table. Two of the four are named for the assistant that tab covers — on the Claude Code tab, for example, they read **PRs with Claude** and **Claude Adoption**. | Column | Description | | ------------------------- | --------------------------------------------------------------------------------------------------------------------------------- | | **PRs Merged** | Total pull requests merged by this developer in the selected period, regardless of how they were authored | | **PRs with \[Assistant]** | PRs where that assistant left its attribution — on a commit or in the pull request description — matching its detection signature | | **Cost/PR** | This developer's API-equivalent estimated value divided by PRs merged — the cost side of a basic productivity ratio | | **\[Assistant] Adoption** | The share of this developer's merged PRs attributed to that assistant | These columns let you ask: are high-spend developers also shipping the most? Which developers are getting the most delivered per dollar of AI spend? Is AI adoption actually showing up as more code delivery? {% hint style="info" %} **The assistant-attributed columns can significantly undercount AI-assisted work — they never overcount.** A PR only counts toward an assistant when a matching signature for that specific assistant appears on one of its commits or in the pull request description — see [AI co-author detection patterns](#ai-co-author-detection-patterns) below. A miss happens when the AI-assisted work is both committed and opened by hand, or when that assistant's attribution is disabled. Either way, the PR is left unattributed even though AI was involved. The true AI-assisted share is usually higher than what these columns show. {% endhint %} ## Which tools support PR data PR attribution appears on every coding assistant tab: merged pull requests, pull requests with that assistant's help, cost per pull request, and adoption rate. Detection is per-assistant: each assistant is matched against its own signature (see [AI co-author detection patterns](#ai-co-author-detection-patterns) below), so a commit or pull request only counts toward the assistant whose signature it actually carries, not toward every tab at once. If an assistant leaves no mark Revenium can match on, its figure reads **Not detected** instead of a zero. That means unmeasured, not that the assistant helped with nothing. Columns appear only for assistants with attributed counts, so a tab never fills with empty cells. ## Prerequisites * A GitHub **fine-grained** personal access token with these read-only permissions: * **Repository permissions:** Pull requests, Metadata (auto-selected by GitHub) * **Organization permissions:** Members * Developer email addresses in Revenium must match the email addresses on their GitHub commits for per-developer attribution to work The connect screen provides a link that pre-selects these permissions for you. If your organization requires administrator approval for fine-grained tokens, the token will stay pending until an owner approves it. {% hint style="info" %} Classic personal access tokens are also accepted, using the `repo` and `read:org` scopes. Those scopes are considerably broader than Revenium needs, since `repo` grants write access to all repository content, and classic tokens are not subject to your organization's token approval policy or lifetime limits. We recommend a fine-grained token wherever possible. {% endhint %} ## Setting up the integration GitHub is managed under **Connections → Integrations** in the product, on the same tab as the [Slack](/integrations/slack.md) integration. Connect with a GitHub personal access token carrying the permissions listed in [Prerequisites](#prerequisites) above. The connection screen shows the last successful validation timestamp and offers a **Sync now** action; data refreshes on its natural cadence otherwise. Either integration on the tab can be reconfigured or disconnected without affecting the other. ### Connecting multiple organizations You can connect more than one GitHub organization to a single Revenium account. Add each organization from the GitHub connect modal; each connection carries its own credential, and PR attribution is drawn from every connected organization. This suits teams whose code is split across separate GitHub organizations rather than concentrated in one. ### Choosing repositories with the repo picker When you connect an organization, the connect modal presents a **repository picker** listing the repositories the connection can access, so you can select exactly which repositories to track instead of scanning everything. The picker refetches its list when you switch organizations, so it always reflects the repositories available in the organization you're currently configuring. ## Configuring the integration Open the GitHub settings dialog from the integrations page to refine repository scope and detection patterns. ### Allowed repositories You can also scope scanning to specific repositories through the **Allowed repos** field, listing them one per line in `owner/repo` format: ``` myorg/backend-api myorg/mobile-app ``` Leave this field empty to scan all repositories available to the connection. ### AI co-author detection patterns Revenium identifies AI-assisted pull requests by scanning the attribution an assistant leaves on a merged PR — the Co-Authored-By trailer and author email on its commits, and the marker in the pull request description — against that assistant's own detection signature. A PR is attributed to an assistant when **any** of those signals matches **any** pattern in that assistant's signature. Matching is case-insensitive substring matching on commit messages and on the pull request description, and exact matching on email addresses. An assistant with no signature recognized reads **Not detected** on its tab rather than showing a zero. Claude Code, Cursor, and Codex CLI each ship with a built-in signature and need no configuration. Claude Code recognizes four signals automatically: * the `noreply@anthropic.com` co-author email on a commit * a `Co-Authored-By: Claude Code` trailer carrying no email address * a `Claude-Session:` trailer * commits authored by the `claude[bot]` GitHub identity Cursor and Codex CLI are each recognized by their own default co-author email. The pattern field on this settings dialog (one pattern per line, each at least 3 characters) feeds the **overall AI-assisted count**, the one that splits merged PRs into AI-assisted and human-authored. Patterns you add here extend the built-in signals behind that count and never replace them, and they add to no individual assistant's column. Use this field for a proxy address or an internal template your team wraps around AI-assisted commits, for example: ``` noreply@anthropic.com claude-proxy@yourcompany.com ``` {% hint style="info" %} This field is configured at the organization level and applies to every developer's figures, with no per-team variant. An individual assistant's own signature, the one behind its **PRs with \[Assistant]** column, is extended through the integration metadata API, keyed by assistant. The settings dialog has no field for that yet. {% endhint %} Attribution depends on Claude Code actually adding its signature to the commits it makes and the pull requests it opens, and any engineer can turn that off locally — an organization can enforce that setting centrally instead of relying on each engineer to opt in. See **Integrations → GitHub settings** in the product for how. ### Managing user mappings Most developers are mapped for you. Revenium reads the mapping GitHub already holds. People are matched to their GitHub accounts without anyone editing anything, and without relying on a public profile or on a commit email that is usually private. Connecting GitHub starts that mapping immediately rather than waiting for the overnight sync. Two things are worth knowing. The **token used to connect must be created by a GitHub organization owner for the identity list to be readable**, and the connection dialog tells you when it was not. A mapping you set by hand is never overwritten by the automatic one. If the automatic mapping cannot resolve someone, or if they commit under more than one address, you can adjust the mapping directly rather than leaving the attribution wrong. * **Edit an existing mapping** to correct which Revenium user a GitHub identity resolves to. * **Map multiple GitHub accounts to one corporate email**, so a developer who commits from more than one GitHub account still rolls up to a single person. Consolidating accounts this way keeps per-developer metrics — PRs merged, PRs with AI assistance, and cost per PR — accurate for people who work across more than one GitHub identity. ## Team filtering and PR scope The team filter on a coding assistant dashboard applies to AI completion metrics (sessions, tokens, cost). PR data is org-scoped: the PRs Merged and PRs with \[Assistant] columns always reflect the developer's activity across the entire organization (or across your allowed repositories list), not filtered by team. To limit PR scope to a specific team's repositories, add those repositories to the Allowed repos field. ## Troubleshooting **No PR data appears after connecting:** * Allow up to 15 minutes for the initial sync to complete * Confirm the token carries the permissions listed in [Prerequisites](#prerequisites) above. A token missing **Pull requests** authenticates successfully but returns no PR data * Verify the token is valid and not expired — Revenium shows validation status on the integrations page **Coding assistant-attributed PR count is lower than expected:** * A PR is attributed to an AI Coding assistant only if a matching signature appears on one of its commits or in the pull request description. This is user or organization-configurable, and not all Claude Code sessions automatically produce these — check whether those PRs carry the trailer or the description marker * Confirm the repositories containing the expected PRs are accessible to your token (or listed in Allowed repos) * Inspect the relevant repository to confirm whether the Co-Authored-By trailer or the pull request description marker appears where you expected it to count **Developer PR counts are not attributed correctly:** * The email address on the developer's GitHub commits must match the email address Revenium has on file for that user * GitHub allows per-commit email overrides — developers using a different email for AI-assisted commits will not be matched --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.revenium.io/track-and-control-costs/analyze-ai-tooling-spend/github-integration.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.