CheckCC claims 40 plus signals and names six, and its example table is empty

The example detection table has a header and no rows

The most telling artefact in this repository is a table with two columns and no content. Under a heading that introduces sample detection metrics, the table declares its columns as detection principle and the region under key detection, then stops. There is a header row and a separator and nothing after them.

The screenshot section above it is equally bare. The project describes itself as a detector for account restriction risk, subscription failure risk and API application risk, and then shows no screenshot of any of it, in a repository where the surrounding markup reserves space for images that are not there.

A feedback group table follows the same pattern, listing a second group and leaving the cell empty rather than carrying a link or an invite code.

None of this means the detection does not work. It means a reader deciding whether to trust a risk score for their own account gets no worked example of what a passing or a failing result looks like. For a tool whose entire value is a judgement about consistency between signals, the demonstration of the judgement is the product, and it is the part that is missing.

Forty plus signals in the summary, six dimensions in the detail

The feature list leads with 40 or more environment signals detected with risk prompts, and the technical section says the project has 40 or more environment detection dimensions built in. What it then names is six.

Those six are browser language, judged against whether the browser's preferred language matches the region in use; system timezone, matched against the same region profile; Intl Locale, which checks whether the JavaScript internationalisation environment exposes an unusual language or region; User-Agent, parsed for browser, system and client container characteristics; the running container, looking for WebView, automation or abnormal client features; and a consistency check that weighs language, timezone, region and browser environment against each other.

Five aggregation methods are described for combining them: client-side environment sampling, server-side request analysis, IP intelligence identification, runtime feature identification and signal consistency verification. So the shape of the system is a client sample plus a server-side view plus an IP lookup, aggregated into one consistency judgement.

The arithmetic between the headline number and the itemised list is the first thing to ask about. Either the remaining dimensions are variations that do not warrant naming, or they exist and are not described, and the two cases call for different amounts of trust in a number.

Local-only detection and server-side request analysis describe two different products

The privacy section is a list of things the project says it does not do: it does not require logging into Claude, does not read the Claude account, does not read a password, does not read cookies, does not read chat content, and does not upload detection results by default. The framing is that the project does browser-local environment detection by default.

The technical section names two of its five methods as server-side request analysis and IP intelligence identification. IP intelligence cannot be done from the browser without disclosing the address to whoever answers the request, so the hosted site at checkcc.org necessarily observes the IP of every visitor who runs a check there. That is not a criticism of the project, since observing the requester is what a server does, but it means the local-only description applies to a self-hosted deployment and not to the hosted one, and the README presents them in the same voice.

The deployment options sharpen the point. Self-hosting is offered on Vercel, Cloudflare Pages, Netlify or your own server, and all four are places where the check runs as a page that calls a server. A project whose value is telling you whether your environment looks inconsistent needs the vantage point of the network you are actually on, which is a server-side measurement by definition.

The honest summary is that the browser supplies the fingerprint signals and the server supplies the network and IP context, and only the first half is local.

The package manifest is still at 0.1.0 after three 1.x releases

The published tags are v1.0.0 on 2026-07-07, V1.1.0 on 2026-07-11 and v1.1.1 on 2026-07-22, the last titled as improvements to the startup workflow and deployment experience. The manifest in this repository declares `"version": "0.1.0"`. Three 1.x releases have shipped and the package version never moved, and the middle tag is written with a capital V while the other two use a lowercase v.

The rest of the manifest is specific. Next.js is pinned at 16.2.10 with React and React DOM at 19.2.4, Tailwind CSS at major version 4 with its PostCSS plugin, TypeScript at 5, ESLint at 9 with the matching Next config, and `engines` requiring Node 20 or later. The scripts are four: `next dev`, `next build`, `next start` and a bare `eslint` with no path or rule arguments.

The documented quick start is two commands, and the page then serves on port 3000:

pnpm install
pnpm dev

There is no test script, and no test directory is listed at the top level either, in a project whose output is a risk judgement about somebody else's account. A tool that scores consistency can be wrong in ways that matter, and nothing in the manifest suggests its scoring is checked automatically.

