GitHub Copilot Review: What It Does, Pricing, and Alternatives

Draft v0.1 — 2026-05-22 KST; promoted to content_status = qa_passed after the 2026-05-22 official plans page-body read. Generated from templates/tool-page-template.md. Passed Section A of qa/adsense-seo-quality-gate.md; later source-freshness updates are recorded in the update log. Meta description (≤ 155 chars): GitHub Copilot is the AI pair-programmer for IDEs and GitHub — here is what it does, who it fits, and how it compares to Cursor and other coding assistants.

Quick verdict

Best for: developers and engineering teams already on GitHub who want AI completion, chat, and pull-request assistance inside their existing IDE and GitHub workflow.
Not ideal for: non-developers, or teams whose top requirement is a chat assistant rather than in-editor code generation.
Pricing model: freemium. Free at $0, Pro at $10/user/month, Pro+ at $39/user/month, plus Business and Enterprise on Contact Sales pricing — verified on github.com/features/copilot/plans on 2026-05-22.
Free plan: yes — Free tier includes 50 agent/chat requests and 2,000 completions per month, access to Haiku 4.5, GPT-5 mini, and other listed models, plus Copilot CLI, with no credit card required. Verified on github.com/features/copilot/plans 2026-05-22.
Last verified: 2026-05-22 (github.com/features/copilot/plans page-body read)

Source-freshness note (2026-06-13)

If you are weighing GitHub Copilot as an IDE and GitHub coding-agent workflow rather than just inline autocomplete, GitHub maintains a first-party documentation surface describing how its Copilot coding agent fits the repository and pull-request workflow (docs.github.com — "About GitHub Copilot cloud agent", read HTTP 200 on 2026-06-13 KST).

Two distinct surfaces. Per the page, the coding agent runs in a GitHub Actions–powered environment and "can research a repository, create a plan, make code changes on a branch, and optionally open a pull request," whereas "agent mode in your IDE makes autonomous edits directly in your local development environment." Match the surface to where your team actually works.
Changes flow through pull requests you review. The agent's work lands as a branch and pull request, not a direct push to your default branch: per the page, "You can review the diff, iterate, and create a pull request when you're ready." A human still reviews, tests, and approves before anything merges or ships.
Vendor evidence only. This is GitHub's own documentation of how the workflow is shaped, not an independent ranking — confirm current pricing, plan availability, and model availability on GitHub's official pricing and product pages before relying on specifics.

Source-backed freshness note drawn from GitHub's own documentation. No benchmark, ranking, price, quota, speed, model-availability, or superiority claim is made here; vendor positioning is reported as vendor evidence only.

Source-freshness note (2026-06-18)

If part of your Copilot evaluation is agentic automation running inside your own CI rather than just an in-IDE assistant, GitHub's official changelog now documents that GitHub Agentic Workflows is in public preview (github.blog changelog, "Agentic workflows no longer need a personal access token", read HTTP 200 on 2026-06-18 KST; companion entry "GitHub Agentic Workflows is now in public preview", HTTP 200 same pass). This is one more surface to weigh — separate from the in-IDE agent mode and the coding/cloud agent above.

What the workflow does, and where it runs. Per the preview entry, "With agentic workflows, you can automate reasoning-based tasks like issue triage, CI failure analysis, and documentation updates by leveraging coding agents inside GitHub Actions." Because they are implemented as Actions, the entry notes "they reuse your existing runner groups and policy constraints" — so they inherit, rather than bypass, the Actions security and access controls your org already governs.
Session/token boundary to review. Per the token entry, "You can now use GitHub Agentic Workflows with GitHub Actions's built-in GITHUB_TOKEN," which means "you no longer need to create and store a personal access token (PAT), eliminating the operational and security risks of managing long-lived PATs." For evaluation, that turns a key question into: which identity and scopes the workflow runs under, and how org billing is gated — per the entry, organization billing requires enabling the "Allow use of Copilot CLI billed to the organization" policy and adding copilot-requests: write to the workflow frontmatter permissions.
Public preview, human review still applies. This is a public-preview capability, so confirm current behavior on GitHub's official changelog and docs before relying on it, and keep the same review discipline as any agent surface: an agentic workflow's output is a proposal to review and test, not an unreviewed change. Match the surface — in-IDE agent mode, the coding/cloud agent, or an Actions-run agentic workflow — to where your team actually works and governs access.

Source-backed freshness note drawn from GitHub's own changelog. No benchmark, ranking, price, quota, speed, model-availability, or superiority claim is made here; vendor positioning is reported as vendor evidence only, and public-preview specifics are routed to GitHub's official changelog and docs.

Source-freshness note (2026-06-24)

If you are evaluating GitHub Copilot as an agent-workflow, code-review, security, and enterprise surface — and want to verify its plans yourself — a 2026-06-23 KST source gate confirms GitHub's own surfaces for doing that evaluation are reachable and stable. The Copilot product page (github.com/features/copilot, titled "GitHub Copilot · Your AI pair programmer · GitHub", HTTP 200), the plans & pricing page (github.com/features/copilot/plans, titled "GitHub Copilot · Plans & pricing · GitHub", HTTP 200), and the GitHub Changelog (github.blog/changelog, H1 "Changelog", HTTP 200) all loaded as full pages in the same pass.

Evaluate the agent, review, security, and enterprise surfaces at the source. Copilot's product page continues to surface its agent-workflow, code-review, security, and enterprise framing. Read those surfaces on GitHub's own pages and decide whether each fits how your team actually works — don't infer current capabilities from this page.
Verify plans and pricing on the plans page, not here. The plans & pricing surface remained reachable (HTTP 200). It — not this page — is where to confirm current plan names, prices, quotas, included models, and per-tier feature gating before you rely on any figure, including the ones quoted lower on this page once they are more than ~90 days old.
Track changes on the official changelog, and keep a human in the loop. New agent/workflow capabilities ship and change on GitHub's official changelog; confirm preview-vs-GA status there. Treat any Copilot output — completions, chat, or an agent's proposed changes — as a draft your team reviews, tests, and approves before it merges or ships. The vendor's positioning is not a guarantee about any specific run.

Source-backed freshness note: a 2026-06-23 KST reachability/title/H1 recheck of GitHub's own Copilot product, plans, and changelog surfaces (from the agent-workflow source gate). No price, quota, per-plan feature, model-availability, benchmark, ranking, speed, accuracy, or superiority claim is made here; volatile specifics are routed to GitHub's official pages, and vendor positioning is reported as vendor evidence only.

Buyer control and the review boundary

If you are evaluating GitHub Copilot as a buyer rather than an individual user, the deciding question is usually not "can the tool write code?" but "who stays in control of what it produces, and where does the review boundary sit?" This page makes no benchmark, ranking, or superiority claim; it only frames the control questions to ask, and routes the answers to your own repository and review practice plus GitHub's official surfaces.

