A browser-based AI checker is a program you run, not a service you call.

When you paste text into the console, nothing is interpreted by a language model. The page loads a set of functions, each of which knows one way that generated work tends to fail: a credential assigned in source, a statistic with no source next to it, a heading structure that skips a rank.

Each function reads the input, applies a test, and returns zero or more findings with an identifier, a severity and the text that triggered it. The findings are de-duplicated, sorted and weighted into a score. All of it is arithmetic and pattern matching, which is why it is possible to explain every number in the report.

That is also why there is no cleverness to be impressed by. A rule engine is predictable in the way a linter is predictable, and predictability is the feature.

For text, the work is string handling: regexes over a few hundred thousand characters, line splitting, counts, averages of sentence length, checks for balanced brackets, and an attempt to parse code as JavaScript so a syntax error surfaces as a finding rather than a stack trace.

For documents, the same pass adds structural parsing: Markdown headings and their ranks, CSV rows split by comma with a check that every row has the same column count, JSON fed to the browser's own parser.

For images, the file is decoded by the browser's image decoder and drawn to a canvas, which is how dimensions, average luminance, contrast and a rough sharpness measure can be computed without a server. The bytes are inspected for provenance containers and for metadata strings naming a generative tool.

There is no temperature setting and no sampling. A rule either matches or it does not, so re-running a check on the same text returns the same findings in the same order and the same grade.

This is the property that lets a report be attached to a pull request, a campaign sign-off or a client deliverable without a caveat. If somebody disputes it a week later, they can run the same text through the same version and get the same page.

It also makes the report comparable across a library. Running a hundred published pages through one rule set tells you something real about the pipeline that produced them, which is not true of scores produced by a model whose judgement shifts between runs.

The tab sees what you give it. It does not know your dependency graph, your type definitions, your repository history or whether an imported module still exists. It cannot follow a link to see whether it resolves, and it cannot compare two files.

Generated code is exactly the kind of output where cross-file context matters, which is why the honest answer is that the console covers a large share of the mechanical defects and nothing beyond them. Duplicated logic across three files, an interface used inconsistently, a migration that contradicts a model, all of that needs a reader.

The report leans into this rather than hiding it: it lists how many checks ran and stops. What is left over is a job for engineering judgement, not for a bigger regex.

Start from the severity rather than the count. One critical finding outweighs a dozen low ones, and the score is weighted that way on purpose, so a long tail of style notes cannot bury a credential.

Then read the rule. Each finding names the pattern it matched and the line it matched it on, which means you can agree or disagree on the evidence rather than on the tool's authority. Disagreement is useful: it tells you where your house conventions differ from the published rule set, and that is the kind of thing a named reviewer can adjudicate.

Finally, decide what the finding costs. A leftover console statement is a minute. An unescaped interpolation is a category of vulnerability. The report gives you the raw material for that judgement; it does not make it for you.

Keep it local when the material is sensitive, the answer is needed immediately, or you are checking something you would not put in a ticket: a prototype, a fragment from a prompt, a vendor's code you are evaluating, a page that has not been approved for release.

Move it to a server or a person when the question needs context the tab does not have, when the work is going into production with real risk attached, or when the evidence has to be defensible to a third party who will ask who reviewed it and what they found.

Those two modes are complementary rather than competitive, and the handover is cheap because the automated report travels with the request.

The cost of a check is not only money. A server-side grader with a queue and a cold start turns verification into a task you schedule, so it happens once, at the end, when changing anything is expensive and the only remaining options are ship or delay.

A check that answers in the time it takes to read a paragraph gets used differently. It runs on the second draft, on the fragment pasted out of a chat window, on the paragraph that felt wrong, on the file someone else wrote. The gate stops being a ceremony and becomes part of how the work is written.

That behavioural difference is the real argument for client-side analysis, and it is not a marketing claim. A team that checks five drafts learns more about its generative pipeline than a team that checks one release, because the failures repeat and the repeats are visible.

There is a performance ceiling, and it is worth knowing. A tab will happily scan a very long document, but the console caps input at 200,000 characters so a careless paste does not freeze the page, and image work is bounded by the file's weight rather than by any server quota. Within those bounds the answer is immediate, which is what makes the habit stick.