Chrome 154 is on the kernel. How far behind can a profile fall?

Chrome 154 reached the stable channel on 2026-09-09, and the AntiBrow kernel now ships a build of it. New profiles pick it up as soon as the package for their machine is in the release manifest. Existing profiles stay where they are until you move them.

The previous release note argued against moving every profile on release day, because a brand new major is a thin bucket and a synchronised jump across related profiles is a signal. That argument has a mirror image, and it matters more over a long enough timeline.

Real Chrome does not stay put

Desktop Chrome updates itself in the background and applies the update on the next restart. Most people never think about it. The practical effect is that the population of real browsers on any one major is not stable: it rises for a few weeks after a release, peaks, and then drains steadily into the next one.

A profile does not drain with it. It reports whatever version it was pinned to, indefinitely. On the first day that is unremarkable. Two majors later it is in a bucket that real users are actively leaving. Several majors later it is in a bucket made mostly of machines that cannot update: managed fleets with updates held back, abandoned installs, and automation that nobody maintains. That last group is exactly the company you do not want to keep.

No serious scoring model blocks on version age alone. It is a weight, not a rule. But it is a weight that only ever moves in one direction for a pinned profile, and it compounds with everything else that is slightly off.

The packages do not all land the same day

A new major is built and published per platform package, and those packages do not arrive at the same hour. A profile created on one machine can get the new major while a profile created the same afternoon on another machine gets the previous one, simply because that package was not in the manifest yet.

That is fine, and it is closer to how real Chrome behaves than a single global switch would be: Google stages rollouts too. It does mean you should check what a new profile actually reports rather than assume. In the desktop app the browser core page lists what is installed and what is available for your machine.

A cadence that holds up

Something like this works for most setups:

• Leave new profiles on whatever they get. That is the newest build for your machine, which is what a fresh install of Chrome would be.
• Move existing profiles in small batches, spread over a few weeks after a release, not on the day.
• Do not let any profile fall more than a major or two behind the current stable. Past that, the version starts to describe a kind of machine rather than a person.
• Move a profile when you are about to rely on it for something that matters, not in the middle of a session it is already in.

Moving one is a single call:

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

await setProfileKernelVersion({ profileName: 'ads-us-east', version: '154' })

The version is the only thing that changes. The rest of the identity, the cookies and the stored logins move with the profile as they are, which is what a real Chrome update looks like from the outside too: same person, same browser, newer build.

When none of this is worth paying for

If you run a single browser for yourself, your real Chrome already handles this perfectly and for free. It updates on its own schedule, and what it reports is what it runs. The reason to manage versions by hand is managing many separate identities that must not link to each other. Without that, you do not need an antidetect browser for this, and you should not buy one for it.

And a fresher major does not repair a profile that is failing for another reason. Proxy quality, account history and behaviour explain far more challenges than version age does. The dated detection runs show which signals actually moved results, and the consistency walkthrough covers what else has to agree before a version number is worth worrying about.