Before ranking any AI code detector, here are two numbers from our own, measured on 4 October 2026. A clean, well-documented Python function scored 87% AI. A deliberately human one, with a swear word in a comment and a reference to a ticket number, scored 68%.
Nineteen points apart, and the human sample landed one point below the threshold where the label flips to "likely AI-generated". That gap is the whole story of this category. A code detector is a sorting aid, and anyone selling you one as proof of authorship is selling something that does not exist.
Run against our live tool on 4 October 2026. Both numbers are published because one of them is inconvenient.
| Input | AI score | Label it gets |
|---|---|---|
| Clean Python function with a full docstring | 87% | Likely AI-generated |
| Messy human code: swearing in a comment, a ticket reference, an inline "y2k, lol" | 68% | Mixed signals |
The thresholds are 70 and 40: at or above 70 the label reads likely AI-generated, between 40 and 69 mixed signals, below 40 likely human-written. So the human sample came back one point short of being called AI.
Two things follow, and they matter more than any ranking. Well-documented code scores high. Consistent naming, complete docstrings and uniform structure are what a classifier reads as machine-made, and they are also what a good style guide and a linter produce. A tidy codebase will score worse than a scruffy one, which is the opposite of a quality signal.
And the useful range is narrow. Nineteen points between a best case and a worst case is not much room to make a decision in. Treat a high score as a prompt to go and look, never as a finding.
Worth knowing, because it explains both results above.
Our code scanner sends the code to the same endpoint as our prose detector and returns one document-level probability. The response carries an AI score, a human score and a word count. It reported the language of our Python sample as "English."
That is not a bug so much as a description of the category. These tools read statistical regularity in a token stream. Code is far more regular than prose by design, because style guides, formatters and linters exist precisely to remove individual variation. So the signal a detector depends on is the signal your tooling has already flattened.
Three things, because they are commonly advertised in this category and we cannot do them. We do not attribute code to a specific assistant. Nothing in the response identifies Copilot versus one chat model versus another, and a page claiming to tell them apart is describing something it has not built. We do not score per function. One scan returns one number for whatever you pasted. And we do not analyse language-specific syntax; the same classifier runs on all six languages the tool accepts, which are Python, JavaScript, Java, C++, Go and Rust.
If any of those three is what you need, no tool we know of does them reliably, ours included, and you should be sceptical of one that says otherwise.
Ranked by what each can actually establish, which is not the order they get reached for.
| Approach | What it establishes | Effort |
|---|---|---|
| Version-control history | How the code was actually written, over time | Low, if the history exists |
| Manual review by someone who knows the codebase | Whether it fits the author and the project | High |
| A classifier score on the code text | A direction, and nothing about authorship | Seconds |
| Clone and plagiarism detection | Whether it matches existing code | Minutes |
| Asking the model whether it wrote it | Nothing reliable | Seconds |
Git history is first and it is not close. A commit series showing a function built across sessions, with a failed approach reverted and a variable renamed twice, is evidence about how the code came to exist. A classifier score is a statement about how the finished text reads. In a dispute about who wrote something, one of those answers the question and the other does not.
This is also why the practical advice runs the other way from the sales pitch: if authorship matters on your team, the thing to invest in is commit discipline and review, not a scanner.
Clone detection answers a different question and is worth separating. It finds code matching something that already exists, which catches copied code and misses generated code, because a model composing fresh tokens matches nothing. Running one and getting a clean result tells you nothing about AI generation.
The daily count gates scans and rewrites; code scanning has its own, and length is the real limit.
| Free | Starter | Pro | |
|---|---|---|---|
| Price | $0 | $9.99/mo · $7.49 yearly | $19.99/mo · $14.99 yearly |
| Actions a day (shared) | 3 | 20 | Unlimited |
| Words per scan | 1,500 | 5,000 | 7,500 |
| Words per humanization | 260 | 5,000 | 10,000 |
| Detection a month | No cap | No cap | No cap |
| Humanizer a month | No cap | 40,000 words | 80,000 words |
One action is one scan, one file upload or one rewrite, from a single shared daily count. That daily number is the gate that matters: there is no monthly ceiling on any plan, so what separates the tiers is how often you can work and how long a single piece can be, not how much you get through in a month.
Read the free row together rather than line by line. No monthly cap sounds unlimited and is not: three actions a day at up to 260 words a rewrite is roughly 780 rewritten words in a day. It is a real allowance for checking and fixing specific passages, and it is not a plan for processing a backlog.
Current prices, the Business and Enterprise tiers and regional pricing are on the plans page, which is the page we keep up to date.
Code scanning is not one of those shared actions either. It runs on its own count: 3 scans a day with no account, 5 on a free account, 25 on Starter and no daily limit above that. The binding limit is length, not frequency: 50 lines per scan on free and anonymous, 500 on Starter. So the row above does not cap it, and on the free tier you are scanning a function at a time rather than a file.
Judge any of them on what the score is worth rather than on a ranking, because the honest answer is that this category gives a direction and not a verdict. On our own tool, measured on 4 October 2026, clean well-documented Python scored 87% AI and deliberately human messy code scored 68%, which is one point below the threshold for being labelled AI. We publish both numbers because the second one is the one that tells you how to use the result. We disclose that this is our own product.
No. The strongest evidence about authorship is version-control history, which shows how the code was built over time, including the approach that was reverted and the variable renamed twice. A classifier score is a statement about how the finished text reads, not about how it came to exist. If authorship matters on your team, commit discipline and review are the investment, not a scanner.
Most likely because it is tidy. Consistent naming, complete docstrings and uniform structure are what a classifier reads as machine-made, and they are also exactly what a style guide, a formatter and a linter produce. That means a well-maintained codebase tends to score worse than a scruffy one, which is the reverse of a quality signal. In our test the deliberately messy human sample scored 19 points lower than the clean one.
No, and we are not going to imply otherwise. Our scanner returns a single document-level probability with no attribution of any kind, so nothing in it distinguishes one coding assistant from another. Tools that advertise naming the specific assistant are describing a capability we have not seen substantiated anywhere, so treat that claim as a reason to doubt the rest of the page.
Python, JavaScript, Java, C++, Go and Rust. Worth knowing how that works: the same classifier runs on all six, because the tool reads statistical regularity in the text rather than parsing language-specific syntax. It reported our Python sample language as English. So there is no per-language tuning to choose between, and a language outside that list is not a different model, it is simply unsupported.
Yes, with no account: three scans a day at up to 50 lines each. A free account gives five a day at the same 50 lines, and Starter raises the length to 500 lines. Length is the binding limit rather than frequency, so on the free tier you are scanning a function at a time rather than a file. These scans are counted separately from the shared daily actions that gate text scans and rewrites.
Three scans a day, 50 lines, no account.
Open the tool →What 50 lines covers, and how to spend three scans well.
Read the guide →The signatures a human reviewer can read that a classifier cannot.
Read the post →Detection across docs and prose, not just code.
Read the guide →Three scans a day, no account, 50 lines. Try your cleanest code first and see what the score does.