Google Reportedly Internally Testing New Model Carbon: Employees Say Coding Close to Opus 5.5

According to an October 9 Business Insider report, Google employees recently began testing a Gemini 4 checkpoint codenamed Carbon on the internal coding platform Jetski. One employee involved in the testing believes Carbon's coding experience approaches Claude Opus 5.5, but also says more testing is needed. Google declined to comment on the leak.

The spread of this news comes from the phrase "approaches Opus 5.5," but its evidence level must be made clear: this is internal experience feedback, not a public evaluation conclusion. Carbon is also not a product name Google has officially announced, and gaps remain over whether users will ultimately be able to get this version and through what product they would use it.

Placed back into Google's recent product rhythm, its significance goes beyond "another model codename has appeared." From the already released Argon, to Antigravity, to work-oriented enterprise agents, Google is advancing three lines at once: model capability, execution tools, and work entry points. Carbon's potential value lies in whether it can provide more reliable coding capability for this layout.

Google officially released Argon on September 30, initially opening access only to some cybersecurity partners. According to the September 30 official introduction, Argon raised the output limit from the previous 64K to 1 million tokens; Google reports its DeepSWE v1.1 score at 77.9%. The model first opens to trusted cyber defenders through the Fairwind program, then gradually expands its scope of use.

There are two boundaries here that must be kept separate. First, 1 million tokens is Argon's announced output limit and cannot be conflated with the context tiers in the Antigravity testing interface. Second, Argon's DeepSWE v1.1 score cannot be transferred to prove Carbon's performance—one is official data for a released product, the other is an internal-testing rumor about an undisclosed version.

The report also says the internal version Barium-B was chosen as the model using the external name Argon, while how Carbon will ultimately be released remains undetermined. This means even "under what name and in what form Carbon will appear" still has no answer.

In an October 9 report, TestingCatalog pointed out that Antigravity has already shown an Argon model option and three context configurations of 256K, 512K, and 900K; the larger two tiers show quota consumption of roughly 1.3x and 1.8x per turn. At the same time, Gemini Web now supports low, medium, and high thinking-effort settings for all available models.

These changes can be understood as the platform preparing for Gemini 4's release, but restraint is needed: the interface configurations of Antigravity and Concierge are testing clues and cannot be directly regarded as final product specs. TestingCatalog also found that the not-yet-released Concierge agent has appeared with a new name, Chief of Staff, which is likewise only a testing-interface clue.

If these configurations ultimately land, the choices developers face will become more concrete: how much information does a task need to carry, and how much quota is it worth consuming? For large codebases, longer context may reduce the back-and-forth of repeatedly supplying materials, but capacity itself cannot answer whether the model accurately understood dependencies, preserved constraints, and found the truly relevant code. What determines the experience is still task-completion quality, not the window number.

This set of changes reflects the problem Google wants to solve: letting models keep pushing tasks forward over longer work processes. The difficulty in software engineering is often not writing a certain function, but understanding an existing system, modifying multiple files, running tests, and then adjusting the implementation based on failure results. Expanded output space provides the conditions for longer processing, but it is not a guarantee of reliability.

Long tasks can even amplify the cost of errors. If a wrong judgment is not discovered early, subsequent modifications, tests, and explanations may continue around a false premise. Therefore, evaluating a next-generation coding model requires not only looking at "how long it can work continuously," but also at when it can recognize a wrong direction, stop ineffective attempts, and hand which uncertainties back to humans.

This is also the limitation of the phrase "approaches Opus 5.5." Even if a public comparison between Carbon and Opus 5.5 appears in the future, it cannot be judged by the two model names alone. Whether the comparison uses the same tasks, tools, retry counts, and compute budget directly affects the conclusion. A system that fixes a problem after several more attempts and another that completes it in one go do not have the same cost or user experience. An employee saying "approaches" can be a signal worth watching, but it is still not enough to answer these questions.

