AI coding detector tools — what they measure, and what they can actually prove

In summary

• Code detection is fundamentally harder than prose detection. Idiomatic solutions converge, boilerplate is identical whoever wrote it, and a formatter erases most of what stylometry relies on.
• No code detector should ever be the sole evidence in a misconduct case. Commit history, draft states and a ten-minute oral walkthrough all outperform any score.
• False-positive rates on short, templated or heavily scaffolded files are high enough to destroy a case on appeal — and those are exactly the files most coursework consists of.
• Our pick, Pangram: free 2,000 words/day; Individual $20/mo (300k words); Team $20/seat/mo (min 2); Professional $65/mo (1.5M words + $200 API). Claims 99.98% accuracy and a ~1-in-10,000 false positive rate, third-party evaluated by U Chicago and U Maryland researchers. Verified 18 August 2026.
• Those published figures are for prose. Apply them to the write-up around the code, not to the code itself.
• Students: a low score is not clearance and a high score is not an accusation. Committing as you work is a better defence than any tool.

What each kind of evidence actually establishes

Editorial assessment of how each source behaves in a contested academic-misconduct case, 18 August 2026

Dimension	Code detector score	Commit / draft history	Oral walkthrough
What it measures	Statistical resemblance between the submitted tokens and model-typical output	How the artefact came into existence over time	Whether the student can explain and modify their own design
Fails on short files	Badly — under roughly 50 lines there is often not enough signal to separate anything	No — a three-commit history is still a history	No — a short file is quicker to discuss
Fails on boilerplate and scaffolds	Yes — generated scaffolds, framework templates and taught patterns are indistinguishable	No — scaffold and student work appear as separate commits	No — you ask about the parts they wrote
Survives a formatter or linter	Partly — auto-formatting strips whitespace and naming signal	Yes — formatting is itself a commit	Yes
Holds up on appeal as sole evidence	No. Do not attempt it	Usually, when combined with a discussion	Yes, when documented contemporaneously
Cost to run	Low — free tiers exist	Zero, if you require the repository up front	Ten to fifteen minutes of staff time per student

The pattern is consistent: the cheapest evidence is the weakest, and the strongest evidence has to be designed into the assessment before submission rather than reconstructed afterwards.

Detectors worth running — and what to run them on

All three of these are natural-language detectors with published evidence behind them. Vendors such as Copyleaks and Codequiry market code-specific detection; we have not been able to verify their false-positive behaviour on academic submissions and we only quote prices we have read off a vendor page ourselves, so treat those as candidates to evaluate rather than recommendations. Stanford’s long-standing MOSS remains the reference tool for code similarity, but it answers a different question — whether two submissions resemble each other, not whether a model wrote one.

#1 Pangram — our winner

Strongest published false-positive evidence, and the LMS coverage a computing department needs.

Best for: Departments that may have to defend a decision to a student or an appeals panel

Price: Free tier · Individual $20/mo

Run it against the prose that surrounds the code — the design rationale, the reflective commentary, the README, the report. That is where a detector still has real signal, and where a student who did not do the work is most exposed. Third-party evaluation by University of Chicago and University of Maryland researchers is unusual in this category and worth something, though it is a snapshot of a moving target. LMS integration spans Canvas, Moodle, Google Classroom and Brightspace, so it appears where marking already happens, which is what determines whether a tool gets used consistently rather than abandoned by week six.

Strengths

• Lowest published false-positive rate in the category (~1 in 10,000)
• Third-party evaluation rather than vendor benchmarks alone
• Canvas, Moodle, Google Classroom and Brightspace integration
• Free 2,000 words/day is enough for a genuine departmental evaluation

Trade-offs

• Published accuracy figures are for natural-language text, not source code
• Newer entrant with a shorter track record than the incumbents
• Institutional licensing is custom-quoted rather than transparent

Try Pangram free CASRAI referral link — disclosed on this page

#2 GPTZero

Sentence-level highlighting gives you something specific to discuss instead of a percentage.

Best for: Tutors who want to open a conversation rather than raise a case

Price: Free tier · Individual from ~$9.99/mo

In a computing context the highlighting matters more than the headline number. Being able to point at the two paragraphs of the design rationale that look anomalous and ask the student to expand on them is a fair, proportionate and quick intervention; producing a 92% figure and asking them to explain it is neither. Free tier available, Individual from around $9.99/mo, with Canvas, Moodle and Blackboard integration. Verified 18 August 2026.

