Understand GitHub Copilot Data and Architecture Study Guide — GH-300

Understand GitHub Copilot Data and Architecture

This domain (13% of GH-300, roughly 8–10 scored items on a 60-ish item exam) tests whether you can explain mechanically what happens between a keystroke and a suggestion: what an LLM is trained on, how the IDE assembles a prompt, what the Copilot proxy does to inputs and outputs, where data is stored or discarded by plan tier, which hostnames must be reachable through a corporate firewall, and what Copilot structurally cannot do. Questions are heavily scenario-based ("a developer in an air-gapped network…", "an org must guarantee its code is never used for training…") and the wrong answers are almost always real GitHub features applied to the wrong layer of the architecture. Memorize the layers, the order of operations, and the plan-tier differences in data handling.

How GitHub Copilot Works: LLM Training, Context Window, Token Limits

GitHub Copilot is a thin client + remote LLM inference product. The IDE extension never contains a model; it only collects context, sends a request, and renders the response.

Models and training data

• Copilot is built on large language models (LLMs) trained by OpenAI (originally Codex, a GPT-3 descendant fine-tuned on code) and now on newer OpenAI models (GPT-4o / GPT-4.1 class), plus selectable third-party models for chat.
• Training corpus = natural language text + publicly available source code, including code from public GitHub repositories. Private repositories, Copilot Business/Enterprise prompts, and your local files are not part of pretraining.
• Models are hosted in Microsoft Azure infrastructure operated for GitHub. When a user selects a non-OpenAI chat model (Anthropic Claude, Google Gemini), the inference may be served by that provider's cloud under GitHub's subprocessor agreements — this changes who serves the request, not whether your code trains a model.
• Copilot uses two classes of models: a low-latency completion model tuned for inline "ghost text" (milliseconds matter, small context) and a larger chat/reasoning model for Copilot Chat, PR summaries, and agents (bigger context, slower).
• Inference is stateless and probabilistic. There is no per-user model, no fine-tuning on your repo, and no learning from your accept/reject choices in real time.

Tokens and the context window

• Text is split into tokens (sub-word units). Rule of thumb: 1 token ≈ 4 characters ≈ 0.75 English words; code is usually less token-efficient than prose (punctuation, indentation, camelCase splitting).
• The context window is the maximum number of tokens the model can process for prompt + completion combined. If the prompt fills the window, there is no room to generate output, so the client always reserves a completion budget.
• Exact window size is model-dependent and changes over time: inline completion models operate on a few thousand tokens; chat models range from tens of thousands to 128k+. The exam tests the concept (finite, token-measured, shared between input and output, forces truncation) far more often than a specific number.
• Because the window is finite, the extension must prioritize and truncate context. This is why Copilot "forgets" earlier chat turns and why it cannot see your entire monorepo.

Common traps

• Believing Copilot "learns from your codebase over time." It does not. Repo awareness comes from context supplied per request (open files, indexes, knowledge bases), never from training.
• Confusing context window with repository indexing. Indexing (Copilot Enterprise / @workspace / remote index) selects snippets to place into the window; it does not enlarge it.
• Assuming a bigger window is always used — the client still truncates based on relevance and latency budget.
• Thinking tokens = words, or that whitespace/comments are free.
• Answering "the model runs locally in the IDE for privacy." No local inference exists in Copilot.

Worked scenario: A developer complains that Copilot Chat "forgot" a constraint stated 40 messages ago. The correct explanation is that conversation history exceeded the model's context window and the earliest turns were truncated; the fix is to restate the constraint, start a new thread, or move the constraint into repository custom instructions so it is re-injected into every prompt. Increasing the subscription tier does not extend memory.