Why I care what the schema says
I build AI agents at eesel, which means I read model cards the way other people read release notes, and I get to watch what happens when a detector sits inside a real pipeline instead of a demo box.
Every draft eesel's blog writer produces goes through a detector gate before a human sees it. That is not a small sample. One customer, an SEO content lead on Webflow CMS, runs a keyword-to-publish pipeline at 360+ posts a month, roughly 12 a day, with bulk review and publish at the end of it. When you are operating at that rate, "the detector said 84%" is useless and "these four paragraphs read as AI-assisted, the rest is clean" is actionable. So the schema is the product, as far as I am concerned, and Pangram 4 is the first version where the schema is the headline feature.
That volume is also why I read the limits section before the results section. A detector sitting inside an AI content pipeline gets fed things nobody tested it on, and the failure is quiet: it returns a number for input that is outside its own stated scope, and the number looks exactly like a real one.
The eesel team has spent years putting AI on live queues and watching confident-sounding models be wrong in ways that only show up at volume, which is the same instinct I bring to a 0.0041% claim. Not disbelief. Just a habit of reading the footnote first.
What Pangram 4 actually is
Pangram Labs is a Brooklyn company, founded in 2023, with a team of 11 to 50 people. Max Spero (CEO) and Bradley Emi (CTO) met in a Stanford freshman dorm and later built the classifier together, per Pangram's own story. The company carries SOC 2 Type 2, verified by AssuranceLab.
Pangram 4 launched on July 29, 2026, and the same day brought a $9M round led by Menlo Ventures and a first AI image detection model badged as a research preview. The model has a published model card and a technical report on arXiv as 2607.27183, which is more disclosure than most of this category offers.
The positioning is flat and combative. The homepage headline is "An AI detector that actually works," and the subhead claims 99.98% accuracy. Worth noting that the site quotes several different accuracy figures depending on which page you land on: 99.98% in the hero, 99.9%+ in the badge strip, "over 99%" in the FAQ, and a 1-in-10,000 false positive rate in a different FAQ entry than the 1-in-24,000 figure on the model card. Those are not contradictions exactly, they are different measurements presented with the same confidence, which is the first reason to go to the model card instead of the marketing page.
How Pangram 4 reads a document
This is the part that makes Pangram 4 different from its own predecessor, and it is all on the record.
The backbone is "a causal, open-weight sparse mixture-of-experts language model." Pangram does not name the base model, and publishes no parameter count. Training was four days on eight NVIDIA H100 GPUs, using PyTorch and Hugging Face libraries, with a two-stage LoRA process where the first adapter is merged into the backbone before the second stage begins.
Four linear heads sit on top of the shared representation:
- A 15-class segment head estimating the overall level of AI involvement in a text window.
- A three-class tokenwise provenance head predicting Human, AI-Assisted or AI-Generated for every single token.
- A binary mixed-authorship head estimating whether a segment contains text of mixed provenance.
- A four-class humanizer head separating Human, AI-Generated, AI-Edited and Humanized-AI text.
The humanizer head is trained as a stop-gradient probe, so its objective never updates the shared backbone. It also does not vote on the final label: the card is explicit that in the decoding step, "the humanizer evidence does not contribute." So is_humanized is a side channel you read separately, not an input to the verdict.
Inference works on a 512-token window, which means longer documents get split into overlapping windows and predictions for tokens that appear in more than one window are aligned and averaged. A calibrated three-state linear-chain conditional random field then combines the tokenwise, segment and mixed-authorship observations across the whole document, Viterbi decoding picks the most likely label sequence, and a postprocessing step rounds everything to sentence boundaries with a minimum run length "tuned to around 2 sentences."
That 512-token window is also the mechanism behind the single most common confused-user report about this product, and it has been for over a year:
"Can you tell me how the sections work in Pangram? I am looking at a student's work, and Section 1 is all green, with 7.83% identified as possible AI use. Section 2, which includes most of Section 1 along with some additional new paragraphs, says 99.9% possible AI use, and some of the paragraphs that were green before are now red. Confused!"
That is not a bug report, it is the windowing working as designed. A paragraph's label depends on the context it was scored inside, so the same paragraph can flip colour when you change what surrounds it. Pangram 4 narrows the blast radius here by taking the minimum segment down to about two sentences, where Pangram 3 was much coarser, but it does not remove the effect. If you are scanning excerpts, scan the whole document once instead of chunk by chunk, and you will stop seeing contradictions.
The output fields, and the two that get misread
Here is what a finished Pangram result actually looks like.
Per segment, the API returns the exact substring, a label, character offsets, a word count, and four numbers. Two of those four are routinely read as something they are not, and the model card corrects both in plain language.
ai_assistance_score is computed as P(AI-Generated) + 0.5 × P(AI-Assisted). The card states it "is a continuous AI-involvement score, not the probability of the displayed discrete label." So a segment at 0.62 does not mean 62% confident. It means the blended AI-involvement estimate landed at 0.62, and the label next to it came from a separate decoding path.
confidence returns High, Medium or Low, and it "measures the peakedness of the unconstrained CRF posterior, it is not a calibrated probability estimate." High confidence is a statement about how sharply the model's internal distribution peaked, not a claim that it is right 95% of the time.
The other two are cleaner. humanizer_score is the probability a humanizer tool touched the segment, and is_humanized flips true at 0.91 by default at release, a threshold Pangram describes as internally calibrated, which is a polite way of saying it can move.
If you have ever argued with a colleague about what a detector percentage means, this is where the argument was hiding. The number is real and the model is measuring something, but it is not the "chance this is AI" figure that everyone reads it as. That gap is the whole subject of my longer piece on detector accuracy, and it applies to every tool in this category, not just this one.
How the document verdict gets decided
At document level, Pangram returns three character-weighted fractions that sum to 1.0, plus a prediction_short field with exactly three possible values and two published thresholds.
prediction_short thresholds, per the Pangram 4 model card.Human requires at least 90% of the document's characters classified human. AI requires at least 80% classified AI-generated. Everything else is Mixed. Notice the asymmetry: the human bar is stricter than the AI bar, so a document that is 85% AI-generated does not return AI, it returns Mixed.
That asymmetry matters more than it sounds, because Pangram's own evaluation methodology says that on binary datasets containing only fully human or fully AI texts, a Mixed prediction counts as an error. Which is fair, and it also means the headline error rates are measured against a stricter standard than "did it get the vibe right."
Plug your own split in and watch where the verdict flips:
The reason this matters for anyone editing rather than grading: Mixed is the normal result for real work. A human draft with a polished intro, or an AI draft a human properly rewrote, both land there. Treating Mixed as a failing grade means treating AI content editing as suspicious behaviour, which is backwards, and it pushes writers toward the wrong target. The goal is error-free writing that reads like a person, not a fraction that clears a threshold.
What Pangram 4 does not cover
The model card is unusually direct about its own boundaries, and this section is the one I would print out before deploying it anywhere.
Pangram 4 "accepts text inputs of at least 50 words" and is "designed for natural-language prose written in complete sentences." Named as outside its primary scope or more error-prone: short conversational replies, single-fact answers, source code, tables of contents, reference sections, templated or automated writing, instructions and technical manuals, and text dominated by mathematical notation. Pangram also recommends stripping human-written headers, footers and formatting before a scan, and prefers raw text or .docx over PDFs because PDF parsing introduces artefacts.
Read that list against how people actually use detectors and the mismatch is obvious. Product descriptions, changelog entries, meta descriptions, release notes, FAQ answers and social captions are all either under 50 words or templated by nature. A verdict on any of them is outside what the model claims to do, which matters if you are gating the output of a content generation tool that produces exactly those formats at scale.
The language gap is the other boundary, and it is quantified. Against 0.3396% for English, the published false negative rates per language run from Czech at 0.2760% up to Persian at 3.1715% and Urdu at 5.3169%. Multilingual false negatives aggregate to 1.24%, nearly four times the English figure. On the false positive side the spread is smaller but real, with Ukrainian worst at 0.0361%.
| Corpus | N | Errors | Rate |
|---|---|---|---|
| FineWeb English, human | 1,000,000 | 41 false positives | 0.0041% |
| FineWeb2, 104 languages, human | 996,273 | 14 false positives | 0.0014% |
| English AI, 26 generator models | 519,993 | 1,766 false negatives | 0.3396% |
| Multilingual AI, 18 languages | 190,149 | 23,578 false negatives | 1.24% |
Figures from the Pangram 4 model card.
Against Pangram 3.3.2, the overall English false negative rate dropped from 1.9942% to 0.3396%, which is a real generational improvement rather than a rounding change. Per generator, Grok 4.3 is the hardest at 0.605% and Claude Haiku 4.5 the easiest at 0.130%, and the biggest single gain was on Gemini, from 5.138% down to 0.498%.
Where you can actually run a scan
Five surfaces, and the free tier reaches most of them.
The web app takes pasted text or file uploads, and supports PDF, DOCX and RTF, up to 100 files at a time. There is a browser extension for Chrome and Firefox that adds a right-click "Check for AI Content" action and works inside Google Docs.
The API is prepaid credits rather than a subscription, at $0.05 per 100 words on Pangram 4, with a 20% bulk discount and a 5 QPS realtime ceiling. That is the surface you would use to put a detector gate inside your own stack, which is the same integration shape as a writer API on the generation side. Two details there are easy to get wrong. Pangram 4 costs exactly ten times Pangram 3 per word, because the dollar figure stayed at $0.05 while the unit shrank from 1,000 words to 100. And a call that omits the model argument still routes to Pangram 3 on the old billing until September 30, 2026, at which point the same call silently gets ten times more expensive per word. Pin model="pangram-4" now and you will not be surprised in October.
LMS integrations for Canvas, Moodle, Brightspace and Google Classroom sit behind the quote-gated Institutional License, and plagiarism checking is the line between free and paid. The image detector is on every plan including free at three scans a day, but it is a research preview: the page states 99.8% accuracy with no dataset, no methodology, and no published list of which generators it covers.
Reading the numbers without over-reading them
Pangram 4 is, by the available evidence, the strongest detector in this category. Independent teams from UChicago Booth, Vrije Universiteit Brussel and the University of Maryland all found Pangram had the lowest false positive rate of the commercial detectors they tested. Every one of those studies ran Pangram 3.x. No third party has tested Pangram 4 at all yet, and the largest human control set anyone has run bounds the false positive rate at roughly 0.15%, not 0.0041%. Confirming a 1-in-24,000 figure needs somewhere around 73,000 clean human samples.
The two sharpest criticisms are not anecdotes, they are statistical, and both survive contact with Pangram's own numbers.
"Pangram boasts a false positive rate of 1 in a 10,000. That is, if Pangram says a block of text is AI there is only a one in ten thousand chance that it was written by a human. That'd be if they had a false discovery rate of 1/10,000."
That distinction is the one to internalise. A false positive rate answers "how often does this flag clean text," and a false discovery rate answers "given a flag, how likely is it wrong." Those two numbers diverge hard when genuine AI text is rare in the pile you are scanning, which is exactly the situation in most editorial workflows.
The second one is about who you are scanning, not how many.
"People mention Pangram has a low false positive rate, but usually such statistics are over a large population. […] But in your example you aren't checking 10 random works from an assortment of authors. You are checking 10 works from one author. […] all it might take for them to get most of them flagged even if they are 100% human written is for that author to have some style choice, like those 3 bullet point sections, that they just use in much of their writing."
A per-population error rate says nothing about a per-author error rate, and errors correlate with style. Pangram's published statistics do not answer this, and to be fair to Pangram, no detector's do. Spero himself narrows the marketing claim when pushed, describing benchmarks on public datasets that put the false positive rate "roughly around 1 in 10,000" in his own HN reply, which is a different number from the model card's headline and honest about being one.
There is a well-put version of what the tool is good for that I keep coming back to:
"The most reliable automatic detector right now must be https://www.pangram.com/. If Pangram says something is AI, it is very likely AI. Sometimes it concludes more unusual AI text is human-written"
Trust the positives more than the negatives. That asymmetry is baked into the published numbers, where the false negative rate is roughly 80 times the false positive rate, and it is a better mental model than any single percentage. It is also not unique to Pangram, it falls out of how detectors work in general: they are tuned to avoid accusing innocent text, and the cost of that choice is missed AI.
How I would deploy it
Detector last, never first. If you have independent reason to think a piece is machine-written, a scan can support that, and the per-segment view will tell you where. Starting from the scan and working backwards is how people end up arguing with a probability.
Look at patterns rather than single results. One flag across ten pieces from the same author is noise. Eight out of ten is a conversation, and the sane version of that argument was made on HN better than I can make it here.
Scan whole documents, not chunks, so the 512-token windowing stops producing contradictory colours on the same paragraph.
And keep the categorical limit in view, which the teaching side of this debate articulated years before the SEO side caught up:
"Ultimately they're black boxes. You don't really know what causes false positives/negatives. You get a number and hopefully its correct, but it's not like something that scans for plagiarism because with that you have the original source that you can refer to and make more insightful decisions on."
Plagiarism detection produces a source you can open. AI detection produces a probability you cannot audit. Pangram 4's per-segment output is the closest anyone has come to closing that gap, and it still is not the same thing.
For a content team specifically, that pushes the useful work upstream. A detector tells you which paragraphs read as machine-written; it does not tell you whether the piece answers the query, and those two facts are unrelated. Which is why I would spend the effort on making content sound human through real editing and on adding personality rather than on chasing a score.
The various humanization tools largely optimise for the number instead of the reader, and Pangram 4's dedicated humanizer head exists precisely because that category got popular. Surfer's humanizer is the one I get asked to compare against most, and my honest read is that better input prompts beat any post-hoc rewrite pass.
If you are choosing a detector at all, my comparison of detector software options and my notes on Grammarly as an AI-assistance source are the neighbouring questions. And if your worry is search rather than authorship, the honest answer lives in does Google penalize AI content, because the two things are measured differently and always have been.
For anyone doing this at organisational scale, the governance version of the same discussion is scaling SEO content safely. A detector is one control in that system, not the system.
Try eesel for the draft, not the detector
Pangram 4 grades the draft you already have. It has no opinion on whether the research was any good, and after watching a lot of drafts go through that gate, the drafts that clear it easily are the ones that were properly researched and properly edited in the first place. There is no shortcut where a thin post passes because you found the right phrasing.
That is the job eesel does. eesel researches a topic from primary sources, writes with brand voice training, builds the internal link graph, and hands over a draft an editor finishes rather than rescues. The same pipeline produced this post, detector gate included, which is about as honest a demo as I can offer. Try eesel free, or see the automated loop running keyword to publish.
If you want the mechanics before the pitch, how the writer works is the explainer, the pros and cons is the fair version, and how I test one is the method I would use on any tool in this space, including ours.
Where to go next depends on where you already are. Still comparing tools? My AI blog writer review is the head-to-head, and writer examples show output before you commit to anything.
Already publishing at volume? Then the constraint is rarely the drafting, it is the review loop, which is what blog writing automation and production speed are about.
And if the drafts are clean but the traffic is not, that is a different problem entirely. I wrote up the ranking gap separately, along with the E-E-A-T angle that usually turns out to be the real cause.
For the wider survey, there is my roundup of AI content generators and a shortlist of AI writer tools.
If ranking is the only metric that counts, start from the SEO-first angle instead. My own drafting workflow is written up too, for anyone who would rather copy a process than buy a product.
Frequently Asked Questions
What is Pangram 4?
How does Pangram 4 work?
Is Pangram 4 free to use?
What languages does Pangram 4 support?
What is the difference between AI-generated and AI-assisted in Pangram 4?
Can Pangram 4 detect AI images?
What text is Pangram 4 not designed for?
Is Pangram 4 accurate enough to accuse someone of using AI?
Article by
Alicia Kirana Utomo
Kira is a writer at eesel AI with a Computer Science background and over a year of hands-on experience evaluating AI-powered customer service tools. She focuses on breaking down how helpdesk platforms and AI agents actually work so that support teams can make better buying decisions.
