Gemini 4 Carbon oder Argon? Sieben Tipps zum neuen Modell

Google hat Gemini 4 Carbon für Alle freigegeben. Der neue Developer Guide erklärt, wann Carbon sich lohnt und wie du das Modell bei längeren Aufgaben einsetzt.

Warum solltest du noch Argon nehmen, wenn Carbon im Benchmark deutlich besser abschneidet und Google für beide denselben API-Preis pro Token verlangt? Im Intelligence Index von Artificial Analysis liegt Carbon mit 60 Punkten vor Argon mit 50.

Carbon nimmt sich bei schwierigen Aufgaben häufig mehr Zeit zum Nachdenken und verbraucht dafür mehr Token. Google berechnet diese Thinking-Token zum selben Preis wie die Ausgabe-Token. Heißt auch bei gleichen API-Preisen wird Carbon im Durchschnitt teurer sein.

Für eine kleine Fehlerkorrektur oder eine Zusammenfassung ist Argon deshalb oft die bessere Wahl. Nimm Carbon, wenn sich zum Beispiel ein Fehler über Webseite, Server und Datenbank zieht und du mehrere mögliche Ursachen prüfen musst.

Wenn in deiner älteren API-Anbindung noch »thinking_budget« steht, ersetze es für Carbon durch »thinking_level«. Nutzt du schon Argon, kannst du dieselbe Einstellung weiterverwenden.

Starte bei Carbon mit »medium«. Das ist die Voreinstellung und passt etwa, wenn du beim Programmieren zügig Rückmeldung brauchst. Wähle »low«, wenn du zum Beispiel viele kurze Texte nach Themen sortieren willst. Probier »high«, wenn Carbon einen Fehler über mehrere Dateien hinweg eingrenzen soll.

In der Interactions API setzt du die Stufe mit »generation_config = {"thinking_level": "medium"}«.

Wenn du einem Modell bisher jeden Schritt einzeln gegeben hast, konntest du schnell nachsteuern. Soll Carbon eine längere Aufgabe am Stück bearbeiten, klär zuerst, woran du ein fertiges Ergebnis erkennst.

Beschreibe genau dieses fertige Ergebnis, lass Carbon offene Fragen stellen und prüfe seinen Plan. Google empfiehlt außerdem, vor dem Start prüfen zu lassen, ob Carbon an die nötigen Dateien und Programme herankommt.

Anzeige

Mit »Beheb diesen Fehler« beschreibst du das Ziel. Wie das Modell erkennt, ob die Korrektur funktioniert, bleibt offen. Gib Carbon einen Test, den es vor und nach der Änderung ausführen kann.

Wenn es noch keinen passenden Test gibt, lass Carbon zuerst einen schreiben. So kannst du sehen, ob der Test den ursprünglichen Fehler tatsächlich erfasst und nach der Änderung durchläuft.

Wenn du ein Layout bisher nur mit Worten beschrieben hast, musste das Modell sich Abstände, Größen und Anordnung oft selbst überlegen. Gib Carbon einen Screenshot als Vorlage und sag dazu, was es übernehmen soll. Wenn dein Programmieragent Zugriff auf einen Browser hat, kann er die fertige Seite öffnen und mit der Vorlage vergleichen.

Wenn du bisher einen ganzen Umbau einem einzigen Modell überlassen hast, dann ist das unnötig teuer. Lass Carbon den Umbau planen und am Ende prüfen, ob alle Teile zusammenpassen. Gib Argon einzelne Arbeiten, die unabhängig voneinander erledigt werden können.

Bei einem neuen Datenimport könnte Carbon etwa festlegen, wie die eingelesenen Daten aussehen sollen. Zwei Argon-Agenten setzen dann getrennt den Import für CSV- und JSON-Dateien um. Carbon prüft am Ende, ob beide Importe dieselben Regeln einhalten.

In der Antigravity-App kannst du dafür mit »/swarm« starten und den Agenten in der Mitgliederliste unterschiedliche Modelle zuweisen. Die Funktion wird aktuell nach und nach ausgerollt.

Anzeige

Wenn ein Agent einen besonderen Testbefehl erst nach mehreren Versuchen findet, bleibt die Lösung leicht im Chatverlauf hängen. Beim nächsten Auftrag kann dieselbe Suche von vorn anfangen. Lass Carbon nach einer längeren Aufgabe herausarbeiten, welche Erkenntnisse du wiederverwenden kannst.

Wenn dein Programmieragent »AGENTS.md« als Projektanweisung liest, kannst du dort die geprüften Hinweise ablegen.