Buyer control over what each surface may do. Completions, chat, agent mode, the coding/cloud agent, and (in public preview) Agentic Workflows are different surfaces with different blast radius — match each to where your team actually works, and decide which you enable and which identity and scopes they run under before you adopt. As the source-freshness notes above describe from GitHub's own documentation, agentic surfaces "reuse your existing runner groups and policy constraints" rather than bypassing them, so the controls your org already governs are the controls that apply.
Human review owns correctness. Every Copilot surface produces drafts, not finished commits. Decide in advance who reviews each change — the prompting developer, a second reviewer, or both — and treat that human review as a required step. The same caveats in Cons and caveats (subtly wrong edits, missed edge cases, insecure defaults) are why the reviewer, not the tool, owns whether a change is correct.
Repository and pull-request review boundary. As noted above from GitHub's documentation, the coding agent's work lands as a branch and a reviewable pull request, not a direct push to your default branch — "You can review the diff, iterate, and create a pull request when you're ready." Keep that output inside the same pull-request and code-review process you already use for human work, so the review boundary sits in one place rather than scattered across surfaces.
Generated-code acceptance and CI/test review before merge. Accepting a suggestion or an agent's diff is the start of review, not the end of it. Decide which checks must pass before anything merges — your existing CI, tests, security scanning, and licensing review — and set them as gates on the pull request rather than conventions. For anything touching security-sensitive code, shared infrastructure, or release-bound branches, make human approval a hard gate before merge.
How to compare against adjacent routes. The control/review boundary is a fair axis to compare tools on, not just a Copilot concern. Use the same questions when you weigh Copilot against an AI-first editor on Cursor vs GitHub Copilot, a self-hosted or data-isolation deployment on Tabnine vs GitHub Copilot, a browser-based environment on GitHub Copilot vs Replit AI, or a general reasoning-and-coding assistant on Claude vs GitHub Copilot. To browse the field by job rather than a single head-to-head, start from the AI Coding Assistants category.

Evergreen decision framing only. No price, quota, plan entitlement, model availability, benchmark, ranking, speed, accuracy, security-certification, or legal claim is made here; verify current plan inclusions and data-handling on GitHub's official pages, and confirm how each Copilot surface fits your repository and review process against your own practice.

Source-freshness note (2026-07-21): allocating, capping, and measuring Copilot cost per group

If you are an enterprise buyer or operator sizing GitHub Copilot for cost allocation and usage control — not just "can it write code?" — GitHub's July 2026 changelog documents three distinct surfaces you should evaluate as one system, because each answers a different question and none substitutes for the others. Read them on GitHub's own pages before relying on specifics; everything below is GitHub's vendor evidence, not an independent ranking, price, or quota.

Keep these three levers separate — collapsing them into "the Copilot budget" is the most common way an enterprise cost model goes wrong:

The included-credit pool — cap consumption of credits you already bought. An AI credit pool ties a cost center's included AI credits to what that group's own Copilot licenses fund. Per GitHub's changelog, "An AI credit pool keeps a cost center from using more included AI credits than its own Copilot licenses fund, so each group stays within what it paid for" (github.blog changelog, "AI credit pools for cost centers in the billing UI", read HTTP 200 on 2026-07-21 KST). The entry states the feature "is available for Copilot Business and Copilot Enterprise on GitHub Enterprise Cloud," that you "can also choose what happens at the limit: block further included usage or let it continue as additional spend if your enterprise allows overages," and that a cost center's pool can now be managed "directly in the billing UI where you create and edit cost centers" (previously it was REST-API only). The decision this lever forces: for each cost center, does reaching the pool block further included usage, or bleed into additional spend?
The metered-spend budget — cap the dollars that accrue past the pool. A cost center budget is a different control operating on a different quantity. Per the same entry, the pool "is separate from a cost center budget, which caps metered charges after the pool is exhausted. You can set both on the same cost center." So the pool governs how many included credits a group may consume; the budget governs the metered charges that start accruing once those included credits are gone. An evaluation that configures only one of the two leaves the other side of the meter ungoverned — a pool with no budget can still run up metered spend after exhaustion, and a budget with no pool never enforces the "stay within your own licenses" boundary.
The measurement surface — see what actually happened, at the level you allocate. Allocation and caps without measurement are guesswork, and two 2026-07-17 changelog entries widen what you can observe. Repository-level usage metrics are now generally available: "Two new endpoints return a per-repository report for a single day" covering "Pull requests created and merged by Copilot coding agent" and "Pull requests reviewed by Copilot code review," reachable via GET /enterprises/{enterprise}/copilot/metrics/reports/repos-1-day and the org-scoped equivalent (github.blog changelog, "Repository-level GitHub Copilot usage metrics generally available", read HTTP 200 on 2026-07-21 KST). Separately, the Copilot usage metrics API "now reports the GitHub Copilot app usage in the enterprise and organization 1-day and 28-day reports," adding daily_active_copilot_app_users and totals_by_copilot_app so that "admins can see how broadly the app is being adopted … in the same API they already use" (github.blog changelog, "GitHub Copilot app now available in the usage metrics API", read HTTP 200 on 2026-07-21 KST). Both are governed access, not open telemetry: per the repository-metrics entry, "The Copilot usage metrics policy must be enabled," and the data is reachable only by "Enterprise owners and billing managers, organization owners, and anyone with a custom organization or enterprise role that grants the View Copilot Metrics permission."

Practical evaluation checklist — map each item to your own procurement and org chart, not to a headline number:

1. Confirm plan and hosting fit first. Cost-center AI credit pools are documented for Copilot Business and Copilot Enterprise on GitHub Enterprise Cloud. If your SKU or hosting is different, do not design your cost model around this control until you have verified it applies — check the official pages, not this one. 2. Draw your cost centers before your controls. Both the pool and the budget attach to a cost center, so how you slice teams and business units decides what "stays within what it paid for" actually means. Model that boundary first; the controls only make sense once the groups are drawn. 3. Choose block-vs-overage deliberately, per group. For each cost center, decide whether hitting the included-credit pool should hard-block further included usage or spill into additional spend — and confirm your enterprise even permits overages before you assume the second option is available to that group. 4. Set the budget as a second, independent ceiling. Because the budget only caps metered charges after the pool is exhausted, treat it as a separate decision from the pool and set both where you want a firm limit on post-pool dollars. Setting one is not setting the other. 5. Turn measurement on before you need it. Enable the Copilot usage metrics policy and grant the View Copilot Metrics permission to the finance and platform owners who will reconcile spend. The repository-level and app-adoption reports are only as useful as the access you provisioned ahead of the first reconciliation. 6. Match the metric to the question. Use the repository-level 1-day reports to see where coding-agent PRs and Copilot code-review activity actually land, and the app 1-day/28-day fields (distinct active users, session/request/prompt/token totals) to gauge how broadly the app is adopted. Read adoption breadth as adoption, not as productivity, savings, or ROI — these reports measure activity, not value. 7. Reconcile allocation against measurement on a cadence. Review each group's included-credit posture (pool), its post-pool spend (budget), and its actual usage (repo metrics + app adoption) together on a recurring schedule, so a cost center that is blocking users, quietly accruing overage, or barely using its licenses surfaces as one picture rather than three disconnected screens.

Source-backed freshness note drawn from GitHub's own July 2026 changelog — three entries, each independently read HTTP 200 on 2026-07-21 KST. Vendor evidence only, not an independent ranking. No price, exact credit quota, model-availability, benchmark, speed, accuracy, ROI, security-certification, or legal claim is made here; the credit-pool/budget mechanics and metrics fields describe GitHub's documented controls as of the read, and volatile specifics — dollar amounts, credit counts, and current plan availability — remain to be confirmed on GitHub's official billing and documentation pages. As with every Copilot surface, an agent's or the app's output is a draft your team reviews before it merges or ships.

Source-freshness note (2026-07-24): governing an issue-to-code agent workflow from GitHub Issues or Linear

If your Copilot question has moved past "can it write code?" to "how much of the path from a tracked issue to merged code should an agent drive, and where do we keep the gates?", two 2026-07-23 GitHub changelog entries describe surfaces you now govern as one workflow — an agent that acts on issues, and an agent that turns issues into pull requests. Read them on GitHub's own pages before relying on specifics; everything below is GitHub's vendor evidence, not an independent ranking, and current plan eligibility is routed to the official source. Treat each control below as a decision to make deliberately, not a default to inherit. Issue-to-code control check (2026-07-24).