The tree also carries `pnpm-workspace.yaml` and a `.npmrc` in what is otherwise a single package, plus a `shell/` directory that has no obvious role in a browser-side detector.

MIT, and then attribution conditions MIT does not contain

The licence is stated as MIT with copyright to yacuo and CheckCC, and the README says you may freely use, modify and redistribute the project. That part matches MIT.

The next paragraph goes further. It requires that any copy, secondary development version, self-hosted site or substantial part of the project must retain the original copyright and licence notice and cite the source, and it asks that anyone redeploying the project keep the footer signature or the repository link so visitors can find the original. The project description section repeats the same instruction for anyone doing secondary development, redeployment or a derivative release.

A mandatory footer credit is not an MIT term. MIT asks you to keep the licence and copyright notice, and it does not ask you to advertise the origin in your user interface. What the README describes is MIT plus an attribution requirement on the deployed artefact, which is a licence the SPDX identifier does not describe and which a downstream operator has to honour by reading the README rather than the LICENSE file.

For a self-hosted project that invites forks, that difference matters more than it would for a library, because the visible credit is the part people drop first.

The repair tool is announced, three platforms, and gated on stars

The roadmap item is a desktop application for one-click environment repair, described as coming soon, in private beta, for macOS, Windows and Linux, and it is the half of the product that would act rather than report. The detector is open source and in the repository; the repair program is not.

The announcement asks readers to star the project to receive the repair program and its updates first, and states that it is free on all three platforms. That is a reasonable way to grow a user base before a release, and it is worth noticing that the part of the tool with the higher stakes is the part that is not in the tree.

Development is funded by a sponsor. The README states that the project's development resources and AI token consumption are sponsored by tokenplan.vip, described as a global AI token price comparison site. So the running costs of a checker that makes server-side requests on your behalf are being covered by a third party, and the hosted site is the thing that sponsor is paying for.

The stated audience for the whole project is learning, secondary development and self-hosting, and the four listed use cases are studying browser environment detection, researching Claude runtime risk prompts, standing up a personal detection page, and using it as a base for further open-source work.

The advice list is where this project should be read most carefully

A section titled how to lower the risk of account restriction lists concrete habits: keep the IP, system timezone, browser language and account region consistent; avoid frequently switching country, proxy node, device and browser environment; avoid logging in from a WebView, an automated browser, an abnormal client or an unstable container; check the environment before subscribing to Claude Pro, applying for the Claude API or using Claude Code; adjust the environment before continuing if high-risk signals are detected; and prefer a long-term stable network egress and a consistent device environment.

This article does not reproduce that as a procedure, and the reason is worth stating plainly. Each item is only innocent under an assumption the tool never checks, namely that the person is entitled to access Claude from the region they are in. A user on a VPN, or in an automated browser, or hopping nodes, is exactly the case the list is written for, and following it does not resolve the entitlement question, it only removes the signal that would reveal the question. That makes the list advice for looking like something other than what it is.

The project itself does not claim more than a prompt. It states that the signals cannot prove an account is safe or will be restricted, that the results are for reference only and do not represent an official judgement from Claude or Anthropic, and that the results should not be the sole basis for a decision about account safety, subscription status or an appeal. That disclaimer is the correct reading of everything else here, and it should be read before the score, not after it.

The last commit on the default branch is dated 2026-08-03, and the repository is not archived.

Editorial conclusion

Treat this as a browser environment sampler, not as a verdict, which is exactly how the project describes it: no login, no account read, no cookies, and no official standing with Anthropic. Three things to check before relying on a score. The gap between the 40 plus signals claimed in the feature list and the six dimensions actually named, since the rest are not itemised anywhere visible. Whether the privacy claim survives contact with the hosted site, since the technical section names server-side request analysis and IP intelligence while the privacy section promises local-only detection. And the licence, which is MIT and then adds attribution conditions MIT does not impose. If you want to know whether a specific environment reads as consistent, read the dimensions yourself rather than trusting a label.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. yacuo/check-cc on GitHub