Chrome 157 is on the kernel. Moving a profile two majors at once.

The AntiBrow kernel now has a Chrome 157 build, and there is no 156 build before it: the series goes from 155 straight to 157. Chrome 156 went stable on 2026-10-07 and 157 followed on 2026-10-22, about two weeks later, so a 156 build would have been on its way out almost as soon as it shipped.

For anyone who moves profiles forward, that skip raises two practical questions. Does a two-major jump look suspicious? And should the missing number be filled in by hand so the history looks continuous? The short answers are no and no, and the second one matters more.

A skipped major is what an idle laptop does

Chrome's updater does not walk through versions one by one. When it runs, it fetches whatever is current, and the browser switches to it on the next restart. A laptop left closed for a few weeks wakes up and lands on the current major directly; the ones in between are never installed on that machine. The same happens to anyone who dismisses the restart prompt for long enough.

So one profile reporting 155 on Monday and 157 a week later reads as a browser that was not restarted for a while. That is unremarkable on its own. What is not unremarkable is a batch of related profiles making the same jump in the same hour, which is why moves should still be spread out, as the first release note explains.

Do not invent a 156

The tempting fix is to make the series look continuous: give a few profiles a 156 user agent on top of a 155 or 157 build. This creates exactly the kind of contradiction detectors are built to find.

The version string is not stored in one place. It appears in the User-Agent header, in navigator.userAgent, in the low-entropy client hints sent on every request, and in the full version list a page can ask for:

const { fullVersionList } = await navigator.userAgentData
  .getHighEntropyValues(['fullVersionList'])

On the wire, a request from a 157 build carries a header like this one, and the major in it has to match the one in the user agent:

sec-ch-ua: "Chromium";v="157", "Google Chrome";v="157", "Not-A.Brand";v="24"

Behind all of those sits the engine itself. Each major ships web platform changes and new defaults, and a script can test for them directly instead of reading any label. A browser whose header says 156, whose feature set says 157 and whose high-entropy hints say something else again is not a browser anyone has ever installed. The kernel keeps every one of these surfaces on the build it actually runs, and a hand-edited version string can only break that agreement, never improve it.

Moving a profile and checking the result

Try the new major on a throwaway profile first, as in the Chrome 155 note. Then move real profiles one at a time:

import { setProfileKernelVersion } from 'anti-detect-browser'

await setProfileKernelVersion({ profileName: 'shopper-01', version: '157' })

Only the browser build changes, and with it every place the version is reported. In the desktop app the same switch is in the profile's settings.

After the first launch on 157, open a page in the profile and compare the three readings: navigator.userAgent, navigator.userAgentData.brands, and the fullVersionList above. All three should name 157. If any of them disagrees, stop and do not move the next profile until you know why.

Packages arrive per operating system. If a fresh profile on your machine still reports 155, the 157 package for that system is not in the release manifest yet, and new profiles there keep getting the newest build that is until it lands.

When this release is not for you

Sometimes the right answer is not to move at all, and sometimes it is not to use us.

If a profile is in the middle of something that matters, such as a payout, a verification or an appeal, leave it alone until that is over. A browser update is a small change, but it is a change, and there is no reason to stack it on top of a sensitive session.

If you do not run separate identities, stock Chrome is the better tool. It moves to 157 on its own, every surface listed above agrees by construction, and it costs nothing. The case for managing versions per profile only exists when many identities must not be linked to each other, and even then the proxy and the account history explain far more challenges than the browser version does.