Intake and delegation boundary — GitHub Issues and Linear are two different jobs. These are separate entry points into an agent workflow, and conflating them is the first way governance goes wrong. On the GitHub side, agent automation controls in GitHub Issues are in public preview, and per GitHub the supported issue changes are "labels, fields, type, close, and assignees" — the agent is acting on the issue record itself (github.blog changelog, "Agent automation controls in GitHub Issues in public preview", read HTTP 200 on 2026-07-24 KST). Per the same entry these controls "work with GitHub Agentic Workflows and Copilot cloud agent automations" and are "also available through the REST and GraphQL APIs," so the boundary you set has to hold across the UI and programmatic callers alike. On the Linear side, the Copilot cloud agent for Linear is generally available, and here the agent is turning a tracked issue into code: per GitHub, when assigned a Linear issue it analyzes the contents, opens draft pull requests, works in ephemeral environments, streams progress updates, and requests pull-request reviews on completion (github.blog changelog, "Copilot cloud agent for Linear is now generally available", read HTTP 200 on 2026-07-24 KST). Decide first which intake surface you are delegating from, because the blast radius differs: an issue-field change is reversible metadata, a draft PR is proposed code.
Suggestion/review workflow versus direct application. The GitHub Issues controls give you a review dial rather than an on/off switch. Per the changelog, "every supported action records the reason behind it, whether it applies automatically or waits for review," and each action carries a confidence rating — high-confidence changes apply automatically while medium- and low-confidence ones are held as suggestions in a panel on the issue for review. You can also "prompt your automation to suggest instead of applying," so the changes wait in that panel instead of taking effect. Repository admins "configure the automation level to set the confidence threshold, controlling which changes apply automatically and which are held for review." The decision this forces: what confidence threshold does each repository set, and which categories of change (closing an issue, reassigning it) do you want held for a human even when the agent is confident?
Permission and security boundary — approvals are not a security control. Preserve this caveat exactly as GitHub states it, because it is easy to mistake the suggestion panel for an enforcement boundary. Per the GitHub Issues entry, "approvals are a workflow convenience, not a security control. They don't enforce a server-side boundary, and an agent with permission to change issues can directly apply changes rather than suggest them." In practice: the confidence threshold and the suggest-instead-of-apply setting shape the workflow, but the real limit on what an agent can do is the permission it was granted. If an agent holds permission to change issues, "suggest only" is a convention it can be configured past — so govern the underlying permission and identity (as the Agentic Workflows notes above describe, agentic surfaces "reuse your existing runner groups and policy constraints"), not just the review dial.
Repository, branch, custom-agent, and session-steering controls (Linear). For the Linear issue-to-code path, GitHub documents several levers you set before and during a run: you can pick which model Copilot uses for a task; point Copilot at a custom agent from your repository to match your team's workflows; set the base and working branch that determines where pull requests target and where commits land; and mention Copilot in a comment to give it new instructions while it works. These can be applied per issue, or across your workspace or team with Linear agent guidance. Setup itself is a governed action — per GitHub it requires "organization owner permissions in GitHub and workspace admin privileges in Linear," so standing up the integration is an admin decision on both sides, not a per-developer opt-in. Current plan eligibility for the Copilot cloud agent changes over time and is not restated here — confirm it on GitHub's official Copilot pages before you rely on it.
Human review, CI/test, and merge ownership. Neither surface removes the review boundary; both are shaped to keep it. The Linear agent opens draft pull requests and requests reviews on completion, which means its output enters the same pull-request, CI, test, and merge process you already run for human work — decide which checks are hard gates before anything merges, exactly as the Buyer control and the review boundary section frames for every Copilot surface. On the GitHub Issues side, a wrongly-applied label or a prematurely-closed issue is cheaper to reverse than merged code, but it still steers your triage and reporting, so treat the confidence threshold as a real setting a human owns. In both cases the agent proposes; a human still owns whether a change is correct and whether it ships.

Compact rollout checklist — map each item to your own repositories, org roles, and issue tracker, not to a headline:

1. Name the intake surface before the controls. Decide per team whether you are delegating issue-record actions (GitHub Issues) or issue-to-code work (Linear cloud agent) — or both — because each has a different blast radius and a different control set. Do not enable one and assume its settings cover the other. 2. Set the confidence threshold deliberately, per repository. For GitHub Issues, choose the automation level (which confidence tier applies automatically vs. waits in the panel) as an explicit repository-admin decision, and decide which change types you always hold for a human even at high confidence. 3. Govern permission, not just approval. Treat "suggest instead of apply" as a workflow convenience and confirm the real limit at the permission/identity layer — which identity and scopes the agent runs under — because, per GitHub, an agent with permission can apply changes directly regardless of the suggestion setting. 4. Fix the branch and custom-agent boundary for Linear. Set the base and working branch so agent commits land where you expect and pull requests target the branch you intend, and point Copilot at the repository custom agent that matches your workflow rather than accepting a default. 5. Keep steering auditable. Session steering happens through Linear comments and issue-level or workspace/team guidance; decide who may steer a running session and keep that instruction trail where your team can review it after the fact. 6. Confirm setup privileges and eligibility at the source. Standing up the Linear integration needs GitHub organization-owner and Linear workspace-admin privileges; verify current Copilot plan eligibility on GitHub's official pages rather than assuming it from this page. 7. Keep merge ownership on the human side. Route every draft PR the Linear agent opens through your existing review, CI, test, and merge gates, and reconcile GitHub Issues automation against your triage practice, so an agent surface never becomes the thing that decides a change is done.

Source-backed freshness note drawn from GitHub's own 2026-07-23 changelog — two entries, each read HTTP 200 on 2026-07-24 KST. Vendor evidence only, not an independent ranking. No productivity, ROI, safety, security, benchmark, ranking, price, quota, model-availability, speed, accuracy, security-certification, or superiority claim is made here; GitHub's own words are reported as vendor evidence, GitHub's caveat that approvals are not a security control is preserved verbatim, and volatile specifics — current plan eligibility for the Copilot cloud agent, and any preview-vs-GA change — remain routed to GitHub's official Copilot and changelog pages. As with every Copilot surface, an agent's output is a proposal your team reviews, tests, and approves before it merges or ships.

Agent Plugins adoption decision check (2026-08-14)

If your Copilot question has moved from "which surface generates code?" to "should we let our team install third-party skills, MCP servers, and plugins across Copilot clients — and what has to be true before we do?", GitHub's Agent Plugins 1.0 launch (published Aug 6, GitHub support generally available across VS Code, Copilot CLI, the Copilot SDK, and the Copilot app, on all Copilot plans, per GitHub's 2026-08-12 changelog entry) plus the independently-published portable specification give you enough to reason about, but not enough to skip verification. Read them on the official pages before relying on specifics; everything below is vendor and specification evidence, not an independent ranking, security review, or compatibility guarantee.