Strengths

• Sentence-level highlighting supports a defensible conversation
• Canvas, Moodle and Blackboard integration
• Free tier for evaluation

Trade-offs

• Accuracy figures are vendor-reported
• Same fundamental limits on source code as everything else here

Try GPTZero free CASRAI referral link — disclosed on this page

#3 Originality.ai

Team-oriented, with plagiarism checking bundled — but no LMS integration.

Best for: Assessment teams already working outside the LMS, or publishers screening technical submissions

Price: From $14.95/mo (2,000 credits)

From $14.95/mo for 2,000 credits, verified 18 August 2026. The bundled plagiarism check is genuinely useful for technical writing, where lifted passages from documentation and Stack Overflow answers are common and much easier to establish than generation. The credit model needs watching across a marking period so a module team does not run dry mid-cohort, and the absence of LMS integration is a real workflow cost in teaching.

Strengths

• Plagiarism checking bundled alongside detection
• Team activity logging
• Transparent entry pricing

Trade-offs

• No LMS integration
• Accuracy figures are vendor-reported
• Credit model requires active management across a term

Try Originality.ai CASRAI referral link — disclosed on this page

Why detecting AI-generated code is harder than detecting AI-generated prose

Prose detection works, to the extent it works at all, because natural language is enormously redundant. There are hundreds of acceptable ways to express a given sentence, and the choices a writer makes among them carry a signal. Source code is the opposite: it is written under constraints designed to eliminate exactly that variation.

Idiomatic code converges. Ask fifty competent Python programmers to reverse a linked list, validate an email field or parse a CSV into a dataframe and you will get a handful of near-identical solutions, because the language, its standard library and the community’s style guides all push towards one answer. Where prose fans out, code collapses inward. A model trained on public repositories produces the same idiomatic solution the textbook teaches, which is the same one the student was taught in week three. There is no anomaly to detect, because there is no divergence.

Boilerplate is identical whoever produced it. A large fraction of any submission is not authored in a meaningful sense at all: imports, class scaffolds, framework-generated files, configuration, test harness setup, getters and setters, the argument parser. This material is produced by templates, IDE autocompletion, framework CLIs and starter repositories. Feeding it to a detector asks a question with no coherent answer, and detectors nonetheless return a number.

Formatters erase stylistic signal. Prose stylometry leans on habits of punctuation, sentence length and lexical choice. In a modern toolchain, Black, Prettier, gofmt, clang-format or a pre-commit hook normalises indentation, line breaks, quote style and spacing before the code is ever committed — often automatically, on save. A linter enforces naming conventions on top. Much of what a stylometric approach would use has been deliberately standardised away by the profession as a matter of good practice, and a student following the module’s own style guide looks, by construction, less individually distinctive.

The training data is the coursework. Models were trained on the public repositories, tutorials and question-and-answer sites that students also learn from. Human-written code that closely resembles model output is therefore the normal case rather than a suspicious one, and the resemblance runs in both directions.

And almost everyone now writes code with assistance. Completion tools are embedded in the editors students and professional developers use daily. A file where a student wrote the logic and accepted a dozen autocompletions is not generated code, but it is also not untouched — and no detector can tell you where on that spectrum a submission sits. If your policy has not defined which forms of assistance are permitted, the detector is answering a question your regulations have not asked.

What the available tools actually measure, and how they report confidence

Marketing copy in this category says “AI detection”. The underlying methods are distinct, and they fail in different ways, so it is worth knowing which one you are buying.

• Token likelihood and perplexity. The classic approach: score how predictable each token is under a language model. Text a model would readily produce scores as low-perplexity and gets flagged. On code this is at its weakest, because well-written code is supposed to be predictable — that is what idiomatic means. The clearest human code and the clearest generated code sit in the same region of the distribution.
• Trained classifiers. A model trained directly on labelled human and generated samples. Usually the strongest performer, and the approach behind the better prose detectors, but it inherits the biases of its training set and degrades whenever a new model with different output characteristics is released.
• Stylometry. Naming habits, comment density and placement, structural preferences, error-handling patterns. Genuinely informative when you have a body of a student’s previous work to compare against — and largely neutralised by a formatter, a linter or a house style guide.
• Similarity detection. MOSS and its descendants compare submissions against each other and against a corpus. This answers a different and much more tractable question than generation, and in practice it still catches more misconduct than AI detection does.
• Provenance and telemetry. Commit history, keystroke and paste events in a browser-based IDE, draft states in a version-controlled repository. Not detection at all in the classifier sense — and much better evidence than any classifier, which is the uncomfortable finding at the centre of this entire subject.

