How Often Does GitHub Copilot Recite Code Verbatim?
GitHub Copilot is trained on billions of lines of public code, and its suggestions are adapted to the user’s current context. But that adaptation is always informed by code written by others. The relationship between a suggestion and the code that influenced it can range from highly original to nearly verbatim. Some researchers have described such AI systems as “stochastic parrots,” while others at GitHub have compared them to “a toddler with a photographic memory.”
To test this directly, I examined how often GitHub Copilot produces a suggestion that is quoted from its training data, versus producing something genuinely novel.
The experiment setup
During GitHub Copilot’s early development, nearly 300 employees used it in their daily work as part of an internal trial. That trial provided a dataset to test for recitation. I limited the investigation to Python suggestions with a cutoff on May 7, 2021 (the day we started extracting that data). That left 453,780 suggestions spread over 396 “user weeks” — calendar weeks in which a user actively used GitHub Copilot on Python code.
Automatic filtering
To find possible recitations, I considered sequences of “words” that appear in a suggestion in the same order as in the code GitHub Copilot was trained on. Here, punctuation, brackets, and other special characters all count as “words,” while tabs, spaces, and line breaks are ignored. For instance, a suggestion like a regex for numbers separated by whitespace might contain exactly 100 such “words,” though the average non-empty line of code has only 10. I restricted the investigation to overlaps of at least 60 “words,” since shorter sequences are unlikely to be of interest — though it’s worth noting that most interesting cases ended up well above that threshold.
If the overlap extends to code the user has already written, that also counts toward the length, since the user may have written that context with GitHub Copilot’s help as well. This permissive filter still eliminated more than 99% of suggestions, leaving a manageable set for human analysis.
Manual bucketing
After filtering, 473 suggestions remained. They fell into distinct categories:
- Near-duplicates of other cases that passed filtering — for instance, when GitHub Copilot suggests something, the developer types a comment, and GitHub Copilot offers a very similar suggestion again.
- Long, repetitive sequences, such as repeated blocks of
‘<p>’found in training data. These can sometimes be useful (test cases, regexes) but do not fit the idea of rote learning. - Standard inventories like natural numbers, prime numbers, stock tickers, or the Greek alphabet.
- Common, straightforward, or nearly universal ways of doing things with few natural degrees of freedom — for example, the standard way to parse a Wikipedia list with BeautifulSoup.
- All other cases with specific overlap in code or comments — these are the potential “recitations” that matter most.
This bucketing is subjective at the edges. That’s why the dataset has been open sourced for independent review.
Key results
For most suggestions, the filter found no significant overlap with training data. Of the 473 cases it flagged, removing near-duplicates left 185. Of those, 144 fell into buckets 2–4, leaving 41 genuine recitations. That corresponds to one recitation event every 10 user weeks (95% confidence interval: 7–13 weeks, using a Poisson test).
These measurements came from GitHub and Microsoft developers; if your coding behavior differs, your results might too. Some participants worked only part-time on Python, so an event every 10 weeks is not zero — and three patterns stood out.
Lack of specific context invites quoting
Like a song learned by heart, GitHub Copilot only “knows” a snippet if it appears many times across public code. Each file is shown only once during training, so the snippet must exist in many files to be memorized. None of the 41 main cases appeared in fewer than 10 different files; most appeared in over a hundred. One instance — the GNU General Public License — had been seen more than 700,000 times during training.
Quoting happens early in a file
As a file grows, its context becomes unique. But GitHub Copilot doesn’t wait for that; it offers suggestions even when the file is still generic. Without specific context, it more readily quotes code it knows by heart. Developers spend most time inside files where context is unique, so suggestions at the very beginning are more hit-or-miss. Yet sometimes, even modest initial context lets GitHub Copilot hazard a reasonable guess — and that guess can be pulled almost directly from a known source, such as code from a robotics class coursework uploaded in different variations.
Detection isn’t perfect
The current filter turns up many uninteresting cases when applied broadly, but the signal still stands out. For internal users, that meant roughly one find per week on average, of which about 17% (95% confidence interval: 14–21%) fell into the final bucket. The tool can be tricked. Some cases with an obvious source are hard to detect automatically — for instance, content like the Zen of Python.
Where recitation happens — and how to surface it
The analysis shows that verbatim quotation is possible but rare, and when it does occur, it tends to involve widely copied boilerplate near the top of a file. The practical gap is not just in whether Copilot recites, but in the lack of transparency: a human who quotes a poem knows they are quoting. Copilot gives no such signal.
Knowing when a suggestion echoes training data matters for two reasons. It lets a developer seek out background context on the code, and it makes it possible to decide whether attribution is appropriate — or whether the snippet should be avoided altogether.
The natural fix is to surface the overlap detection logic used in this analysis directly in the product. If a suggestion contains copied segments, the UI could point to the source. That puts the developer in control: use it with credit, or drop it.
That duplication search is not yet part of the technical preview. The plan is to integrate it while continuing to bring down recitation rates and sharpen detection accuracy.
Methodology notes
Several caveats apply to the measurements in this study. The dataset used for matching is public but limited: it includes only the matched portion of a suggestion, not the surrounding completion or the user’s code context, with only a rough length indicator for those omitted parts (footnote 7). Because privacy was a constraint, some judgment calls were inevitable; labelers flagged uncertainty in just 34 cases, under 10% of the sample (footnote 6).
The experimental conditions also predate a change in Copilot itself. Since the data was collected, GitHub Copilot now requires a minimum file content before offering suggestions, so some completions flagged as recitations would not appear in the current version (footnote 8).
Earlier work informs the approach: deliberately triggering training-data recall has been explored in the context of large language models (footnote 4), and the risks of scaling such models were raised in the “Stochastic Parrots” paper (footnote 1). The interest in animal analogies — crows constructing compound tools — comes from research by von Bayern and colleagues (footnote 3).
Examples of matched suggestions cited in the dataset come from public repositories, including a snippet from DelayedTwitter referenced by user jaeteekae (footnote 5) and code from jenevans33’s CS8803-1 repository (footnote 9). The labeled dataset was compiled with help from Tiferet Gazit (footnote 2).
