Gemini 4 Carbon, explained: Google's security model, who gets it first, and how to test a code fix

Our site has its own Gemini API key, the secret that lets code call Google's models. On 29 October, the day after the announcement, I asked the API which models this key can see. There are 60, and none has "carbon" in its name. Argon is there now: on 4 October, when I wrote about Argon, it was not.

Google has not published an API name for Carbon, so I tried the three a developer would guess: gemini-4-carbon, gemini-4-carbon-preview and gemini-carbon. All three came back HTTP 404 NOT_FOUND, which means "no model by that name for you".

Then I sent the same request to Argon and to Gemini 3.8 Flash, and got something different: HTTP 402 RESOURCE_EXHAUSTED. The message said our prepaid credit is used up. I did not add more money for this page, so I could not run Argon either. The two errors still teach something: a 404 says the model is not there for your key, a 402 says it is there and you need to pay. A router, the code that picks a model and falls back to another one when the first fails, should treat them differently, because one fixes itself on launch day and the other needs a person with a credit card.

One more number from the listing: the API reports an output limit of 32,768 tokens for gemini-4-argon. Argon's 30 September post spoke of a 1 million token output limit; its 13 October post calls it a "1M unified input-output token limit" and mentions a "new continuation protocol". I am reporting all three and not guessing how they fit together.

Carbon's headline skill is fixing security weaknesses. When it opens to developers, the first question is not its benchmark score but whether its fixes work on your code. So I built the small harness I would point it at, and ran it on the model I could run for free today: qwen2.5:3b, a small open model with 3 billion parameters, on this Mac through Ollama, a tool that runs models locally. It is far smaller than Carbon; the point is the harness, not a contest.

I wrote five short Python functions, each with one well-known weakness: a password-reset token made with the random module, which is predictable (CWE-338); an API key checked with ==, which stops at the first wrong character, so the time it takes can tell an attacker how much of a guess was right (CWE-208); passwords stored as MD5, an old hash so fast that guessing is cheap, with no salt (CWE-916); an SQL query built by pasting in the user's text (CWE-89); and a cookie decoded with pickle, which can run code (CWE-502).

Each function has tests that the weak version fails. The SQL test, for instance, looks up the surname O'Brien: the apostrophe breaks the pasted-together query, while a parameterized query, where the database receives the value separately from the SQL, handles it. To prove the tests are fair, I wrote my own fix for each one first. The originals fail all five, and my fixes pass all five.

Then the model got the same instruction for each: fix the weakness at the root cause, keep the names, standard library only. It fixed 1 of 5, the SQL query. Two runs, with temperature set to 0 so the model picks its most likely answer each time, gave identical code and identical results.

Be clear about what the tests check. Only the SQL test checks behaviour alone. The other four also search the code text: the token test rejects the random module, the key test requires compare_digest, the password test rejects MD5, the cookie test rejects pickle. A safe fix written another way, such as random.SystemRandom, would fail them, so read a failure before you trust it too.

The interesting failure is the password. The model's fix looked right at a glance: a random 16-byte salt (random bytes stored next to the hash, so two people with the same password get different hashes) and PBKDF2, a slow password hash. It still failed, because it read the salt back as 32 bytes, so it could not check a password against its own stored hash. A reviewer skimming the code might have approved it. The test did not. Even with the salt fixed I would not ship it: it compares hashes with ==, not a timing-safe compare, and its 100,000 rounds are below the 600,000 that OWASP recommends for this hash.

That is the lesson for Carbon too. Google reports 71.0% on a patching benchmark, which also means some fixes fail. Whatever model writes the fix, run it against tests before a person reads it, and keep the tests for the next change.

Read next: Parameterized queries, and why the O'Brien test works