Confidence reporting varies more than it should. Some tools return a single percentage, which reads as a probability that the work was generated but is nothing of the kind — it is usually a classifier output that has not been calibrated against any realistic base rate of misconduct in your cohort. Others return bands (“likely human”, “uncertain”, “likely AI”), which is more honest because it refuses precision the underlying method cannot support. A few give per-segment highlighting, which is the most useful format for teaching because it localises the concern to something you can ask about.

Whatever the format, ask the vendor two questions before adopting anything: what is the false-positive rate, and on what kind of material was it measured? A figure measured on 3,000-word essays tells you nothing about a 40-line file. If a vendor cannot separate those cases, that is your answer. We work through the same evaluation logic for prose in our most-accurate-detector comparison and the detector round-up.

A detector score must never be your only evidence

This section is the point of the page, and it is unambiguous: no code detector should be used as the sole evidence in an academic-misconduct case. Not as corroboration for a weak case, not as the tie-breaker, and not as the thing you put in front of a panel when nothing else materialised.

Three reasons, each sufficient on its own.

The false-positive rate on the files you actually mark is high. Published detector accuracy is measured on long, discursive samples. Coursework submissions are frequently short, templated, scaffolded by the module team and shaped by a taught style. Those are precisely the conditions under which a classifier has least signal — and a wrongly flagged student is not merely an error in a spreadsheet. It is an accusation they cannot disprove, against a record, with consequences for progression, funding and visa status.

The same disparities documented for prose detection apply here. Research has repeatedly found that AI detectors disproportionately flag writing by non-native English speakers, because the features associated with machine generation overlap with competent second-language writing. In computing the analogous effect is a student who has learned from the same tutorials and templates the models were trained on, and who follows the taught pattern faithfully — a description that fits conscientious students, students new to the language and students on conversion courses more than it fits anyone else. Our guidance for teachers goes through the fairness implications in detail.

Process evidence beats any score, and it is cheaper. A required repository with meaningful commit history shows the work coming into existence. Draft states show a solution being got wrong before it is got right. A ten-minute walkthrough — “talk me through this function, now change it so it handles an empty input, why did you choose a dictionary here” — resolves the overwhelming majority of genuine cases in one sitting, and resolves them in the student’s favour just as often. None of it requires a licence.

A defensible sequence: treat any flag as a prompt to look rather than a finding; read the code yourself; check the commit history for the shape of real work; compare against the student’s previous submissions; hold a short technical conversation and document it contemporaneously; and escalate only when the evidence beyond the score would stand on its own. If the score is the case, there is no case.

Checking your own code before you submit it

If you wrote your own code and you are running a detector on it because you are anxious, be clear about what the result can and cannot tell you.

A low score is not clearance. It does not certify anything, and no institution treats it as certification. A high score is not an accusation either — it frequently means your code is short, idiomatic, formatted by a standard tool and structurally similar to the pattern you were taught, which is what a good submission looks like.

What actually protects you is process, and you have to build it before you submit rather than assemble it afterwards.

• Commit as you work, in small increments, with real messages. A repository showing a feature developed over eleven commits across four days, including the two where you broke it, is close to unanswerable. This is the single most effective thing on the list.
• Keep your notes, sketches and failed attempts. Branches you abandoned are evidence of a person thinking.
• Be able to explain every line. If you accepted a completion you do not understand, either learn it or replace it — not for integrity reasons alone, but because you will be asked.
• Disclose assistance where the module allows it. Many now permit tool use with declaration. Declared use is not misconduct; undeclared use of the same tool can be.
• Read the actual regulations, not a forum summary. Rules differ sharply between institutions and even between modules in the same department.

Do not buy a subscription for this. If you are a student wanting to check your own work, the free tiers are sufficient — Pangram gives 2,000 words a day at no cost and GPTZero has a free tier. Paying $20/mo to reassure yourself about coursework you wrote is money spent on anxiety rather than on a result, and the paid tiers exist for volume, not for extra certainty.

What a computing department should do instead