Portability is a packaging format, not a promise every client loads every part. Agent Plugins 1.0 is a portable package format — plugin.json at the root, an optional skills/ directory, and an optional mcp.json — published as an independent specification (agent-plugins.org / the agentplugins/agent-plugins-spec v1.0.0 spec), not owned by any single vendor. GitHub's support of it means Copilot clients can install and run a plugin built to that spec, and the spec itself requires that package files resolve within the plugin root with no symlink escape — a packaging-safety property, not a runtime security certification. A package satisfying the spec, and a specific client actually loading and executing every component in it, are two different facts; verify the second on GitHub's current documentation before you assume it.
Separate the portable core from Copilot's own extensions. A single plugin can package skills and MCP server configurations that are meant to travel across any conformant client, and GitHub also supports Copilot-specific extensions — custom agents, commands, rules, and hooks — that live under a com.github.copilot/ namespace inside the package. Existing non-spec Copilot plugins remain supported too. Before adoption, ask which parts of a candidate plugin are the portable core (skills, MCP config) versus Copilot-only extensions, because the portable core is the part you could reasonably expect to also work in a different Agent Plugins client, and the namespaced part is not.
Distribution and marketplace trust is a separate question from format conformance. Format conformance says a package is well-formed; it says nothing about who published it or whether you should run it. GitHub Copilot CLI installs plugins from registered marketplaces, and two are registered by default — copilot-plugins and awesome-copilot — with the ability to browse and install through commands and UI. A plugin appearing in a default marketplace, or installing cleanly, is not evidence of vetting, security review, or GitHub endorsement of its behavior; treat marketplace default-registration as a distribution convenience, not a trust signal, and evaluate each plugin's publisher and contents on their own merits before installing.
MCP servers and skills carry their own tool-permission and credential boundary. A plugin can bundle MCP server configurations, and MCP servers are how a plugin gets tool-calling and, often, credentialed access to external systems. Installability under the spec does not by itself tell you what permissions, network access, or secrets a bundled MCP server will request at runtime. Before allowing a plugin org-wide, identify every MCP server it configures, what each one can read or act on, and what credentials it needs — and route that review through the same scrutiny you'd apply to any new third-party integration with tool-calling and network access, not a lighter one just because it arrived as a "plugin."
Managed settings and MCP allowlists are two different controls — configure both. For Business and Enterprise plans, GitHub documents existing managed settings — enabledPlugins, extraKnownMarketplaces, and strictKnownMarketplaces — that govern which plugins and marketplaces an organization allows. Per GitHub, MCP server configurations still require separate MCP allowlists; enabling a plugin through the plugin-level managed settings does not itself authorize the MCP servers it bundles. An org that configures only one of the two has left the other ungoverned — a permitted plugin whose MCP servers were never allowlisted, or an allowlisted MCP server reachable through a plugin nobody vetted.
"Installable" and "portable" are not "security-approved." Nothing in the changelog, the product docs, the CLI marketplace docs, or the portable specification states or implies a security certification, a compatibility guarantee across every Copilot client and plan, or an endorsement of any specific plugin's behavior. Treat every plugin, skill, and MCP server as untrusted third-party code with tool-calling and possibly network/credential access until your own review says otherwise — the same posture this page already recommends for any Copilot agent surface's output.

A practical pilot-to-adoption checklist, mapped to your own org chart and plan, not a headline:

1. Confirm current client, plan, and policy support before piloting. Agent Plugins 1.0 support is documented as GA across VS Code, Copilot CLI, the Copilot SDK, and the Copilot app on all plans as of the 2026-08-12 read — reconfirm this on GitHub's own changelog and docs before you rely on it, since client and plan coverage change over time. 2. Inventory the plugin's contents before approval. For any candidate plugin, list its skills, its MCP servers and what each can access, and any Copilot-specific extensions under com.github.copilot/ — approve or reject each category separately rather than the plugin as one unit. 3. Vet the publisher and distribution channel, not just the package. A plugin from a default marketplace (copilot-plugins, awesome-copilot) or a third-party marketplace still needs its own publisher-trust and content review; marketplace registration is a distribution mechanism, not a vetting outcome. 4. Set enabledPlugins, extraKnownMarketplaces, and strictKnownMarketplaces deliberately. Decide as an explicit org decision which plugins and marketplaces are allowed, rather than accepting defaults, if you are on a plan where these managed settings apply. 5. Set MCP allowlists as a separate step. Because MCP configuration requires its own allowlist independent of plugin-level settings, walk through every MCP server a newly-approved plugin bundles and allowlist (or reject) each one explicitly. 6. Pilot narrow, then expand. Start with a small group and a small set of approved plugins before making any plugin available org-wide, so a bad publisher, an over-broad MCP server, or an unexpected com.github.copilot/ extension surfaces before it reaches every developer. 7. Plan for updates and revocation, not just initial install. Decide who monitors plugin updates (a new version can change what a skill or MCP server does), how you re-review an updated plugin before the update reaches users, and how you revoke a plugin or MCP server org-wide — via the managed settings and allowlists above — if a publisher's behavior or trustworthiness changes after approval. 8. Keep human review on everything the plugin's skills or MCP servers touch. As with every other Copilot surface on this page, a plugin's skill output or an MCP server's tool call is a proposal your team's existing review, CI, and merge gates evaluate — approving a plugin for installation is not the same as trusting everything it does unreviewed.

Source-backed decision framing drawn from GitHub's own 2026-08-12 changelog, official product documentation, official CLI how-to documentation, and the independently-published Agent Plugins portable specification (agent-plugins.org and the agentplugins/agent-plugins-spec v1.0.0 spec on GitHub), all read HTTP 200 on 2026-08-14 KST. No benchmark, ranking, price, quota, speed, accuracy, security-certification, universal-compatibility, or legal claim is made here. Installability and spec conformance are reported as packaging/format facts only, not as a security or trust endorsement; current client, plan, and policy support, and the trustworthiness of any specific plugin, marketplace, or MCP server, remain to be verified on GitHub's official pages and through your own review before adoption.

What is GitHub Copilot?

GitHub Copilot is an AI pair-programming assistant built by GitHub (a Microsoft company). It started as inline code completion inside supported IDEs and has expanded into a broader suite that includes:

Inline code completion in supported editors (e.g., VS Code, JetBrains IDEs, Neovim, Visual Studio).
Chat-based explanations, refactors, test generation, and Q&A about code.
GitHub-side features such as pull-request assistance, code-review aids, and CLI integrations.

The official product page lives at https://github.com/features/copilot. Copilot's feature surface has grown rapidly, and specific feature names (and which tier they live in) have changed multiple times. Treat any third-party material older than a quarter as potentially stale.

Vendor: GitHub (Microsoft)
Official homepage: https://github.com/features/copilot
Category: AI Coding Assistants

Main use cases

Use case 1 — Inline code completion in supported IDEs: suggesting the next few lines of code as you type, including boilerplate, common patterns, and repetitive transformations.
Use case 2 — Chat-based explanations and refactors: asking Copilot Chat to explain unfamiliar code, propose a refactor, write a test, or walk through a bug. The chat surface lives both inside the IDE and on GitHub itself.
Use case 3 — Pull-request assistance on GitHub: generating PR descriptions, surfacing change summaries, and assisting reviewers with context. Specific PR features and their tier requirements should be verified on the official site.

Pricing and plans

The values below were read directly from github.com/features/copilot/plans on 2026-05-22 KST. Plan names, included features, and regional availability have changed multiple times in this product, so reconfirm with the official page before quoting these numbers more than ~90 days from now.

Free — $0. 50 agent-mode or chat requests per month, 2,000 completions per month, access to a listed model set (Haiku 4.5, GPT-5 mini, and others as enumerated on the page), Copilot CLI, no credit card required.
Pro — $10/user/month. Aimed at individual developers; broader feature access than Free.
Pro+ — $39/user/month. Higher individual tier; the page enumerates additional model access and quotas beyond Pro.
Business and Enterprise — listed on the page; pricing not visible in the section read. Use these for seat management, admin controls, and enterprise data-handling commitments — confirm specifics directly with GitHub.

Supported editors listed on the same page include: Visual Studio Code, Visual Studio, Xcode, JetBrains IDEs, Neovim, Eclipse, Raycast, SQL Server Management Studio, and Zed (with Vim and Azure Data Studio also referenced in supporting text). When evaluating Copilot for an organization, also verify directly:

Which features (chat, agentic features, advanced models) are gated to which tier.
Data-handling and code-snippet retention policy per tier.
IDE coverage (which editor extensions support which features at your tier).
Regional plan availability.

Source: live page-body read of https://github.com/features/copilot/plans on 2026-05-22 KST. Business/Enterprise dollar amounts and region-specific pricing were not in scope of this fetch.

Pros

Tight integration with GitHub itself is unique to Copilot — competing tools can wrap an IDE but cannot wrap the GitHub repo, PR, and review surfaces in the same way.
Wide IDE coverage means a team does not need to switch editors to adopt it.
Multiple paid tiers map cleanly onto procurement realities (individual, team, enterprise) and an enterprise tier exists for organizations that need it.

