Mantis

Mantis

Sees 12 color channels. You see 3. Your coding agent sees 0.

English · Tiếng Việt · 简体中文

▶ Watch the 60-second intro (MP4, 4 MB) · 1080p

---

Your coding agent builds UI with its eyes closed. It writes the CSS, says "Done ✅", and never opens the browser.

Then someone opens the page on a phone:

• the menu runs off the screen;
• in dark mode one card is still white, with white text on it;
• the Vietnamese button label is cut in half.

Mantis catches the UI bugs your agent can't see, and the ones it hides. It:

1. opens the real app;
2. checks every screen size, both themes and every language you ship;
3. boxes what is broken in red;
4. fixes it at the root, and flags any "fix" that only hides the bug;
5. proves it with before/after screenshots;
6. measures how fast it is on a slow phone, ranks the fixes, and catches speed-ups that only remove content (from v0.6).

What it catches

How it works

1. Look. /mantis runs the app through every screen × theme × language in a real browser and writes a report the agent reads, with annotated screenshots.
2. Fix. /mantis-fix fixes causes, not symptoms. It never puts overflow-x: hidden on the body, shrinks text until it fits, or turns dark mode off, and the next run checks that it didn't.
3. Prove. /mantis-proof makes a before/after sheet, a close-up of one fixed finding, and optionally a video, for your pull request.
4. Speed. /mantis-perf measures the page like a phone on slow 4G, fixes what slows it down in order of impact and risk, and checks that the page got faster, not emptier (see below).

mantis look http://localhost:3000 --routes /,/settings --locales en,vi

Each language cell sets the browser locale and Accept-Language. Many apps pick their language another way, and --locale-strategy handles that (from v0.5):

A language whose page text comes out the same as the first one is reported as "not localized". That usually means the strategy is wrong.

No translations yet? Add the pseudo-locale (from v0.5): --locales en,pseudo. That cell loads the first language and rewrites every visible string the way translations grow. "Subscribe" becomes [Šûƀƀšççŕîîƀéé]: accented, about 40% longer, and bracketed, so a missing ] shows the end was cut. Text the app renders later is rewritten too. Code, form input and translate="no" content are left alone. The pseudo-locale finds layouts that break with longer text. It can't tell which strings are hard-coded, because it rewrites them all.

Right to left. Arabic, Hebrew, Persian and Urdu pages start at the right edge and overflow to the left. Mantis checks them the same way, mirrored. It also reports an error when such a page is laid out left to right because dir="rtl" is missing. To see how an app without those languages would cope, use --locales en,pseudo-rtl: the pseudo-locale, laid out right to left (from v0.5).

Fixed, or just hidden?

An agent told to make the report clean can make it clean without fixing anything. Every mantis look compares itself with the previous run of the same URL, so these tricks don't work:

A cover-up is an error, so the run still fails. When the fix is honest, the run ends with a receipt:

Mantis: 0 errors, 0 warnings in 24 cells

vs 2026-10-29T11-51-22: 18 fixed · 0 new · 0 cover-ups · 0 lost

Faster, or just emptier? (mantis perf, from v0.6)

Ask an agent to make a page faster and it may remove the hero image, cut the list to five rows, or lazy-load what the first screen shows. The numbers get better, and the page gets worse. mantis perf measures the page, says what makes it slow down to the line of code, ranks the fixes by impact and risk, and fails the run when a "speed-up" only removed content.

mantis perf http://localhost:4173 --routes /,/pricing

Measures like a phone. Every route gets N cold visits (--runs 5 by default) in Chromium. The default profile is a mid-range phone on slow 4G: 4× slower CPU, 562 ms round trips. --profile desktop turns the throttling off. You get the median and spread of LCP, FCP, TBT, CLS, TTFB, when the API data was in, bytes and requests. A development server is called out, since its numbers are not what users get.

One more visit runs without throttling, because throttling hides what it touches:

• the server's real wait per request;
• a CPU profile that names the functions the main thread spent its time in;
• coverage of the code that never ran.

Says what to fix, ranked. perf.md starts with the fixes:

Each fix names a culprit the agent can open. That is a selector, a URL, or file:line with the function and its callers (loadConfig /app.js:4 ← main /app.js:51). It also gives the metric the fix moves with an estimated saving and how sure that estimate is, and the detected framework's own way to fix it (Next.js, Nuxt, Angular, Vue, React, SvelteKit). It finds:

• an LCP image that is lazy-loaded or found late;
• images much larger than they are drawn;
• files in that hold the first paint;
• functions that hold the main thread;
• code that never runs;
• fonts that hide text;
• layout shifts and what caused them (an image without a size, a banner inserted above, a list filled late);
• a slow HTML response.

Slow APIs. Every API call is traced to the code that made it. Mantis finds:

• endpoints that are slow on the server;
• calls that wait for each other;
• the same call made twice;
• one call per item (N+1);
• large JSON;
• a first call that starts late, with the script it waited for.

Third parties. Grouped by vendor (Google Analytics, Intercom, YouTube, Stripe and about 50 more): their bytes, main-thread time, render-blocking files and iframes. Each kind gets its fix: a facade for chat and video, analytics after the page is interactive, self-hosted fonts. Whether a costly vendor is worth it goes under "Your call".

A receipt you can trust. Run it again after a fix and it compares itself with the previous run of the same URL and profile:

vs 2026-10-30T12-32-02: LCP 2.5 s → 36 ms · TBT 121 ms → 0 ms · CLS 0.164 → 0 · transferred 551 KB → 354 KB · 11 fixed · 0 new · 0 cover-ups

A change counts only beyond the noise, meaning both runs' spread. Anything else is shown as ≈. A route that got faster because its LCP image, its text, its first-screen images, headings or controls went away is a cover-up error: "Faster, or just emptier?". Findings that left with the content are not counted as fixed.

Is this Lighthouse? Lighthouse scores a page. mantis perf is built for the agent loop:

• a culprit down to the function and the call stack;
• fixes ranked by risk as well as impact;
• API and vendor findings with their fixes;
• medians over several cold runs;
• a before/after receipt that refuses to count removed content as a speed-up.

Numbers

What has been measured so far:

• Planted bugs. fixtures/buggy-app has 13 planted UI bugs, listed in PLANTED.json. Mantis reports every one of them in exactly the screen, theme and language cells where it was planted, and nothing else. On fixtures/clean-app, the same app with every bug fixed, it reports zero issues. Both checks run in CI.
• Cover-ups. Four tricks applied to buggy-app behind the same URL (hide the overflow with overflow-x: hidden, hide the menu button, hide the button it overlaps, shrink a label to 7px) are all still reported or flagged as cover-ups. Swapping in