How we reviewed this: we loaded the unpacked extension into Chromium in a container, read its settings through its own message handlers, ran its test file, and read the request construction. We did not run it against x.com — we don’t test on other people’s sites — so the on-page behaviour is read rather than observed.
What it does
A Chrome and Firefox extension that runs your draft X post through Jev before you publish and renders a scorecard under the composer: virality, funniness, informativeness, clarity, insult level, ragebait, cringe, “sounds AI-written”, regret risk, typo detection, the most likely crowd reaction, and an overall verdict — “Send it / Fine, mid / Probably don’t / Sleep on it”.
The rubrics are data, not code: a JSON list you can edit in the options page, each entry a question and a type. That is the right way round for something this subjective, and it means the scorecard you get is the one you asked for rather than the author’s taste.
Permissions worth reading
"permissions": ["storage"],
"host_permissions": ["https://api.typesafe.ai/*", "https://api.openai.com/*"],
"content_scripts": [{"matches": ["https://x.com/*", "https://twitter.com/*", "https://pro.x.com/*"]}]
That is close to the floor for what this has to do: no tabs, no scripting, no <all_urls>, two API hosts and three X origins. Compare it with a browser agent like Jev for Chrome, which needs debugger and every URL, and you can see how much of a permission request is the job rather than the author.
One request per analysis carries the draft and its context — the tweet you are replying to as reply_to, a quoted tweet as quoting — plus the rubric questions.
The second host, api.openai.com, is for describing images: when a draft carries media, a vision model is asked what the picture shows so the rubrics can score it. That means images from the compose view — including from the tweet you are replying to — leave for OpenAI.
It is opt-in by key, but not by toggle. We loaded the extension with only a Jev key configured and asked it for its settings through its own handler:
defaults, only a Jev key: {"describeMedia": true, "hasOpenAI": false}
after adding a vision key: {"describeMedia": true, "hasOpenAI": true}
describeMedia defaults to on. Without an OpenAI key the describe path throws NO_OPENAI_KEY and nothing is sent, which is why nothing leaks today. But the moment someone pastes a vision key into the options page, image sending is already enabled — there is no separate “and also send my images” step. Defaulting that to off, or prompting once on the first image, would make the choice explicit.
While you are in there, note that auto-analysis is on by default too, with a 1,200 ms debounce: your draft goes out as you type, not when you ask.
Engineering
Thirteen tests, all passing, covering the background script’s rubric handling and error paths. Errors come back as readable strings — we pointed it at the real API with a deliberately wrong key and got TypeSafe: invalid API key (401). Check it in Vibe Check settings. rather than a stack trace. Retries use backoff. The extension is plain JavaScript with no build step, which makes it easy to audit in an afternoon.
Five commits, created 18 September, and no licence file, so strictly nobody may reuse it.
Verdict
The nicest small extension in this batch: a real use for a decision model, a scorecard you can rewrite, and a permission list you can read out loud. If you post often and have ever regretted one, it is worth the ten minutes.
Before you add a vision key, decide whether you want images from your compose view going to OpenAI, because the extension has already decided yes. And ask the author for a licence.
For the same idea pointed at a conversation rather than a draft, see Crush Monitor; for an agent that drives the page instead of scoring it, Jev for Chrome.
See how it compares with other tools in Best Jev tools, tested hands-on.
Review updated Sep 21, 2026. Numbers quoted from the project are its author's own; we don't publish our own measurements of Jev.