Cons and caveats

Code-generation tools have outstanding legal questions around training-data sourcing and code license. Do not assert legal conclusions on a tool review page; consult counsel before relying on AI-generated code for license-sensitive work.
Generated code can be subtly wrong (mishandled edge cases, off-by-one, missed null checks, insecure defaults). Treat all suggestions as proposals that require human review and testing — not as finished code.
Enterprise data-handling differs by SKU. Public documentation on the official GitHub Copilot docs site is the only authoritative source on what Copilot does or does not retain for which plan.
IDE coverage and feature parity are not uniform. A feature that works in VS Code may lag in another IDE; verify at adoption time.
Adopting Copilot does not eliminate the need for code review, tests, security scanning, or licensing review. It is a productivity layer, not a guarantee of correctness.

Alternatives

Cursor — better if you want an AI-first editor (a VS Code fork built around AI workflows, multi-file edits, and codebase chat) rather than an extension layered on a general editor.
Tabnine — better if your organization requires self-hosted or private-model deployments, or strict enterprise data isolation.
Replit AI — better for browser-based development, education, hobbyist projects, and quick prototypes where the entire dev environment lives in the browser.
Claude (general assistant) — better if your top need is broader: long-context reading, design discussions, and writing, with coding as one of several tasks.

Where to compare GitHub Copilot next

If Copilot is already on your shortlist, the next question is usually "against what, and for which job?" These side-by-side pages are organized by workflow fit, not by a winner — each one walks through where one tool's shape suits a particular task better than the other, so you can follow the path that matches how your team actually works:

Cursor vs GitHub Copilot — when you are deciding between an AI-first editor built around multi-file edits and codebase chat versus an assistant layered into the IDE you already use.
Tabnine vs GitHub Copilot — when self-hosted or private-model deployment and strict code isolation are the deciding constraints rather than raw feature breadth.
GitHub Copilot vs Replit AI — when your work is browser-based, educational, or prototype-first and the whole dev environment may live in the browser.
GitHub Copilot vs Microsoft Copilot — when the question is in-editor code generation versus a Microsoft 365 assistant that appears across Word, Excel, Outlook, and Teams.
Claude vs GitHub Copilot — when you are weighing an in-editor coding assistant against a general reasoning assistant where coding is one of several jobs.
GitHub Copilot vs Gemini — when how much of your day already lives inside the Google ecosystem is part of the trade-off.
Zapier AI vs GitHub Copilot — when your job leans toward connecting apps and automating multi-step workflows rather than generating code inside an editor.

To browse the whole field rather than a single head-to-head, start from the AI Coding Assistants category. These links are decision paths, not rankings — no benchmark, price, quota, speed, or model-availability claim is made here; the comparison pages route any such specifics to the official sources.

Who should not use GitHub Copilot

Teams whose code license or compliance posture is incompatible with sending source code to third-party AI services; verify the data-handling policy of the specific Copilot SKU you would purchase before adopting.
Beginners who have not yet learned the underlying language; uncritical accept-all use of suggestions can cement subtle bugs and bad patterns.
Organizations that have already standardized on a different AI coding assistant and would only fragment workflows by adding Copilot in parallel.

Author selection rubric

Choose GitHub Copilot when at least two of these are true:

Your repos and review process already live on GitHub.
Your developers want AI assistance to appear in their existing IDE rather than in a new editor.
You can pay for and govern a paid tier with the data-handling policy you need.

Avoid GitHub Copilot when any of these are true:

Your team is on a different code host and wants an AI assistant tuned to that host's surfaces.
You require self-hosted or private-model deployment that Copilot's plans do not provide.
Your top requirement is a general-purpose chat assistant rather than in-editor code generation.

Sources