Detection in this domain is a rearguard action, and the direction of travel is not favourable: assistance is being embedded deeper into the tools students are correctly being trained to use professionally. Assessment design is the durable response, and unlike detection it improves teaching rather than only policing it.

Require a repository, not a zip file. Mark the history alongside the artefact. This one change converts an unfalsifiable dispute into a documented record, costs nothing, and reflects professional practice.

Add a short oral component. Ten minutes on a submitted project — explain this design decision, extend this function, what happens with an empty input — is fast at scale when it is scheduled into lab time, and it assesses understanding rather than output. It is also the fairest possible way to resolve a suspicion, because it gives the student an immediate route to clear themselves.

Anchor tasks to things a general model cannot know. This term’s dataset, the departmental teaching server, the specific API keys issued to the cohort, a lab result the student generated themselves.

Assess reasoning explicitly. Marks for the design rationale, the trade-off discussion, the test strategy and the reflection on what failed. This is prose, which is where detection still has some purchase, and it is where a student who did not do the work is genuinely stuck.

Write the permitted-use policy down, at module level. A large share of what currently gets flagged is students using tools nobody told them were prohibited. A clear statement plus a disclosure requirement converts an integrity problem into a transparency one, and resolves more cases than any licence — before the harm rather than after it. If your institution has no written policy on how detection results may be used in a case, close that gap before you procure a tool, because otherwise individual markers will improvise and outcomes will vary by tutor.

Buy a detector, if you buy one, as a screening aid for the written components and as a prompt to look more closely. Do not buy one as a source of proof, because it is not one. For the underlying methodology and evidence, see our Pangram review.

Test it against your own cohort before you commit

The free tier is 2,000 words a day — enough to run a batch of last year’s design rationales and reflective reports, including work from students you know wrote it themselves, and get the false-positive number your own appeals process would actually care about.

Free tier · Individual $20/mo

Try Pangram free Opens on the vendor’s site · CASRAI referral link

Frequently asked questions

Is there a reliable AI coding detector?

Not in the sense people mean when they ask. Every AI coding detector returns a probability derived from statistical resemblance, and source code offers far less signal than prose because idiomatic solutions converge, boilerplate is identical whoever wrote it, and formatters strip stylistic variation. Detectors are usable as a screening prompt on the written components of a submission; they are not usable as proof.

Can a university detect AI-generated code?

It can gather evidence, which is not the same as detection. The methods that work are process-based: required commit history showing the work developing, comparison with the student’s previous submissions, similarity checking against other submissions, and a short oral walkthrough of the code. Those routinely establish what happened. A classifier score on its own does not.

Why does my own code get flagged as AI-generated?

Usually because it is short, idiomatic, auto-formatted and structurally similar to the pattern you were taught — all characteristics of good code rather than generated code. Detectors flag statistical typicality, and a well-written solution to a standard exercise is about as typical as text gets. This is why a high score is not evidence of anything on its own.

Can I be failed because a code detector flagged my submission?

You should not be, and a decision resting only on a detector score is weak on appeal. A score is a probabilistic signal about token patterns, not a record of what you did. Ask what evidence beyond the score exists, offer your commit history and drafts, and ask for the opportunity to talk through the code — that conversation resolves most genuine cases quickly.

How accurate are AI code detectors on short files?

Materially worse than on long ones, and short files are most of what gets marked. Below roughly fifty lines there is often not enough variation for any method to separate human from generated code, and the same applies to scaffolded or templated files regardless of length. Published accuracy figures are generally measured on long natural-language samples and should not be assumed to transfer.

What does Pangram cost, and does it detect code?

Free 2,000 words/day; Individual $20/mo for 300k words; Team $20/seat/mo with a two-seat minimum; Professional $65/mo for 1.5M words plus $200 API. Verified 18 August 2026. Its published claims — 99.98% accuracy and roughly a 1-in-10,000 false positive rate, third-party evaluated by University of Chicago and University of Maryland researchers — concern natural-language text, so use it on the design rationale, report and reflective commentary rather than on the source files.

What is the best evidence that a student wrote their own code?

Commit history with meaningful incremental messages, including the commits where the code was broken, followed by a short oral walkthrough in which the student explains and then modifies their own design. Both are cheap, both are far stronger than any score, and both have to be designed into the assessment before submission rather than reconstructed afterwards.

Related on CASRAI

• Pangram review
• Best AI detector for teachers
• The most accurate AI detector
• GPTZero review
• AI detectors compared
• All AI writing & research tools