Chrome's major updates now arrive every two weeks instead of every four. Version 153 is the first release on the new schedule, and the change applies to desktop, Android, and iOS alike. The goal is not only to ship features sooner. It is to shrink the gap between the moment a fix becomes public and the moment it reaches the people running the browser.
The four-week gap is cut in half from 153 onward
Chrome had been shipping a new milestone every four weeks since 2021. In 2023, weekly security updates and an early stable release for a subset of users made the update rhythm finer still. This change continues in the same direction, halving the interval between major milestones themselves.
Desktop, Android, and iOS are all covered. The Dev and Canary channels are unchanged. Beta now ships three weeks ahead of stable, so anyone running a site or a web app can still check behavior in advance.
Because each release carries fewer changes, the individual updates are smaller. That has a useful side effect: when something breaks, there is less ground to search.
The calendar has shifted forward by two to four weeks
Dates across the schedule moved earlier all at once. Version 153's stable release had been planned for September 22, but it actually shipped on September 8. The branch point moved from August 24 to August 17, and beta promotion from August 26 to August 19.
Version 154 moves further still. Its stable release would have landed on October 20 under the old cadence; it is now September 22, roughly a month earlier. From there, milestone numbers advance every two weeks. Anyone who used the version number as a rough clock for "time to update" will need to recalibrate.
Behind it: the volume of vulnerabilities AI has turned up
The decision to tighten the interval follows a sudden increase in bugs that need fixing. Chrome's security team had been using large language models for vulnerability research for years, but an agent harness built on Gemini in early 2026 raised the efficiency of that search by a wide margin. One of its finds was a sandbox escape that let a compromised renderer trick the browser into reading local files, a flaw that had sat in the codebase for more than 13 years.
The numbers show up in versions 149 and 150. Those two milestones alone accounted for 1,072 security bug fixes, more than the previous 23 milestones combined. Reports from outside researchers rose as well; by March 2026, the volume received had already passed the total for all of 2025.
When that much comes in, the intake side has to be automated too. Triage that once took anywhere from 5 to more than 30 minutes per report has been replaced by a pipeline blending rule-based checks and machine judgment, covering duplicate and spam filtering, reproduction, severity assignment, and routing to an owner. Candidate fixes are now shaped by a generating agent and a critic agent trading passes in something close to a code review.
The race with attackers starts the moment a fix goes public
Once a fix lands in open source code, anyone can read it. Attackers can work backward from the diff and strike before the update spreads, the pattern known as an N-day attack. Patch gap, the term for the delay between a fix landing and reaching stable, is the width of exactly that window.
A two-week major cadence is one move to narrow it. Weekly security updates continue as before, and a pilot is under way to push those to twice a week.
One step further out, the remaining problem is the time until a user restarts the browser. Updates download quietly and wait, but they apply only after a restart. Everyone has reasons not to interrupt what they are doing, so this part does not compress easily. Work on it includes dynamic patching, which swaps background child processes one by one to remove the need for a full restart, and a behavior on macOS that detects when no windows are open and restarts automatically.
Extended Stable stays on eight weeks for enterprises
Faster updates create problems for some environments: companies that validate compatibility with internal systems before rolling anything out, and vendors that embed Chromium in their own products. For them, Extended Stable keeps its existing eight-week interval. Chromebooks likewise continue to receive releases only after dedicated platform testing.
Administrators have levers of their own. A policy that escalates restart prompts over a set period keeps pending updates from sitting untouched. Where validation matters most, Extended Stable is the channel to pick, and a management dashboard shows which version each machine in the fleet is running.
Summary
With version 153 on September 8, Chrome shortened the interval between major updates to two weeks. Faster features are the visible change, but the point is closing the gap between a security fix becoming public and landing on a user's machine. Now that AI turns up vulnerabilities by the order of magnitude, fixing quickly is not enough unless delivery keeps pace. The shortest move available on the user's side is simple: when an update is waiting, restart the browser once.