At this year's May I/O conference, Google announced the standalone desktop application Antigravity 2.0, supporting parallel multi-agent tasks and background scheduling; it also launched Managed Agents in the Gemini API, letting agents use tools, execute code, and retain recoverable files and state within an isolated Linux environment. The official emphasis is that these capabilities use Antigravity's agent runtime framework and are co-optimized with Gemini models.

This layout is crucial. A model answering correctly is only part of a coding product; it also needs to know which files to read, when to execute commands, how to use test results, and how to continue after a task is interrupted. The performance developers ultimately perceive is the combined result of the model and the entire execution system.

And Google's bigger move happens outside the coding scenario. Google Cloud has just released a work-oriented Gemini Agent, covering Q&A, task handling, content generation, and coding. According to Google Cloud's official description, the Gemini agent can be used in entry points such as Workspace, runs continuously in the cloud, retains context across devices, and handles tasks through sub-agent collaboration, while the company also emphasizes model selection, permission management, sandboxing, and cost control. The Verge points out that the product is currently in private preview for enterprise customers and cannot yet be understood as ordinary users having fully obtained these capabilities.

Connecting these moves together, a relatively clear strategic direction is taking shape: use models for complex reasoning, use tools such as Antigravity for execution, and then use enterprise office products to carry actual work. This is an analysis based on already announced products and does not mean Carbon has been confirmed for use in a new enterprise agent.

Why will coding capability become an important pillar of this route? Because many office tasks, once they go beyond simple Q&A, involve data cleaning, information conversion, calling business interfaces, or generating repeatable scripts. What the user asks may be "explain this sales decline," but what the system needs to complete is a series of reading, calculation, verification, and presentation tasks. Code becomes a means of completing the task here.

This also explains why Google emphasizes both coding and general work capability: if the model can write and run code more reliably, the benefits may extend beyond professional developers. But this expansion of capability also raises delivery requirements. Code running successfully does not mean the correct data was used; a report being generated does not mean the business explanation holds. An agent capable of acting needs to let users see clearly what materials it relied on, what operations it performed, and which conclusions still need confirmation.

From a competitive perspective, Google's competitive target is obvious: the entry point where daily tasks begin. The documents, emails, spreadsheets, and cloud systems enterprises already use give agents opportunities to touch the business; whether these entry points can be converted into sustained use ultimately depends on whether the product reduces handoffs, verification, and rework. More connections between products do not mean the burden on users to manage them is smaller. If task status is unclear, permissions are hard to understand, and failures require manually reassembling the process, the convenience promised by integration may be offset. A stronger underlying model can alleviate part of the problem, but it cannot replace product and engineering design.

Around the successive leaks about Gemini 4, two very different reactions have appeared on social platforms: some believe Google is regaining competitiveness, while others have lost patience with the rhythm of "the model isn't even usable yet, and the next version is already being warmed up."

Supporters focus more on the signal released by model iteration, trying to use internal testing feedback to respond to "benchmark-chasing" doubts. However, netizens' interpretations of scores and employees' preliminary experiences still cannot replace public, reproducible real-world testing. Tech bloggers' optimistic judgments about the iteration rhythm reflect more of an expectation for Google's execution speed, and are not yet independent verification of model capability.

Other discussions focus on when the product will actually be usable. Some netizens compiled the hidden Argon configurations in Antigravity and the interface changes for low, medium, and high reasoning effort on the Gemini web page, viewing them as preparation before expanding access and asking whether launch is imminent. But the same release rhythm has also triggered obvious dissatisfaction: a domestic user on x criticized that after Argon was announced it was slow to be "served up," while Carbon appeared internally, along with claims that it reached Opus 5.5's level. He sarcastically said: "I suggest Google just announce AGI next, since everyone can't use it anyway, and no one can slap its face."

The disagreement shown in these comments is not just "optimistic or pessimistic about Google." The two sides are actually waiting for different evidence: supporters see the possibility of catching up from internal iteration and testing clues, while skeptics demand that Google first put the product in users' hands. As of now, Carbon is still an internal-testing item worth tracking. "Approaches Opus 5.5" brought attention, but this series of Google moves raises a bigger question: when models, tools, and office entry points are placed into the same system, can AI truly take on a piece of work that can be verified?