How to detect Kameleo in 2026
Kameleo is a desktop antidetect browser: a fake browser that gives every profile its own device fingerprint. It runs two engines of its own, Chroma for Chrome and Junglefox for Firefox, and takes orders from Selenium, Puppeteer and Playwright scripts. Every profile it launches claims to be a different, ordinary device. Maskbreak does not take that claim at face value: its device check tests whether the browser is consistent and whether a script is driving it, and its network intelligence looks at the connection the visit came from.
What Kameleo is
Kameleo is made by Outis Nemo Ltd. (site footer, checked September 2026). Its engines are its own builds, and several kernel versions can run side by side. The company promises a new Chroma within five days of each stable Chrome release, and Chrome now ships every two weeks. Mobile profiles are emulated browsers inside the same desktop app; the separate mobile app was deprecated in version 4.0 (April 2025).
The homepage promises “Undetected Automation at Scale” (its claim), and the pitch now leans toward web scraping and automation, though multi-accounting is still in the page title (kameleo.io). It works with existing Selenium, Puppeteer and Playwright scripts, has a local API with SDKs for Python, JavaScript and C#, and ships official Docker images for Linux and Windows. Version 5.0.0 (16 June 2026) added an accountless mode, so a profile can launch without a Kameleo account; the newest release when we checked was 5.2.1 on 3 September 2026 (release notes).
Plans are sized by how many browsers run at once, not by profiles alone. The free plan runs 2 browsers at once, with 100 cloud profiles and 300 minutes of browser time, and profiles can also be kept locally. Paid plans cost €59, €299 and €1,499 a month billed monthly, or €45, €225 and €1,125 a month billed annually (pricing, September 2026). None of this is secret, and it tells you what a Kameleo session will try to be: a believable ordinary device, often driven by a script.
How Maskbreak checks a Kameleo session
Maskbreak keeps no list of antidetect brands and never names the product. The device check asks whether the browser a session claims to be holds together and whether a machine is driving it. The network check looks at the address it arrived from. A Kameleo profile has to get past both on every visit.
device.antidetect is true, the reason antidetect_browser is added and the answer is block by default, the same as for a proxy, Tor, automation or an emulator. It flags the class of tool, not Kameleo by name, and a new Chroma build can change what the check sees.device.tampering_score is a 0–1 number from the device check, not a probability of fraud. On our bench it stayed near zero on spoofed profiles while the antidetect flag fired, so do not build a threshold on it. Route on decision and reasons.device.automation is true, the reason is automation_detected and the default is block. It does not name the framework; bot detection covers this signal in full.emulator_detected and blocks by default. A virtual machine is reported as device.virtual_machine with the reason virtual_machine, and on its own it asks for review, never a block: plenty of developers browse from one.proxy_detected and blocks. A VPN on its own adds vpn_detected and is flagged for review, not blocked. A cloud-server address alone lists datacenter_asn and stays allow. network.service names the VPN or proxy operator when known. The network check does not depend on the device check.device.times_seen counts sightings in Maskbreak's shared device history, not only on your site. Send your own accountId and device.linked_accounts counts how many of your accounts this device has been used for; more than one adds multi_account_device. That reason does not change the decision unless you set a rule for it. Links stay inside your account, stored as one-way hashes.Kameleo's official Docker images can run a scripted profile on a rented cloud server. If one reaches your signup form with no proxy in front, the answer looks like this example response, trimmed to the fields that matter:
// example response, POST /v1/evaluate
{
"decision": "block",
"risk_score": 100,
"reasons": ["datacenter_asn", "antidetect_browser",
"automation_detected"],
"network": {
"vpn": false,
"proxy": false,
"datacenter": true,
"tor": false,
"residential": false,
"service": null
},
"device": {
"antidetect": true,
"automation": true,
"emulator": false,
"virtual_machine": false,
"tampering_score": 0.0029
}
}
The weights add up past 100 (30 for the cloud server, 35 for the fake browser, 40 for automation), so the score is clamped at 100. The cloud-server address alone would have been allowed; either device signal alone blocks.
How to integrate
Add the Maskbreak browser snippet to the form you want to protect: signup, login, checkout or a bonus claim. Your server forwards the two tokens it collects to POST /v1/evaluate with your API key and gets back decision, reasons and the network and device blocks. Start in watch mode, which logs every decision and lets the visitor through, and switch to enforce once the Events log looks right. The quickstart has the handler, the API reference lists every field, or hand integrate.md to your coding agent. For the technique, read the 2026 antidetect detection deep-dive; for the other products and who makes them, the antidetect browser guide. A June 2026 lab note ran one fresh Kameleo 4.5.0 profile against the live scanner: one profile on one day, not a detection rate.
Free plan: 10,000 visitor checks a month, no card. Paid plans from €29 a month.