Official feature page: https://github.com/features/copilot — recorded as src-github-copilot-needs-verify in data/sources.json with access_status = ok.
Official plans page: https://github.com/features/copilot/plans — recorded as src-github-copilot-plans-2026-05-22 in data/sources.json with access_status = ok after a 2026-05-22 page-body read; this is the source for every plan, price, Free-tier quota, and editor list quoted on this page.
Official documentation: https://docs.github.com/en/copilot/concepts/agents/cloud-agent/about-cloud-agent ("About GitHub Copilot cloud agent") — recorded as src-github-copilot-coding-agent-2026-06-13 in data/sources.json with access_status = ok after a 2026-06-13 KST HTTP 200 read; source of the "Source-freshness note (2026-06-13)" section, supporting only that GitHub documents a Copilot coding/cloud agent whose changes land via a branch and reviewable pull request, distinct from in-IDE agent mode. Used as vendor evidence only; no pricing, plan, model-availability, benchmark, ranking, speed, or superiority claim is drawn from it.
Official changelog: https://github.blog/changelog/2026-06-11-agentic-workflows-no-longer-need-a-personal-access-token/ ("Agentic workflows no longer need a personal access token") with companion https://github.blog/changelog/2026-06-11-github-agentic-workflows-is-now-in-public-preview/ ("GitHub Agentic Workflows is now in public preview") — recorded as src-github-copilot-agentic-workflows-2026-06-18 in data/sources.json with access_status = ok after a 2026-06-18 KST HTTP 200 read of both; source of the "Source-freshness note (2026-06-18)" section, supporting only that GitHub documents Agentic Workflows in public preview that run as GitHub Actions (reusing existing runner groups and policy constraints), can use the built-in GITHUB_TOKEN instead of a stored PAT, and gate organization billing behind a Copilot policy plus a copilot-requests: write frontmatter permission. Used as vendor evidence only; no pricing, plan, model-availability, benchmark, ranking, speed, or superiority claim is drawn from it, and public-preview specifics are routed to GitHub's official changelog and docs.
Official source-gate reachability recheck (2026-06-23 KST): https://github.com/features/copilot ("GitHub Copilot · Your AI pair programmer · GitHub"), https://github.com/features/copilot/plans ("GitHub Copilot · Plans & pricing · GitHub"), and https://github.blog/changelog/ (H1 "Changelog") — recorded as src-github-copilot-source-gate-2026-06-24 in data/sources.json with access_status = ok after 2026-06-23 KST HTTP 200 reads in the agent-workflow source gate (data/agent-workflow-source-gate-2026-06-23-1007.json, records github_copilot_main, github_copilot_plans, github_changelog); source of the "Source-freshness note (2026-06-24)" section. Durable reachability/title/H1/marker evidence only — no price, quota, plan, model-availability, benchmark, ranking, speed, accuracy, or superiority claim is drawn from it; the 2026-05-22 page-body read remains the source of every plan/price quoted on this page.
Official changelog (2026-07-21 KST cost-controls read): https://github.blog/changelog/2026-07-20-ai-credit-pools-for-cost-centers-in-the-billing-ui/ ("AI credit pools for cost centers in the billing UI"), https://github.blog/changelog/2026-07-17-repository-level-github-copilot-usage-metrics-generally-available/ ("Repository-level GitHub Copilot usage metrics generally available"), and https://github.blog/changelog/2026-07-17-github-copilot-app-now-available-in-the-usage-metrics-api/ ("GitHub Copilot app now available in the usage metrics API") — recorded as src-github-copilot-cost-controls-metrics-2026-07-21 in data/sources.json with access_status = ok after 2026-07-21 KST HTTP 200 reads of all three; source of the "Source-freshness note (2026-07-21)" cost-allocation section. Supports only that GitHub documents (1) cost-center AI credit pools for Copilot Business/Enterprise on GitHub Enterprise Cloud that keep a cost center within the included AI credits its own licenses fund, offer block-vs-additional-spend behavior at the limit, are separate from a cost center budget that caps metered charges after the pool is exhausted, and are now manageable in the billing UI; (2) generally-available repository-level usage-metrics REST endpoints reporting per-repo, per-day Copilot coding-agent and code-review PR activity, gated behind the Copilot usage metrics policy and the View Copilot Metrics permission; and (3) the Copilot app now reported in the usage-metrics API 1-day/28-day enterprise/organization reports. Used as vendor evidence only; no price, exact credit quota, model-availability, benchmark, ranking, speed, accuracy, ROI, security-certification, or legal claim is drawn from it, and dollar amounts / credit counts / current plan availability remain routed to GitHub's official billing and docs pages.
Official changelog (2026-07-24 KST issue-to-code read): https://github.blog/changelog/2026-07-23-agent-automation-controls-in-github-issues-in-public-preview/ ("Agent automation controls in GitHub Issues in public preview") and https://github.blog/changelog/2026-07-23-copilot-cloud-agent-for-linear-is-now-generally-available/ ("Copilot cloud agent for Linear is now generally available") — recorded as src-github-copilot-issue-to-code-2026-07-24 in data/sources.json with access_status = ok after 2026-07-24 KST HTTP 200 reads of both; source of the "Source-freshness note (2026-07-24)" issue-to-code section. Supports only that GitHub documents (1) agent automation controls in GitHub Issues in public preview — supported issue changes are labels, fields, type, close, and assignees; every action records its rationale and a confidence rating; high-confidence changes apply automatically while medium/low are held as suggestions in a panel; automation can be prompted to suggest instead of apply; repository admins set a confidence threshold via the automation level; the controls work with GitHub Agentic Workflows and Copilot cloud-agent automations and are available through the REST and GraphQL APIs; and GitHub's explicit caveat that "approvals are a workflow convenience, not a security control … an agent with permission to change issues can directly apply changes rather than suggest them"; and (2) the Copilot cloud agent for Linear is generally available — model choice, a repository custom agent, base/working branch, and comment-based session steering (per issue or across a workspace/team via Linear agent guidance), setup requiring GitHub organization-owner and Linear workspace-admin privileges, and the agent opening draft pull requests, working in ephemeral environments, streaming progress, and requesting PR reviews on completion. Used as vendor evidence only; no productivity, ROI, safety, security, price, quota, model-availability, benchmark, ranking, speed, accuracy, or superiority claim is drawn from it, and current Copilot plan eligibility plus any preview-vs-GA change remain routed to GitHub's official Copilot and changelog pages.
Official changelog (2026-08-14 KST Agent Plugins 1.0 read): https://github.blog/changelog/2026-08-12-agent-plugins-1-0-in-vs-code-copilot-cli-and-the-copilot-app/ ("Agent Plugins 1.0 in VS Code, Copilot CLI, and the Copilot app") — recorded as src-github-copilot-agent-plugins-changelog-2026-08-14 in data/sources.json with access_status = ok after a 2026-08-14 KST HTTP 200 read; source of the 2026-08-14 Agent Plugins decision section together with the four sources below. Supports only that Agent Plugins 1.0 was published Aug 6 and GitHub support is generally available in VS Code, Copilot CLI, the Copilot SDK, and the Copilot app, on all Copilot plans; that a plugin can package skills and MCP servers; that existing non-spec Copilot plugins remain supported; that Copilot-specific custom agents/commands/rules/hooks can live under com.github.copilot/; and that Business/Enterprise can govern plugins using managed settings enabledPlugins, extraKnownMarketplaces, and strictKnownMarketplaces, while MCP server configurations still require separate MCP allowlists.
Official product documentation (2026-08-14 KST read): https://docs.github.com/en/copilot/concepts/agents/about-plugins ("About plugins") — recorded as src-github-copilot-about-plugins-docs-2026-08-14 in data/sources.json with access_status = ok after a 2026-08-14 KST HTTP 200 read. Supports only that plugins are installable packages that may contain custom agents, skills, hooks, MCP server configurations, and LSP server configurations, and that a plugin.json file is required. GitHub product documentation, not independent testing.
Official how-to documentation (2026-08-14 KST read): https://docs.github.com/en/copilot/how-tos/copilot-cli/customize-copilot/plugins-finding-installing ("Finding and installing plugins") — recorded as src-github-copilot-cli-plugins-howto-2026-08-14 in data/sources.json with access_status = ok after a 2026-08-14 KST HTTP 200 read. Supports only that Copilot CLI installs plugins from registered marketplaces, that two marketplaces (copilot-plugins and awesome-copilot) are registered by default, and that commands and UI exist to browse and install plugins. Not a recommendation to trust arbitrary marketplace code.
Independently-published portable specification (2026-08-14 KST read): https://agent-plugins.org/plugin-authors ("Plugin authors") and https://github.com/agentplugins/agent-plugins-spec/blob/main/spec/1.0.0.md (Agent Plugins Specification v1.0.0) — recorded as src-agent-plugins-spec-2026-08-14 in data/sources.json with access_status = ok after 2026-08-14 KST HTTP 200 reads of both. Supports only that the portable package format defines plugin.json, an optional skills/ directory, and an optional mcp.json; that package files must resolve within the plugin root with no symlink escape; and that installation, distribution, enablement, and UI are outside the portable spec itself. Vendor-neutral specification evidence, not a GitHub product claim and not a guarantee that every client loads every component or extension.

Internal links (at least 3)

Category page: /ai-coding/
Alternative tool: /tools/cursor/
Comparison pages: /compare/cursor-vs-github-copilot/, /compare/tabnine-vs-github-copilot/, /compare/github-copilot-vs-replit-ai/, /compare/github-copilot-vs-microsoft-copilot/, /compare/claude-vs-github-copilot/, /compare/github-copilot-vs-gemini/, /compare/zapier-ai-vs-github-copilot/

Disclosure

Affiliate links: none.
Sponsored content: none. GitHub and Microsoft have no relationship to this page.
Generative AI assistance: this draft was assembled with the help of an AI assistant working from the HMP source records.

Trademark notice

GitHub and Copilot are trademarks of GitHub / Microsoft. Use here is referential only and does not imply endorsement, partnership, or affiliation.

Update log

