Theo reports Gemini Carbon coding run took 22m21s, versus 9m33s for Opus 5.5

• Carbon at low effort took 2.34 times as long as Opus 5.5 at high effort in theo's initial comparison: 22m21s versus 9m33s.
• Response startup consumed about four hours of one 8h10m coding trace, according to theo's measurements.
• Identical code-review briefs produced a 4.8x slowdown against Opus 5.5 across four completed rounds in the follow-up.
• Codebase analysis remained error-prone: the architecture-review table records 23 wrong claims out of 79, despite substantial improvement over Argon.

Google opened Carbon to developers on November 10, and its developer guide suggests 15-to-20-minute HTTP client timeouts for hard reasoning prompts. Further tests changed Theo's planned early-access video, he said before release, and he later acknowledged real use cases alongside his coding complaints.

Theo's first comparison used different effort settings: Carbon on low and Opus 5.5 on high, as specified in his timing report. The elapsed-time gap was 12m48s.

His follow-up held the council code-review brief constant and averaged the four rounds Carbon finished. Carbon averaged 16m44s, versus 3m31s for Opus 5.5 and 5m27s for Argon, making it 4.8 times slower than Opus and 3.1 times slower than its predecessor.

Theo attributed most of the delay to server-side inference and reported roughly 11 seconds before Carbon started responding. Carbon's Antigravity trace was compared with pooled work from Claude Code and Codex, a different comparison population from the matched review rounds.

The nastiest loop was compaction followed by rereading the same large files. The trace counted 1,093 file reads, with a median of just 106 lines per read.

• serviceLauncher.ts: 299 reads, equivalent to reading the file 16 times.
• bootService.ts: 230 reads, equivalent to reading it 17 times.
• Context compaction: 22 occurrences at about 66 seconds each, roughly 24 minutes before counting subsequent rereads.

Theo identified several possible sources of agent-loop overhead, with different proposed remedies:

• Tool-call batching: He said calls did not batch or parallelize well and asked for a “code mode” that could execute multiple operations in one call.
• Persistent connections: He proposed WebSockets to reduce overhead at the inference-routing layer.
• Prefill: He later relayed prefill as an explanation for the response-start delay.

Carbon improved over Argon by 14 points in Theo's eight-PR review evaluation and by 2.06 points in his ts-rust architecture evaluation. Its architecture report still contained 23 wrong claims out of 79, about 29%.

The PR-review table also puts Muse Wonder Full at 31.75 against Carbon's 26.5. Theo explicitly distinguished that variant from Muse Wonder in a separate reply.

Google describes Carbon as spending more thinking tokens on exploration and verification, while positioning Argon for faster interactive coding. Its developer guide lists identical introductory API prices for both models: $2 per million input tokens and $10 per million output tokens through November 30, rising to $4 and $20 on December 1.

A separate 43-prompt comparison by FastMetal found:

• Visible answer length: 385 words for Carbon versus 386 for Argon, on average.
• Output tokens, including reasoning: 2,006 versus 1,099 per answer, on average.
• Median completion time: 34.9 seconds versus 10.5 seconds, with Carbon slower on all 43 prompts.

FastMetal ran each prompt once, testing Argon on October 13 and Carbon on November 10; timings included network time and load on different days. On its hard SQL prompt, Carbon caught an additional accounting bug: assigning an entire order's value to each product instead of summing line-item amounts.

Theo separately challenged GDPx as a measure of task efficiency, arguing that Opus 5.5 at xhigh was cheaper than every Carbon effort level on real-world tasks.

The Windows-service job took 14 hours, Theo reported, and he criticized the 4,000-plus-line result as much larger than necessary before switching to Fable for cleanup.

The original Windows-service PR eventually reached 7,806 added lines and 1,122 deletions across 24 files and was closed. The replacement PR, credited to Fable 5.2 and building on four existing commits, merged November 11 with 1,110 additions and 123 deletions across 16 files.

The merged implementation narrowed the architecture:

• Task Scheduler launches conhost.exe --headless t3.exe __service-launcher, with a one-minute repeat trigger for crash recovery.
• A lock file serializes replacement launchers; an IPC stop message shuts down the server cleanly.
• The loopback TCP/HMAC control channel and shared rollback rewrites from the larger implementation were left out.

The replacement PR reports a Windows 11 remote update completing in 5.6 seconds with about two seconds of downtime. Its sign-out/logon trigger was not exercised in that test run.