Gemini 4 Carbon Review: Vierde op de index, traag met antwoorden

Gemini 4 Carbon staat vierde op de onafhankelijke ranglijst en is geprijsd als een model uit de middenklasse, een ongewone combinatie om eerlijk te beoordelen: de Gemini 4 Carbon API-pagina vermeldt $2,00 per miljoen invoertokens en $10,00 per miljoen uitvoertokens, terwijl de score die het haalt 60 is op de Artificial Analysis Intelligence Index v5.0.1, vierde van 78 modellen. De vraag die een review moet beantwoorden is niet of 60 goed is. Het is wat je betaalt in kloktijd en in foutpercentage om het te krijgen.

Wat het is

Een multimodaal model uit de Gemini 4-familie van Google met een contextvenster van 1.048.576 tokens en een uitvoerplafond van 65K. Het accepteert tekst, afbeeldingen, audio, video en documenten en retourneert tekst, met native toolgebruik en gestructureerde JSON-uitvoer. Het is beschikbaar via zowel het OpenAI-compatibele endpoint als de native Gemini generateContent-API, en Zero Data Retention is beschikbaar.

De parameterset vertelt je wat voor soort model het wil zijn: reasoning, include_reasoning, structured_outputs, tools, tool_choice, seed, temperature, top_p. Er staan een seed en een responsformaat op dezelfde lijst, wat het kenmerk is van een model dat gepositioneerd is voor extractie en agentische pipelines in plaats van voor creatief schrijven.

De score, en de versie waarop deze is gescoord

De 60 is niet vergelijkbaar met oudere cijfers die je voor andere modellen ziet aangehaald, en dit is de meest voorkomende fout in vergelijkingen die deze maand zijn gepubliceerd. Intelligence Index v5.0.1 is een andere evaluatieset dan v4.3 en v4.3.2, dus een v4.3-score en een v5.0.1-score horen niet in dezelfde tabel. Binnen het v5.0.1-cohort zet Carbon's 60 het op de vierde plaats van de 78, achter Claude Fable 5.2 met 65 en vóór al het overige dat opnieuw is gescoord.

De negen evaluaties achter dat cijfer zijn AA-Briefcase v1.1, AutomationBench-AA, Terminal-Bench 4.0, FrontierCode-AA 2.0, AA-Omniscience v1.1, GDP.pdf, HLE-Diamond, CritPt v2 Hard Subset en Terminal-Bench-Science 0.1. Dat is een agentische en wetenschappelijke mix — terminalwerk, automatisering, documentonderbouwing, zwaar redeneerwerk — geen mix voor een code-leaderboard. Een model kan hier goed scoren en toch verliezen bij een refactor op repositoryschaal, dus lees de uitsplitsing voordat je iets concludeert over je eigen use case.

Het deel dat het kopcijfer verbergt

De tijd tot het eerste token van Carbon in de AA-harness is 64,7 seconden, rang 69 van 77 modellen met latentiegegevens. De totale kloktijd per taak is 28,4 minuten over de negen evaluaties. De outputsnelheid zodra het begint te schrijven is 72 tokens per seconde, wat niets bijzonders is maar niet het probleem; het probleem is de denktijd vóór het eerste token.

Het uitvoeren van de index tegen Carbon kostte $5.48 aan provideruitgaven, wat bij een gemengd tarief van $2.70 per miljoen tokens veel tokens is voor één benchmarkronde. AA rapporteert ook een breedsprakigheid van 2,69 procent naast 205 miljoen outputtokens voor de run. Lees het percentage niet als een beknoptheidsscore: Claude Fable 5.2 noteert een veel lager 0,97 procent met een hoger aantal van 275 miljoen outputtokens, dus de twee cijfers bewegen onafhankelijk van elkaar.

Als de prijs de reden is dat u dit leest, zet de LLM API-prijsvergelijking een gemengd tarief van $2,70 per miljoen naast de rest van de catalogus, inclusief de modellen die daaronder zitten en de modellen die meerdere keren meer kosten voor een vergelijkbare score.

Via de gateway zien de getallen er anders uit.

De 64,7 seconden van AA is een benchmarkharnas waarmee het model kan nadenken over moeilijke problemen. In het liveverkeer van OrcaRouter in de afgelopen zeven dagen was de p50-tijd tot het eerste token voor Carbon 6,89 seconden en de p95 was 10,00 seconden, met 226 tokens per seconde aan uitvoer over 9,6 miljoen geleverde tokens. Beide zijn waar. Een chatproduct ziet iets in de buurt van het eerste getal; een batch-evaluatiekloon ziet iets in de buurt van het tweede.

Het cijfer dat meer aandacht verdient dan beide andere is het foutpercentage: 39,7 procent van de verzoeken gaf een niet-2xx-respons bij alle upstreamproviders in dat venster van zeven dagen, tegenover 10,8 procent voor Claude Fable 5.2. Wat de oorzaak ook is — capaciteit, rate limits, providerrotatie — een product dat Carbon aanroept zonder retrybudget en fallbackmodel zal gebruikers fouten laten zien in een mate die geen enkele benchmarkgrafiek voorspelt. Dat is een routeringsvraagstuk, en het is het enige dat je vóór de tweede week moet testen.

Waar het in de catalogus hoort

Vergeleken met de andere modellen in dezelfde reeks is Carbon het multimodale lid van de Gemini 4-lijn, niet het goedkope model: de invoerprijs is identiek aan die van Gemini 3.1 Pro op $2,00, de uitvoer is $2,00 goedkoper, en het verschil dat ertoe doet is dat Carbon audio en video verwerkt waar 3.1 Pro tekst en afbeeldingen verwerkt. Als je pipeline nooit een videobestand aanraakt, betaal je voor een capaciteit die je niet zult gebruiken.

Ten opzichte van de rest van het veld komt de beslissing meestal neer op twee vragen. Als het een interne Google-keuze is, Gemini 4 Carbon vs Gemini 3.1 Pro is de vergelijking die ertoe doet. Als het om verschillende leveranciers gaat, GPT-6.1 Sol vs Gemini 4 Carbon en Claude Opus 5.5 vs Gemini 4 Carbon dekken de twee meest voorkomende alternatieven, en de LLM-modellenlijst bevat de volledige catalogus als geen van beide het model is dat u overwoog.

Vonnis

Carbon verdient zijn vierde plaats op capaciteit per dollar aan invoer, en wel op een manier die past bij langdurig, multimodaal, gestructureerd werk in plaats van bij gesprekken. De kosten die niet in de prijstabel staan, zijn de twee die bepalen of het voor jou werkt: 64,7 seconden nadenken voordat de eerste token verschijnt onder een benchmarkomgeving, en een foutpercentage van bijna 40 procent op live verkeer. Omzeil beide — een fallbackketen, een retrybudget en een asynchrone wachtrij voor alles wat niet interactief is — en de verhouding tussen prijs en score is werkelijk moeilijk te verslaan. Zet het achter een synchrone UI zonder fallback en je zult concluderen dat het model slechter is dan het is.