2026-08-14 (decision-content increment — evergreen; LIVE on aistackdb.com after Hermes uploaded the verified 93-entry production ZIP through the authenticated Cloudflare Dashboard and independent route/body verification; NOT a new revenue page/product): added one substantial new H2 section (the dated Agent Plugins decision section) after the "Source-freshness note (2026-07-24)" issue-to-code section and before "## What is GitHub Copilot?", carrying the exact durable natural reader-facing marker for the dated Agent Plugins decision section exactly once, as the section heading. The section answers, for a reader deciding whether to adopt portable Agent Plugins now: portability (a packaging format — plugin.json, optional skills/, optional mcp.json, symlink-escape-safe by spec) versus actual per-client capability, which a spec-conformant package does not itself guarantee; the portable core (skills, MCP config, meant to travel across conformant clients) versus Copilot-specific extensions namespaced under com.github.copilot/, plus continued support for existing non-spec Copilot plugins; distribution/marketplace trust as a question separate from format conformance (Copilot CLI's two default marketplaces, copilot-plugins and awesome-copilot, are a distribution mechanism, not a vetting outcome); the MCP/tool-permission and credential boundary a bundled MCP server carries; the split between plugin-level managed settings (enabledPlugins, extraKnownMarketplaces, strictKnownMarketplaces, Business/Enterprise) and the separately-required MCP allowlist; and an explicit statement that installability/portability is not security approval. Followed by an eight-point pilot/approval/update/revocation checklist covering client/plan/policy confirmation, plugin-content inventory, publisher/marketplace vetting, managed-settings configuration, MCP allowlisting, narrow-then-expand piloting, update/revocation ownership, and continued human review of plugin output. Evidence: 2026-08-14 KST HTTP 200 reads of five official/specification sources — https://github.blog/changelog/2026-08-12-agent-plugins-1-0-in-vs-code-copilot-cli-and-the-copilot-app/, https://docs.github.com/en/copilot/concepts/agents/about-plugins, https://docs.github.com/en/copilot/how-tos/copilot-cli/customize-copilot/plugins-finding-installing, https://agent-plugins.org/plugin-authors, and https://github.com/agentplugins/agent-plugins-spec/blob/main/spec/1.0.0.md — recorded as five sources (src-github-copilot-agent-plugins-changelog-2026-08-14, src-github-copilot-about-plugins-docs-2026-08-14, src-github-copilot-cli-plugins-howto-2026-08-14, src-agent-plugins-spec-2026-08-14, all access_status = ok) added to data/sources.json, to the github-copilot sources_used in content/content-status.json, and to five Sources bullets here. Vendor-and-specification evidence only, not an independent ranking or security review: no price, benchmark, ranking, ROI, speed, accuracy, security-certification, universal-compatibility, or legal claim was added; no ad code, Adsterra, popunder, push-notification, Smartlink/direct-link, forced-redirect, interstitial, Gumroad, UTM, affiliate, sponsored, coupon, or checkout link was added. No new internal links added (existing internal-link set already routes to /ai-coding/ and the Copilot comparison pages). data/tools.json pricing/plan data and last_verified_at unchanged (non-pricing source read); content_type/content_status stay tool_page/qa_passed; revenue inventory unchanged (18 tool + 51 comparison = 69 qa_passed pages). Verification/build/ZIP integrity performed in this session; https://aistackdb.com/tools/github-copilot/ returned HTTP 200 with marker count=1, exact canonical, no noindex, and route membership confirmed in sitemap.xml, feed.xml, feed.json, and llms.txt. Exact deployment-version evidence is kept in HMP_RUN_LOG.md only, per this project's established convention.
2026-07-24 (source-freshness/decision-content increment — evergreen, LOCAL source/content edit only, NOT a new revenue page/product and NOT a deploy): added one substantial "Source-freshness note (2026-07-24): governing an issue-to-code agent workflow from GitHub Issues or Linear" section after the "Source-freshness note (2026-07-21)" cost-controls section and before "## What is GitHub Copilot?", carrying the durable natural reader-facing marker (the dated issue-to-code control-check bold lead label) exactly once as a bold phrase, with no raw HTML anchor tag introduced — the model-host-boundary escaped-anchor lesson from the 2026-07-23 comparison-page cleanup is applied here from the start. The section is written for an engineering/platform buyer deciding how much issue-to-code autonomy to allow, and deliberately answers a different question from the 2026-07-23 /compare/github-copilot-vs-gemini/ model-host-boundary angle — it separates (a) the intake/delegation boundary (GitHub Issues agent automation controls, public preview, acting on the issue record: labels/fields/type/close/assignees, working with GitHub Agentic Workflows and Copilot cloud-agent automations and exposed via REST/GraphQL — vs. the Linear Copilot cloud agent, GA, turning an assigned issue into draft PRs in ephemeral environments), (b) the suggestion/review workflow vs. direct application (per-action rationale, high/medium/low confidence, suggestions held in a panel, admin-set confidence threshold via the automation level), (c) the permission/security boundary with GitHub's caveat preserved verbatim ("approvals are a workflow convenience, not a security control … an agent with permission to change issues can directly apply changes rather than suggest them"), (d) the repository/branch/custom-agent/session-steering controls for Linear (model choice, repo custom agent, base/working branch, comment-based steering, per-issue or workspace/team guidance, setup needing GitHub org-owner + Linear workspace-admin) with current plan eligibility routed to the official source, and (e) human review, CI/test, and merge ownership — followed by a seven-point rollout checklist. Evidence: 2026-07-24 KST HTTP 200 reads of https://github.blog/changelog/2026-07-23-agent-automation-controls-in-github-issues-in-public-preview/ and https://github.blog/changelog/2026-07-23-copilot-cloud-agent-for-linear-is-now-generally-available/, recorded as one source src-github-copilot-issue-to-code-2026-07-24 (source_type = changelog, access_status = ok) added to data/sources.json, to the github-copilot sources in data/tools.json, to the github-copilot sources_used in content/content-status.json, and to a Sources bullet here. Vendor evidence only, not an independent ranking: no productivity, ROI, safety, security, price, exact quota, model-availability, benchmark, ranking, speed, accuracy, security-certification, or legal claim was added; no Gumroad/UTM/affiliate/sponsored/coupon/checkout link added. data/tools.json pricing_summary/has_free_plan/last_verified_at and the existing May 2026 pricing data unchanged (this non-pricing source read did not touch them); content_type/content_status stay tool_page/qa_passed; revenue inventory unchanged (18 tool + 51 comparison = 69 qa_passed pages). Local-only increment; live verify/build/deploy is handled separately.
2026-07-21 (source-freshness/decision-content increment — evergreen, LOCAL source/content edit only, NOT a new revenue page/product and NOT a deploy): added one substantial "Source-freshness note (2026-07-21): allocating, capping, and measuring Copilot cost per group" section after "Buyer control and the review boundary" and before "## What is GitHub Copilot?", carrying the durable cost-controls anchor once as a single  (marker string appears exactly once in this page source). The section is written for an enterprise buyer/operator evaluating Copilot cost allocation and usage controls, and deliberately separates three levers — the included-credit AI credit pool (caps a cost center's included AI credits to what its own licenses fund, with block-vs-additional-spend behavior at the limit, now manageable in the billing UI, for Copilot Business/Enterprise on GitHub Enterprise Cloud), the cost center budget (a distinct control that caps metered charges after the pool is exhausted; both can be set on the same cost center), and the usage/adoption measurement surfaces (generally-available repository-level usage-metrics REST endpoints for per-repo/per-day coding-agent and code-review PR activity, plus the Copilot app now in the usage-metrics API 1-day/28-day reports; both gated behind the Copilot usage metrics policy and the View Copilot Metrics permission) — followed by a seven-point practical evaluation checklist. Evidence: 2026-07-21 KST HTTP 200 reads of https://github.blog/changelog/2026-07-20-ai-credit-pools-for-cost-centers-in-the-billing-ui/, https://github.blog/changelog/2026-07-17-repository-level-github-copilot-usage-metrics-generally-available/, and https://github.blog/changelog/2026-07-17-github-copilot-app-now-available-in-the-usage-metrics-api/, recorded as one source src-github-copilot-cost-controls-metrics-2026-07-21 (source_type = changelog, access_status = ok) added to data/sources.json, to the github-copilot sources in data/tools.json, to the github-copilot sources_used in content/content-status.json, and to a Sources bullet here. Vendor evidence only, not an independent ranking: no price, exact credit quota, model-availability, benchmark, ranking, speed, accuracy, ROI, security-certification, or legal claim was added; no Gumroad/UTM/affiliate/sponsored/coupon/checkout link added. data/tools.json pricing_summary/has_free_plan/last_verified_at unchanged; content_status stays qa_passed; revenue inventory unchanged (18 tool + 51 comparison = 69 qa_passed pages). Local-only increment; live verify/build/deploy is handled separately.
2026-06-27 (qualified-traffic/decision-content increment — evergreen, LIVE deployed on aistackdb.com, NOT a new revenue page/product/outreach): added a compact "Buyer control and the review boundary" section after the "Source-freshness note (2026-06-24)" section and before "## What is GitHub Copilot?", carrying the durable marker github-copilot-review-boundary-2026-06-27 once (as a  anchor). The section helps AI Stack DB readers evaluate GitHub Copilot by control/review boundaries — buyer control over which surface is enabled and under which identity/scopes, who owns human review of correctness, how the repository/pull-request review boundary is held, generated-code acceptance, and CI/test review before merge — and reuses only this page's own existing context (the GitHub-documentation framing already in the source-freshness notes, including the "review the diff … create a pull request when you're ready" and "reuse your existing runner groups and policy constraints" wording) plus the Cons and caveats anchor. Links only existing local routes already in this content package: /compare/cursor-vs-github-copilot/, /compare/tabnine-vs-github-copilot/, /compare/github-copilot-vs-replit-ai/, /compare/claude-vs-github-copilot/, and the /ai-coding/ category. No source was fetched. No price, quota, plan entitlement, model availability, benchmark, ranking, speed, accuracy, superiority, security-certification, or legal claim was added; no Gumroad/UTM/affiliate/sponsored/coupon/checkout link added. data/tools.json, data/sources.json, and last_verified_at are unchanged; content_status stays qa_passed. Revenue inventory unchanged (18 tool + 51 comparison = 69 qa_passed pages). Hermes later uploaded the production ZIP through the visible Cloudflare Dashboard static-assets flow; public /tools/github-copilot/ served the marker/heading on 2026-06-27 KST.
2026-06-24 (source-freshness/traffic refresh — local source-gate recheck, NOT a new revenue page, NOT a deploy): added a compact "Source-freshness note (2026-06-24)" section after the "Source-freshness note (2026-06-18)" section (before "## What is GitHub Copilot?"), framing GitHub Copilot as an agent-workflow / code-review / security / enterprise surface whose plans should be verified at GitHub's own pages, with agent/Copilot output still needing human review and testing and no independent ranking or benchmark. Evidence: the 2026-06-23 KST agent-workflow source gate (data/agent-workflow-source-gate-2026-06-23-1007.json) found GitHub's official surfaces reachable (HTTP 200) — https://github.com/features/copilot (title "GitHub Copilot · Your AI pair programmer · GitHub", body-sample SHA-256 prefix 86faf6b5e632947e), https://github.com/features/copilot/plans (title "GitHub Copilot · Plans & pricing · GitHub", prefix 07690dbbcd439b50), and https://github.blog/changelog/ (H1 "Changelog", prefix 025b096b8ddadaf9). Recorded as src-github-copilot-source-gate-2026-06-24 (source_type = official_homepage, access_status = ok) and added to the github-copilot sources_used, plus a Sources bullet. Durable reachability/title/H1/marker evidence only: no exact price, quota, per-plan feature, model-availability, benchmark, ranking, speed, accuracy, or superiority claim was added, and the 2026-05-22 page-body read remains the source of every plan/price quoted here. No commerce, tracking, affiliate, sponsored, or coupon link added; data/tools.json and last_verified_at unchanged; still qa_passed, still 1 of the 18 tool pages. Local increment only — not a deploy.
2026-05-22 (draft): first local draft created from templates/tool-page-template.md. content_status = drafted.
2026-05-22 (qa pass): live page-body read of https://github.com/features/copilot/plans added concrete Free/Pro/Pro+ plan names and prices, Free-tier quotas, and the list of supported editors. New source entry added (src-github-copilot-plans-2026-05-22, access_status = ok). data/tools.json pricing_summary, has_free_plan = true, confidence_score, and last_verified_at refreshed. Section A1/A2 of qa/adsense-seo-quality-gate.md now satisfied. content_status advanced to qa_passed.
2026-06-18 (source-freshness refresh — local increment, NOT a new revenue page): added a compact "Source-freshness note (2026-06-18)" section after the "Source-freshness note (2026-06-13)" section, focused on the agent workflow + review/security/session/token boundary. Frames GitHub Agentic Workflows (public preview) from GitHub's own changelog: agentic workflows automate reasoning-based tasks "by leveraging coding agents inside GitHub Actions" and, as Actions, "reuse your existing runner groups and policy constraints"; they "can now use … built-in GITHUB_TOKEN" so a stored PAT is no longer required; and organization billing is gated behind the "Allow use of Copilot CLI billed to the organization" policy plus a copilot-requests: write frontmatter permission. Helps the buyer decide which identity/scopes/billing boundary to review before adopting agentic workflows, and reiterates public-preview + human-review caveats. Evidence: 2026-06-18 KST HTTP 200 reads of https://github.blog/changelog/2026-06-11-agentic-workflows-no-longer-need-a-personal-access-token/ (title "Agentic workflows no longer need a personal access token - GitHub Changelog", 200000-byte body-sample SHA-256 e612e7da0c16c55b5e3d34d19cb62be5a84ee0c0e9f6d1b2b50db261e026e529) and the companion https://github.blog/changelog/2026-06-11-github-agentic-workflows-is-now-in-public-preview/. Added one source to data/sources.json (src-github-copilot-agentic-workflows-2026-06-18, source_type = changelog, access_status = ok) and to the github-copilot sources_used, plus a Sources bullet. Vendor evidence only, not an independent ranking. No benchmark, ranking, price, quota, Free-tier-limit, speed, model-availability, or superiority claim added; No commerce, tracking, affiliate, sponsored, or coupon link added; data/tools.json and last_verified_at unchanged. Still qa_passed, still 1 of the 18 tool pages.
2026-06-13 (source-freshness refresh — LIVE deployed on Cloudflare static-assets upload, NOT a new revenue page): added a compact "Source-freshness note (2026-06-13)" section after "## Quick verdict" (before "## What is GitHub Copilot?"), framing GitHub Copilot as an IDE/GitHub coding-agent workflow from GitHub's official documentation page "About GitHub Copilot cloud agent" (src-github-copilot-coding-agent-2026-06-13, https://docs.github.com/en/copilot/concepts/agents/cloud-agent/about-cloud-agent, access_status = ok after a 2026-06-13 KST HTTP 200 read; the requested /coding-agent/about-coding-agent URL redirects to this canonical /cloud-agent/about-cloud-agent page). Covers the two surfaces (GitHub Actions–powered coding agent vs in-IDE agent mode), that agent changes land via a branch and reviewable pull request needing human review/test/approval before merge, and that pricing/plan/model availability must be confirmed on official pages — vendor evidence only, no independent ranking. Added one source to data/sources.json and the github-copilot sources_used. No pricing row changed; no benchmark, ranking, price, quota, speed, model-availability, or superiority claim added; No commerce, tracking, affiliate, sponsored, or coupon link added; data/tools.json and last_verified_at unchanged. Revenue inventory unchanged (18 tool + 51 comparison = 69 qa_passed revenue pages, plus 5 site_page drafts). Hermes verified and deployed this update on 2026-06-13 KST; live /tools/github-copilot/ returned HTTP 200 with the new source-freshness markers present.
2026-06-03 (internal-link/traffic refresh — LIVE deployed on Cloudflare version 9ffa100f, NOT a new revenue page): added a "Where to compare GitHub Copilot next" section (placed after "## Alternatives", before "## Who should not use GitHub Copilot") linking seven qa_passed GitHub Copilot comparison pages — /compare/cursor-vs-github-copilot/, /compare/tabnine-vs-github-copilot/, /compare/github-copilot-vs-replit-ai/, /compare/github-copilot-vs-microsoft-copilot/, /compare/claude-vs-github-copilot/, /compare/github-copilot-vs-gemini/, /compare/zapier-ai-vs-github-copilot/ — plus the /ai-coding/ category, framed as workflow-fit decision paths rather than rankings. Expanded the "Internal links" comparison row from the single /compare/cursor-vs-github-copilot/ entry to those seven Copilot comparisons. No source was fetched and no volatile claim was added: no benchmark, ranking, price, quota, Free-tier limit, speed, or model-availability fact is asserted, and no commerce/tracking/affiliate/sponsored/coupon CTA was added to this page. data/sources.json, data/tools.json, and last_verified_at are unchanged. Revenue inventory unchanged (18 tool + 51 comparison = 69 qa_passed pages). Live /tools/github-copilot/ returned HTTP 200 with marker count 2.