GitHub Copilot

If you pay for GitHub Copilot, Empryo can use it. Claude Opus/Sonnet, GPT-4o, GPT-5.4, o-series, Gemini 2.5 Pro - all included in your Copilot subscription, no extra cost.

Setup

Enterprise seats

A Copilot seat can live on a GitHub that is not github.com — GitHub Enterprise Cloud with data residency (a *.ghe.com tenant) or a self-hosted Enterprise Server. Those tenants serve every leg of the flow from their own hostnames, and a token minted on one GitHub means nothing on another, so the host is part of the sign-in rather than a setting applied afterwards:

/login copilot octocorp.ghe.com

/login copilot enterprise asks for the host instead, and /login lists GitHub Copilot (Enterprise) as its own row on both the TUI picker and the desktop dialog. Headless takes it in the same position:

empryo --headless --login copilot octocorp.ghe.com

Give the tenant root. api. and copilot-api. hosts are derived from it — pasting one folds back to the root rather than being taken literally:

The host is saved next to the credential as copilotHost, and COPILOT_GITHUB_DOMAIN overrides it for one run or a CI image. Signing out returns the lane to public github.com. Business and Enterprise seats on github.com need none of this — their proxy already comes back in the token exchange and has always been followed.

Reusing an IDE token instead

If you already signed in to Copilot in VS Code or JetBrains, that token works too:

jq -r '."github.com".oauth_token' ~/.config/github-copilot/apps.json
empryo --set-key copilot <token>

On Windows the path is ~\AppData\Local\github-copilot\apps.json. /keys inside the TUI does the same thing.

Which models your seat can actually run

Copilot's catalog lists every model GitHub sells, not the ones your seat may use. A plan with no premium allowance (Copilot Free, free_limited_copilot) routes only the base GPT line — gpt-4.1 and gpt-4o. Every other id answers:

The requested model is not supported.

Empryo rewrites that refusal with the reason and your seat SKU instead of passing it through, because GitHub's own message names neither. Claude, Gemini and the GPT-5 line need a paid Copilot plan.

Models whose terms you have not accepted yet (policy.state: disabled — most new SKUs) are accepted automatically on first use, the same call the official editor extensions make when you pick the model there.

Two wire formats

Copilot is the only provider whose endpoint varies per model, and Empryo follows the supported_endpoints its /models declares:

The Responses lane runs with store: false and encrypted reasoning replay, so a multi-step agent turn keeps its reasoning across tool calls. The mapping is cached on disk, so a --headless run resuming a saved model encodes the right wire before it opens any picker.

Reasoning effort comes from Copilot's own per-model ladder (/effort), which is not always the vendor's: Copilot's Claude SKUs take low|medium|high|max, gpt-5.6 adds none.

Usage and quota

Copilot bills a monthly allowance, not tokens, so the number that matters is how much of the month is left. GitHub reports it and Empryo shows it next to the relay subscription meters, in the same gauge:

Subscription · copilot
● pro                    octocat
  ▸ premium        [▰▰▰▰▰▱▱▱▱▱]   50%  ↺ 12d
    chat           [▰▱▱▱▱▱▱▱▱▱]   10%  ↺ 12d
    completions    [▱▱▱▱▱▱▱▱▱▱]    0%  ↺ 12d  editor only

Three allowances come back, and they are not equivalent:

That last row is why completions is drawn dimmed and marked *editor only*: a spent completions cap says nothing about whether your next turn will go through, so it must never read as "your plan is spent".

Where it shows, on every surface that can carry a plan meter:

The status bar carries one plan meter, and it follows the model: a copilot/* turn shows the Copilot allowance, a proxy/* turn shows the relay window. They are never both true at once, so they never compete for the slot.

Numbers are cached for five minutes; they only move monthly, and GitHub's Acceptable Use Policies discourage chatty automation against their servers.

Context windows follow your seat

Copilot resells these models and caps them under their native windows. A plain seat gets Claude Opus at 200k where Anthropic serves 1M. Seats with the extended-context capability get more, and GitHub reports the number per account rather than per model.

Empryo reads both numbers Copilot publishes for each model and keeps them apart:

Collapsing them made every extended-context model read as its input half. If your seat has the 1M capability, open the picker once so the live listing lands, and the larger window appears. Until then Empryo falls back to a table of plain-seat numbers, which is the safe direction to be wrong in: an overstated window means compaction never fires and Copilot rejects the turn.

Where the list comes from

Three tiers, in order, and a lower one only fills what the one above did not answer:

Signing in replaces the seat: /login copilot drops the previous account's cached catalog (memory and copilot-models.json) and re-lists immediately, so a Free seat's numbers never survive an upgrade or an account switch.

Which rows a human is offered is GitHub's call, not a guess: the listing carries model_picker_enabled per model, and Empryo filters on it exactly as the official client does. Where no listing exists to ask — a cold start, a catalog-only row — a name pattern stands in for it (copilot-search-*, exec-agent-*, trajectory-*, the -picker / -secondary / -tertiary shadow deployments).

The client Empryo identifies as, and the line it will not cross

CAPI needs to know which protocol dialect is calling, and it answers differently for different client generations. This is not cosmetic: GitHub's 1M-token context windows are scoped in its own changelog to "Visual Studio Code and Copilot CLI", and a seat entitled to them is served them on the same model ids — claude-opus-5 comes back as 264k to one client and 1,000,000 to another, from one account, minutes apart. The difference was the contract version and the intent: X-GitHub-Api-Version: 2026-08-01 (the value the official CAPI client negotiates) and a listing that asks as model-access rather than as a chat turn.

So Empryo sends a current Editor-Version / Editor-Plugin-Version, Copilot-Integration-Id: vscode-chat and that API version. A listing goes out as model-access, a turn as conversation-agent, and a request carrying images declares Copilot-Vision-Request.

The User-Agent says `Empryo/<version>`. It is not GitHub Copilot Chat and does not claim to be — the Acceptable Use Policies prohibit "fraudulently misrepresenting your identity", and every third-party Copilot client in the wild names itself here. For the same reason Empryo sends no VScode-MachineId, VScode-SessionId or Editor-Device-Id: the official client sends real ones, ours could only be fabricated, and a synthetic hardware id is a counterfeit installation rather than a protocol dialect. Measured on a real seat, sending them changed the catalog not at all.

Every part of the identity is overridable, because it is GitHub's to change and yours to test:

COPILOT_INTEGRATION_ID=copilot-cli empryo --list-models copilot asks GitHub the same question as a different client, and the source: line says which tier answered.

Request discipline

Nothing in GitHub's terms forbids reaching Copilot from a third-party client — Section J (AI Features) governs individual seats and names no required interface. What the terms *do* name is volume: the Acceptable Use Policies prohibit "excessive automated bulk activity" and "undue burden on our servers through automated means", and Section H lets GitHub suspend API access for request rates it judges excessive, at its sole discretion.

A turn here is the same shape as a turn in Copilot CLI or the VS Code extension: one agent loop, one request per step, x-initiator: agent when the step follows a tool result. The only call that isn't part of that loop is the model listing, because a UI can trigger it with nobody asking — so that is the one thing throttled, and it is throttled harder than the client GitHub ships:

Concretely:

• One listing per minute per process, floor. Every picker open, cache invalidation and login collapses into one question; a sign-in is the single event allowed to bypass it.
• A 429 or 403 is a stop, not a retry. Empryo backs off for Retry-After (or 15 minutes), serves the seat's last listing from disk, and says so once.
• A refused credential is probed once. The GitHub-App fallback runs a single time per token per process, never in a loop.
• Quota is read at most every five minutes, and only for a copilot/* model.

Legal position

GitHub restructured its terms on 27 April 2026. What governs Copilot now depends on your seat:

Section J covers ownership of input and output, model training and the opt-out, disclaimers and indemnity. It places no restriction on which client you use. The constraints that do apply come from elsewhere in the agreement:

The official route

Since mid-2026 GitHub ships a supported path that did not exist when this integration was written:

If being on a sanctioned integration matters more to you than running Copilot models inside Empryo's own agent loop, that SDK is the route GitHub endorses. Empryo's provider talks to the chat endpoint directly instead, which is what lets Copilot models use the same tools, Genome and compaction as every other provider.

Re-verify if GitHub publishes updated terms after 2026-08-02.