DEV Community: Aleksei Aleinikov

GPT-6.1 Sol vs. Claude Opus 5.5: Halber Preis, andere Klasse – und wo der Abstand verschwindet

Aleksei Aleinikov — Tue, 06 Oct 2026 07:00:00 +0000

Zwei Launches im Abstand einer Woche haben einen Vergleich zum Suchtrend gemacht. Anthropic hat Claude Opus 5.5 am 22. September 2026 veröffentlicht und empfiehlt es als Startmodell für die meisten Workloads. Am 29. September folgte OpenAI mit GPT-6.1 Sol zu 2 $/10 $ pro Million Tokens – exakt die Hälfte von Opus 5.5 mit 4 $/20 $. Die Frage, die jetzt in die Suche getippt wird, ist kurz: Sol 6.1 oder Opus 5.5?

Die ehrliche Antwort beginnt mit einer Korrektur. Die beiden Modelle spielen nicht in derselben Klasse, der Name „Sol“ bedeutet nicht mehr dasselbe wie im Juli, und einen Benchmark, der beide auf demselben Harness laufen lässt, habe ich nicht gefunden. Präzise vergleichen lässt sich, was jedes Modell pro Agent-Turn kostet – und dieser Vergleich hat bei 272.000 Tokens eine Kante, die die Antwort verändert.

GPT-6.1 Sol vs. Claude Opus 5.5 auf einen Blick

Die Angaben stammen von der Modellseite zu GPT-6.1 Sol, der Claude-Modellübersicht und den Preisseiten beider Anbieter.

	GPT-6.1 Sol	Claude Opus 5.5
API-Modell-ID	`gpt-6.1-sol`	`claude-opus-5-5`
Veröffentlicht	29. September 2026	22. September 2026
Einordnung durch den Anbieter	„Leistung nahe an Astra für komplexe Arbeit zu geringeren Kosten“	„Für langlaufendes agentisches Coding und Wissensarbeit“
Input / Output pro Million Tokens	2 $ / 10 $	4 $ / 20 $
Cache Read pro Million Tokens	0,10 $ (5 % des Inputs)	0,20 $ (5 % des Inputs)
Cache Write pro Million Tokens	2,50 $, mindestens 30 Minuten gültig	5 $ für 5 Minuten · 8 $ für 1 Stunde
Prompts über 272K Input-Tokens	2× Input und Cache, 1,5× Output für die gesamte Anfrage	Standardpreise bis 1M
Kontextfenster / max. Output	1,05M (max. 922K Input) / 128K	1M / 128K
Reasoning-Stufen	`low` · `medium` (Standard) · `high` · `xhigh` · `max`	Dieselben fünf Stufen, Standard `medium`
Lässt sich Reasoning abschalten?	Nein – `none` und `minimal` werden abgelehnt	Nein – Thinking ist immer aktiv
Minimaler cachebarer Prompt	1.024 Tokens	512 Tokens
Wissensstand	30. April 2026	Juni 2026
Tool Calling	Responses API (Chat Completions ohne Tools)	Messages API; kein erzwungenes `tool_choice`
Batch-Rabatt	50 % (auch Flex)	50 %
EU-Datenresidenz über die eigene API des Anbieters	Ja (+10 % Regionalaufschlag)	Nein – die Claude API bietet `us` oder `global`

Drei Zeilen verdienen einen zweiten Blick:

Beide Anbieter berechnen Cache Reads mit 5 % des Inputs. Das klingt nach Gleichstand, doch 5 % von 2 $ sind die Hälfte von 5 % von 4 $. Beim Vergleich von Sonnet 5.5 und Opus 5.5 ließen identische Cache-Read-Preise den echten Abstand deutlich unter die 2× des Listenpreises schrumpfen. Hier passiert das Gegenteil: Das günstigere Modell ist auch bei dem Posten günstiger, der Agent-Rechnungen dominiert.
Der Standard-Effort ist jetzt gleich. Beide APIs starten bei medium. Die Namen der fünf Stufen sind identisch, aber es sind getrennte Skalen getrennter Anbieter – high bei Sol ist nicht high bei Opus. Setzen Sie Effort in jeder Vergleichsanfrage explizit.
Die 272K-Zeile entscheidet bei langem Kontext. Sie bekommt unten einen eigenen Abschnitt.

Welches Sol? Der Name hat in drei Monaten die Klasse gewechselt

Wer nach „Sol vs. Opus“ sucht, findet drei verschiedene Modelle namens Sol – und sie stehen nicht an derselben Stelle:

Modell	Veröffentlicht	Rolle in der Familie	Preis pro Million Tokens
GPT-5.6 Sol	9. Juli 2026	Frontier-Modell von GPT-5.6 (über Terra und Luna)	4 $ / 20 $ seit dem Aktionspreis vom 21. August
GPT-6 Sol	22. September 2026	Mitte von GPT-6 (unter Astra)	2 $ / 10 $, Cache Read 0,20 $
GPT-6.1 Sol	29. September 2026	Mitte von GPT-6, „nahe an Astra“	2 $ / 10 $, Cache Read 0,10 $

Gleicher Name, andere Klasse: In der GPT-6-Familie ist Sol dorthin gerückt, wo Sonnet steht.

Zwei praktische Folgen:

Mit „Sol“ beschriftete Benchmarks können das alte Flaggschiff meinen. Anthropics Launch-Beitrag zu Opus 5.5 vergleicht mit GPT-5.6 Sol – dem Frontier-Modell aus dem Juli – und nicht mit GPT-6.1 Sol. Diese Zahlen als „Opus schlägt das neue Sol“ zu lesen, ist in beide Richtungen falsch.
GPT-6 Sol und GPT-6.1 Sol sind verschiedene API-Modelle. GPT-6.1 Sol halbiert den Preis für gecachten Input, streicht die Reasoning-Stufe none und verlangt für Tool Calling die Responses API. GPT-6 Sol unterstützt none weiterhin und erlaubt Function Calling in Chat Completions, wenn Effort auf none steht. Pinnen Sie die exakte ID.

GPT-6.1 Sol vs. Opus 5.5 ist kein Duell der Flaggschiffe. Es ist OpenAIs Mittelklasse-Modell gegen das Modell, mit dem Anthropic den meisten den Einstieg empfiehlt – und preislich gehört Sol neben Sonnet 5.5.

GPT-6.1 Sol Benchmarks: Was es gibt und was nicht

Einen veröffentlichten Vergleich von GPT-6.1 Sol und Claude Opus 5.5 auf demselben Harness – weder vom Anbieter noch von einem unabhängigen Labor – habe ich nicht gefunden. Was es gibt, ist Anthropics Tabelle zu Opus 5.5 mit OpenAIs Flaggschiff GPT-6 Astra und dem älteren GPT-5.6 Sol :

Benchmark	Opus 5.5	GPT-6 Astra	GPT-5.6 Sol
Terminal-Bench 4.0 (agentisches Coding im Terminal)	66,4 %	57,9 %	37,3 %
FrontierCode v1.1 Main	54,4 %	53,3 %	47,5 %
CursorBench 4.0	57,8 %	–	41,7 %
GDPval-AA v2.1 (Wissensarbeit, Elo)	1846	1542	1588
AutomationBench (Geschäftsabläufe)	40,0 %	41,4 %	28,8 %
Humanity’s Last Exam, mit Tools	67,7 %	57,2 %	–
Terminal-Bench-Science 0.1	58,7 %	64,6 %	22,4 %

Lesen Sie die Tabelle mit ihren Fußnoten. Opus 5.5 lief auf Max-Effort, außer bei Terminal-Bench: Dort meldet Anthropic den xhigh-Wert von Opus und den von OpenAI gemeldeten high-Wert von Astra, jeweils den Bestwert. Opus lief mit aktiven Produktions-Safeguards, die einige Cybersecurity- und Biologie-Aufgaben an ältere Modelle weiterreichen – laut Anthropic drückt das vermutlich die Werte. AutomationBench hat Zapier ohne Fallback-Modelle gemessen, Safeguard-Eingriffe zählten also als Fehlschlag. Und jede Zahl hier stammt vom Anbieter.

Anthropic nennt außerdem Kosten pro Aufgabe im Vergleich zu Astra: Auf dem Standard-Effort medium schlägt Opus 5.5 bei GDPval-AA GPT-6 Astra auf Max-Effort für etwa ein Fünftel der Kosten pro Aufgabe und erreicht bei Terminal-Bench 4.0 Astras Niveau für etwa 40 % der Kosten.

Was das über Sol aussagt , ist eine Schlussfolgerung, keine Messung. OpenAIs eigener Modell-Leitfaden ordnet GPT-6.1 Sol unterhalb von Astra ein und empfiehlt, beide zu vergleichen, um den Kompromiss zwischen Qualität und Kosten abzuwägen. Bei den Zeilen, in denen Opus 5.5 deutlich vor Astra liegt – Terminal-Bench um 8,5 Punkte, GDPval-AA um rund 300 Elo, Humanity’s Last Exam um 10,5 Punkte –, dürfte ein unterhalb von Astra positioniertes Modell den Abstand kaum schließen. In den zwei Zeilen, in denen Astra führt, könnte auch Sol führen. Nehmen Sie die Tabelle als Karte, wo Sie eigene Evals fahren sollten, nicht als die Evals selbst.

GPT-6.1 Sol vs. Opus 5.5 Preise: volle 2× bis 272K Tokens

Laut Listenpreis kostet Opus 5.5 doppelt so viel. Anders als beim Vergleich Sonnet gegen Opus hält das pro Agent-Turn, weil auch der Cache Read – der Posten, der lange Agent-Loops dominiert – genau die Hälfte kostet.

Nehmen wir denselben Coding-Agent-Turn mitten in einer Session wie beim Sonnet-Vergleich: 60.000 Tokens gecachter Kontext werden erneut gelesen, 3.000 neue Tokens in den Cache geschrieben und 1.500 Output-Tokens inklusive Reasoning erzeugt. Reasoning wird bei beiden Modellen als Output abgerechnet.

Turn mit 60K Tokens Kontext	GPT-6.1 Sol	Claude Opus 5.5
60K Cache Reads	0,0060 $	0,0120 $
3K Cache Writes	0,0075 $	0,0150 $
1,5K Output inkl. Reasoning	0,0150 $	0,0300 $
Summe pro Turn	0,0285 $	0,0570 $
Aufpreis für Opus	–	2,0×

Lassen Sie denselben Agenten nun eine große Codebasis durcharbeiten, bis jeder Turn 400.000 Tokens erneut liest. Bei Sol wird jede Anfrage mit mehr als 272K Input-Tokens mit 2× Input- und Cache-Preisen und 1,5× Output abgerechnet – für die gesamte Anfrage , nicht nur für die Tokens oberhalb der Schwelle. Anthropic rechnet das volle 1M-Token-Fenster von Opus 5.5 zum Standardpreis ab; eine Anfrage mit 900K Tokens kostet pro Token dasselbe wie eine mit 9K.

Turn mit 400K Tokens Kontext	GPT-6.1 Sol	Claude Opus 5.5	Claude Sonnet 5.5
400K Cache Reads	0,0800 $	0,0800 $	0,0800 $
3K Cache Writes	0,0150 $	0,0150 $	0,0075 $
1,5K Output inkl. Reasoning	0,0225 $	0,0300 $	0,0150 $
Summe pro Turn	0,1175 $	0,1250 $	0,1025 $
Relativ zu Sol	–	1,06×	0,87×

Unter 272K Input-Tokens kostet Sol die Hälfte. Darüber frisst der Aufschlag fast den gesamten Unterschied.

Die Zahlen sind illustrativ und nehmen an, dass sich der Cache-Write-Preis zusammen mit den anderen Cache-Preisen verdoppelt. Zwei Dinge verändern Ihre eigene Rechnung stärker als der genaue Token-Mix:

Tokenizer unterscheiden sich. Derselbe Prompt ergibt nicht bei beiden Modellen dieselbe Token-Zahl. Anthropic weist darauf hin, dass sein Tokenizer seit Claude Opus 4.7 für denselben Text etwa 30 % mehr Tokens erzeugt als der ältere. Vergleichen Sie Kosten pro Aufgabe aus echten Usage-Logs, nie nur den Preis pro Million Tokens.
Die Cache-Lebensdauer unterscheidet sich. Ein Cache Write bei Sol bleibt mindestens 30 Minuten nach der letzten Nutzung wiederverwendbar. Ein 5-Minuten-Write bei Opus 5.5 verfällt nach fünf Minuten Leerlauf; damit er überlebt, während ein Mensch einen Diff prüft, zahlen Sie den 1-Stunden-Write mit 8 $ statt 5 $ pro Million. Für Agenten, die auf Menschen warten, ist das ein weiterer Posten, bei dem Sol spart.

Überschreitet Ihr Agent regelmäßig 272K Tokens, verschwindet das Preisargument für Sol weitgehend – und Sonnet 5.5 wird das günstigste der drei Modelle , weil es bei Sols Basispreisen flach abrechnet.

Reasoning: Bei keinem der beiden abschaltbar

Beide Anbieter haben bei diesen Modellen den Schalter für „kein Reasoning“ entfernt, und beide liefern einen Fehler, statt die alte Einstellung stillschweigend zu ignorieren:

GPT-6.1 Sol akzeptiert reasoning.effort mit low, medium (Standard), high, xhigh oder max. none und minimal werden nicht unterstützt; OpenAIs Migrationsleitfaden empfiehlt stattdessen low. Tool Calling erfordert die Responses API.
Claude Opus 5.5 nutzt immer adaptives Thinking. thinking: {"type": "disabled"} oder ein manuelles budget_tokens liefern einen 400 invalid_request_error; gesteuert wird über output_config.effort. Laut Anthropic denkt Opus 5.5 bei gleichem Effort pro Turn mehr als Opus 5, vor allem bei xhigh und max.

Eine minimale Anfrage für jedes Modell, mit explizit gesetztem Effort, damit ein A/B-Test Gleiches mit Gleichem vergleicht:


from openai import OpenAI

import anthropic

sol = OpenAI().responses.create(

    model="gpt-6.1-sol",

    reasoning={"effort": "medium"}, # "none" liefert bei diesem Modell einen Fehler

    input="Refactor the retry logic in payments/client.py",

)

opus = anthropic.Anthropic().messages.create(

    model="claude-opus-5-5",

    max_tokens=16000,

    output_config={"effort": "medium"}, # Thinking selbst lässt sich nicht abschalten

    messages=[{"role": "user", "content": "Refactor the retry logic in payments/client.py"}],

)

Beide Modelle können den Effort auch mitten in der Konversation ändern, ohne den Cache zu entwerten : Sol über ein configuration_update-Input-Item, Opus 5.5 über Effort pro Nachricht (Beta). Nutzen Sie das für den Fall „bei diesem Schritt gründlicher nachdenken“, statt das Modell zu wechseln.

Ein Wechsel mitten in der Aufgabe kostet doppelt

Verlockend ist ein Router: Sol für Routine-Turns, Opus für die schweren, innerhalb derselben Session. Über Anbietergrenzen hinweg kostet das bei jedem Wechsel an zwei Stellen.

Das Reasoning wird nicht übertragen. Die Reasoning-Elemente gehören dem jeweiligen Anbieter; das Zielmodell sieht Text und Tool-Aufrufe, aber nichts von dem Reasoning dahinter. Schon innerhalb von Anthropics eigener Modellreihe sind Thinking-Blöcke an das erzeugende Modell gebunden; über Anbieter hinweg gibt es nichts zu binden.
Der Cache wird nicht übertragen. Prompt-Caches gelten pro Modell und pro Anbieter. Die erste Anfrage beim anderen Modell verarbeitet den gesamten Präfix als Cache Write neu. Bei einer Session mit 200K Tokens sind das rund 0,50 $ bei Sol und 1,00 $ bei Opus 5.5 , bevor überhaupt neue Arbeit passiert – und bei Sol oberhalb von 272K das Doppelte.

Routen Sie pro Konversation : Entscheiden Sie zu Beginn, ob eine Aufgabe Sol- oder Opus-Arbeit ist, und eskalieren Sie über eine neue Konversation mit Zusammenfassung, statt Turn für Turn das Modell zu wechseln.

Für Teams in Europa

Wo das Modell läuft, zählt unter DSGVO oder Branchenvorgaben so viel wie der Preis – und hier unterscheiden sich die Anbieter auf eine Weise, die in den Datenblättern nicht hervorsticht.

GPT-6.1 Sol unterstützt EU-Datenresidenz über OpenAIs eigene API , mit 10 % Aufschlag für regionale Verarbeitung. Fast Mode ist mit EU-Datenresidenz nicht verfügbar.
Claude Opus 5.5 auf der Claude API bietet nur us oder global als Inferenz-Region und nur us als Workspace-Geo. Für Verarbeitung in Europa nutzen Sie Claude auf Google Cloud (regionale und Multi-Region-Endpunkte) oder regionale Endpunkte bei Amazon Bedrock, jeweils mit 10 % Aufschlag gegenüber globalen Endpunkten – und prüfen Sie, ob Opus 5.5 in der benötigten Region angeboten wird. Fast Mode für Opus 5.5 gibt es nur auf der Claude API.
Opus 5.5 bringt Anthropics Wasserzeichen-Maßnahmen für den EU AI Act mit und ist wie frühere Opus-Modelle mit Zero Data Retention verfügbar.

Wenn Sie bereits auf Google Cloud arbeiten, hält Opus 5.5 über Vertex AI Abrechnung, IAM und Datenstandort in der Plattform, die Sie ohnehin steuern. Brauchen Sie EU-Datenresidenz direkt beim Anbieter ohne Cloud-Zwischenschicht, ist Sol der einfachere Weg.

Vier Fragen klären die meisten Fälle. Der Rest ist Ihr eigenes Eval auf derselben Effort-Stufe.

Welches Modell sollten Sie wählen?

Wählen Sie GPT-6.1 Sol, wenn:

Ihre Agent-Loops in großem Volumen laufen, cachelastig sind und unter 272K Input-Tokens bleiben – dort liegt die volle 2×-Ersparnis;
Sie EU-Datenresidenz über die eigene API des Anbieters brauchen;
Sessions oft genug auf Menschen warten, dass ein 30-Minuten-Cache wiederholte Writes spart;
Ihr Team bereits mit Codex oder den gehosteten Tools der Responses API arbeitet.

Wählen Sie Claude Opus 5.5, wenn:

die Arbeit langlaufend ist und Fehler teuer sind – Migrationen, Audits, mehrdeutige Refactorings –, wo Anthropics veröffentlichte Zahlen Opus vor OpenAIs Flaggschiff zeigen;
Kontexte regelmäßig über 272K Tokens gehen, wo Sols Rabatt weitgehend verpufft;
Ihr Team mit Claude Code arbeitet oder Claude bereits auf Google Cloud oder Bedrock betreibt.

Prüfen Sie eine dritte Option , bevor Sie sich festlegen: Gefällt Ihnen an Sol der Preis, kostet Claude Sonnet 5.5 pro Token dasselbe, rechnet langen Kontext flach ab und hat Opus 5.5 bei Terminal-Bench 4.0 geschlagen. Gefällt Ihnen an Opus die Obergrenze, ist GPT-6 Astra OpenAIs Gegenstück zu 10 $/50 $. Und wenn Sie eigentlich den Agenten statt des Modells wählen: Claude Code, Codex und opencode unterscheiden sich in mehr als dem Modell, das sie aufrufen.

Egal, wofür Sie sich entscheiden: Fahren Sie Ihr eigenes Eval bei beiden gleich – identische Aufgaben, Effort explizit gesetzt und Kosten pro abgeschlossener Aufgabe aus den Usage-Logs.

Fazit

GPT-6.1 Sol ist nicht OpenAIs Antwort auf Opus 5.5, sondern OpenAIs Mittelklasse-Modell, preislich auf Höhe von Sonnet 5.5 und mit günstigeren Cache Reads als beide Claude-Modelle. Für cachelastige Agent-Loops unter 272K Tokens kostet es pro Turn die Hälfte von Opus 5.5, und diese Ersparnis ist echt.

Opus 5.5 ist nach der heutigen Datenlage – Anthropics Zahlen gegen Astra – die stärkere Wette für die schwerste langlaufende Arbeit, und seine flache Abrechnung bis 1M Tokens löscht den Großteil von Sols Vorteil, sobald Kontexte groß werden. Wählen Sie pro Workload, pinnen Sie die exakte Modell-ID, setzen Sie Effort explizit und wechseln Sie nicht mitten in einer Konversation den Anbieter.

Ursprünglich veröffentlicht auf alekseialeinikov.com

GPT-6.1 Sol vs Claude Opus 5.5: Half the Price, a Different Tier — and Where the Gap Disappears

Aleksei Aleinikov — Tue, 06 Oct 2026 07:00:00 +0000

Two launches a week apart turned one comparison into a search trend. Anthropic released Claude Opus 5.5 on September 22, 2026 and recommends it as the starting model for most workloads. On September 29, OpenAI released GPT-6.1 Sol at $2/$10 per million tokens — exactly half of Opus 5.5’s $4/$20. The question people now type into search is short: Sol 6.1 vs Opus 5.5, which one?

The honest answer starts with a correction. These two models are not the same tier, the name “Sol” no longer means what it meant in July, and I haven’t found a benchmark that runs both on the same harness. What you can compare precisely is what each one costs you per agent turn — and that comparison has a cliff at 272,000 tokens that changes the answer.

GPT-6.1 Sol vs Claude Opus 5.5 at a Glance

The specs below come from the GPT-6.1 Sol model page, the Claude models overview and both vendors’ pricing pages.

	GPT-6.1 Sol	Claude Opus 5.5
API model ID	`gpt-6.1-sol`	`claude-opus-5-5`
Released	September 29, 2026	September 22, 2026
Vendor positioning	“Near-Astra performance for complex work at a lower cost”	“For long-running agentic coding and knowledge work”
Input / output per million tokens	$2 / $10	$4 / $20
Cache read per million tokens	$0.10 (5% of input)	$0.20 (5% of input)
Cache write per million tokens	$2.50, kept at least 30 minutes	$5 for 5 minutes · $8 for 1 hour
Prompts over 272K input tokens	2× input and cache, 1.5× output for the whole request	Standard rates up to 1M
Context window / max output	1.05M (922K max input) / 128K	1M / 128K
Reasoning effort	`low` · `medium` (default) · `high` · `xhigh` · `max`	Same five levels, `medium` default
Can reasoning be turned off?	No — `none` and `minimal` are rejected	No — thinking is always on
Minimum cacheable prompt	1,024 tokens	512 tokens
Knowledge cutoff	April 30, 2026	June 2026
Tool calling	Responses API (Chat Completions without tools)	Messages API; no forced `tool_choice`
Batch discount	50% (Flex too)	50%
EU data residency on the vendor’s own API	Yes (+10% regional premium)	No — the Claude API offers `us` or `global`

Three rows deserve a second look:

Both vendors price cache reads at 5% of input. That sounds like parity, but 5% of $2 is half of 5% of $4. When I compared Sonnet 5.5 and Opus 5.5, identical cache-read prices shrank the real gap well below the list-price 2×. Here the opposite happens: the cheaper model is also cheaper on the line item that dominates agent bills.
The default effort now matches. Both APIs default to medium. The names of the five levels are the same, but they are separate scales tuned by separate vendors — high on Sol is not high on Opus. Set effort explicitly in every request you compare.
The 272K row is the one that decides long-context work. It gets its own section below.

Which Sol? The Name Changed Tier in Three Months

If you search for “Sol vs Opus”, you will find three different models called Sol, and they don’t sit in the same place:

Model	Released	Role in its family	Price per million tokens
GPT-5.6 Sol	July 9, 2026	Frontier model of GPT-5.6 (above Terra and Luna)	$4 / $20 since the August 21 promotional price
GPT-6 Sol	September 22, 2026	Middle of GPT-6 (below Astra)	$2 / $10, cache read $0.20
GPT-6.1 Sol	September 29, 2026	Middle of GPT-6, “near-Astra”	$2 / $10, cache read $0.10

Same name, different tier: in the GPT-6 family, Sol moved down to where Sonnet sits.

Two practical consequences:

Benchmarks labeled “Sol” may be the old flagship. Anthropic’s Opus 5.5 launch post compares against GPT-5.6 Sol — the July frontier model — not GPT-6.1 Sol. Reading those numbers as “Opus beats the new Sol” is wrong in both directions.
GPT-6 Sol and GPT-6.1 Sol are different API models. GPT-6.1 Sol halves the cached-input price, drops the none reasoning effort, and requires the Responses API for tool calling. GPT-6 Sol still supports none and allows function calling in Chat Completions when effort is none. Pin the exact ID.

GPT-6.1 Sol vs Opus 5.5 isn’t a flagship fight. It’s OpenAI’s middle model against the model Anthropic tells most people to start with — and on price, Sol belongs next to Sonnet 5.5.

GPT-6.1 Sol Benchmarks: What Exists and What Doesn’t

I haven’t found GPT-6.1 Sol and Claude Opus 5.5 published side by side on the same harness, by either vendor or an independent lab. What does exist is Anthropic’s Opus 5.5 table, which includes OpenAI’s flagship GPT-6 Astra and the older GPT-5.6 Sol :

Benchmark	Opus 5.5	GPT-6 Astra	GPT-5.6 Sol
Terminal-Bench 4.0 (agentic terminal coding)	66.4%	57.9%	37.3%
FrontierCode v1.1 Main	54.4%	53.3%	47.5%
CursorBench 4.0	57.8%	—	41.7%
GDPval-AA v2.1 (knowledge work, Elo)	1846	1542	1588
AutomationBench (business workflows)	40.0%	41.4%	28.8%
Humanity’s Last Exam, with tools	67.7%	57.2%	—
Terminal-Bench-Science 0.1	58.7%	64.6%	22.4%

Read the table with its footnotes in mind. Opus 5.5 ran at max effort except on Terminal-Bench, where Anthropic reports its xhigh score and Astra’s high score as reported by OpenAI; those are each model’s best. Opus ran with its production safeguards on, which hand some cybersecurity and biology tasks to older models — Anthropic says this likely lowers its scores. AutomationBench was run by Zapier without fallback models, so safeguard interventions counted as failures. And every number here is vendor-published.

Anthropic also published cost-per-task claims against Astra: at its default medium effort, Opus 5.5 beats GPT-6 Astra at max effort on GDPval-AA for about a fifth of the cost per task, and matches Astra on Terminal-Bench 4.0 for about 40% of the cost.

What this tells you about Sol is an inference, not a measurement. OpenAI’s own model guide places GPT-6.1 Sol below Astra and recommends comparing the two “to assess the tradeoff between quality and cost”. On the rows where Opus 5.5 leads Astra by a wide margin — Terminal-Bench by 8.5 points, GDPval-AA by about 300 Elo, Humanity’s Last Exam by 10.5 points — a model positioned below Astra is unlikely to close the gap. On the two rows where Astra leads, Sol could lead too. Treat the table as a map of where to run your own eval, not as the eval.

GPT-6.1 Sol vs Opus 5.5 Pricing: a Full 2× Until 272K Tokens

List price says Opus 5.5 costs twice as much. Unlike the Sonnet-versus-Opus case, that holds up per agent turn, because the cache read — the line that dominates long agent loops — is also exactly half.

Take the same mid-session coding-agent turn I used for the Sonnet comparison: 60,000 tokens of cached context re-read, 3,000 new tokens written to the cache, and 1,500 output tokens including reasoning. Reasoning is billed as output on both models.

Turn with a 60K-token context	GPT-6.1 Sol	Claude Opus 5.5
60K cache reads	$0.0060	$0.0120
3K cache writes	$0.0075	$0.0150
1.5K output incl. reasoning	$0.0150	$0.0300
Total per turn	$0.0285	$0.0570
Opus premium	—	2.0×

Now let the same agent work through a large codebase until each turn re-reads 400,000 tokens. On Sol, any request with more than 272K input tokens is priced at 2× input and cache rates and 1.5× output — for the whole request , not just the tokens above the threshold. Anthropic includes Opus 5.5’s full 1M-token window at standard pricing; a 900K-token request costs the same per token as a 9K one.

Turn with a 400K-token context	GPT-6.1 Sol	Claude Opus 5.5	Claude Sonnet 5.5
400K cache reads	$0.0800	$0.0800	$0.0800
3K cache writes	$0.0150	$0.0150	$0.0075
1.5K output incl. reasoning	$0.0225	$0.0300	$0.0150
Total per turn	$0.1175	$0.1250	$0.1025
Relative to Sol	—	1.06×	0.87×

Below 272K input tokens Sol is half the price. Above it, the surcharge eats almost the whole difference.

The numbers are illustrative and assume the cache-write rate doubles along with the other cache rates. Two things change your own math more than the exact token mix:

Tokenizers differ. The same prompt is not the same number of tokens on both models. Anthropic notes that its tokenizer since Claude Opus 4.7 produces about 30% more tokens for the same text than the older one. Compare cost per task from real usage logs, never price per million tokens alone.
Cache lifetime differs. A Sol cache write stays reusable for at least 30 minutes after its last use. An Opus 5.5 5-minute write expires after five idle minutes; to survive a human reviewing a diff, you pay the 1-hour write at $8 per million instead of $5. For agents that wait on people, that’s another line where Sol saves money.

If your agent regularly crosses 272K tokens, the price argument for Sol mostly disappears — and Sonnet 5.5 becomes the cheapest of the three , because it keeps flat pricing at Sol’s base rates.

Reasoning: Neither Model Turns It Off

Both vendors removed the “no reasoning” switch on these models, and both return an error rather than quietly ignoring the old setting:

GPT-6.1 Sol accepts reasoning.effort of low, medium (default), high, xhigh or max. none and minimal are not supported; OpenAI’s migration guide says to use low instead. Tool calling requires the Responses API.
Claude Opus 5.5 always uses adaptive thinking. thinking: {"type": "disabled"} or a manual budget_tokens returns a 400 invalid_request_error; output_config.effort is the control. Anthropic also notes that Opus 5.5 thinks more per turn than Opus 5 at the same effort, most of all at xhigh and max.

A minimal request for each, with effort set explicitly so an A/B test compares like with like:


from openai import OpenAI

import anthropic

sol = OpenAI().responses.create(

    model="gpt-6.1-sol",

    reasoning={"effort": "medium"}, # "none" returns an error on this model

    input="Refactor the retry logic in payments/client.py",

)

opus = anthropic.Anthropic().messages.create(

    model="claude-opus-5-5",

    max_tokens=16000,

    output_config={"effort": "medium"}, # thinking itself can't be disabled

    messages=[{"role": "user", "content": "Refactor the retry logic in payments/client.py"}],

)

Both models can also change effort mid-conversation without invalidating the cache : Sol through a configuration_update input item, Opus 5.5 through per-message effort (in beta). Use that for the “think harder on this step” case instead of switching models.

Switching Between Them Mid-Task Costs Twice

The tempting setup is a router: Sol for routine turns, Opus for the hard ones, inside the same session. Across vendors that costs you on two fronts at every switch.

Reasoning doesn’t transfer. Each vendor’s reasoning items are its own, so the target model sees the text and tool calls but none of the reasoning behind them. Even within Anthropic’s lineup, thinking blocks are bound to the model that produced them; across vendors there’s nothing to bind.
The cache doesn’t transfer. Prompt caches live per model and per provider. The first request on the other model re-processes the entire prefix as a cache write. For a 200K-token session, that is about $0.50 on Sol and $1.00 on Opus 5.5 before any new work — and on Sol above 272K, double that.

Route per conversation : decide at the start whether a task is Sol work or Opus work, and escalate by opening a new conversation from a summary rather than flipping models turn by turn.

For Teams in Europe

Where the model runs matters as much as what it costs if you work under GDPR or sector rules — and here the two vendors differ in a way the spec sheets don’t advertise.

GPT-6.1 Sol supports EU data residency on OpenAI’s own API , with a 10% regional processing premium. Fast mode is not available with EU data residency.
Claude Opus 5.5 on the Claude API offers only us or global inference , and only us as a workspace geo. To process in Europe, use Claude on Google Cloud (regional and multi-region endpoints) or Amazon Bedrock regional endpoints, each with a 10% premium over global endpoints — and check that Opus 5.5 is offered in the region you need. Fast mode for Opus 5.5 exists only on the Claude API.
Opus 5.5 ships Anthropic’s watermarking measures for the EU AI Act and, like previous Opus models, is available with zero data retention.

If you already run on Google Cloud, Opus 5.5 through Vertex AI keeps billing, IAM and data location inside the platform you already govern. If you need first-party EU residency without a cloud intermediary, Sol is the simpler path.

Four questions settle most cases. The rest is your own eval at the same effort level.

Which One Should You Pick?

Pick GPT-6.1 Sol when:

your agent loops are high-volume and cache-heavy and stay under 272K input tokens — that’s where the full 2× saving lives;
you need EU data residency on the vendor’s own API ;
sessions pause for humans often enough that a 30-minute cache saves repeated writes;
your team already works in Codex or the Responses API’s hosted tools.

Pick Claude Opus 5.5 when:

the work is long-horizon and expensive to get wrong — migrations, audits, ambiguous refactors — where Anthropic’s published numbers show Opus ahead of OpenAI’s flagship;
contexts regularly run past 272K tokens , where Sol’s discount mostly evaporates;
your team works in Claude Code or already runs Claude on Google Cloud or Bedrock.

Consider a third option before you sign up for either: if what you like about Sol is its price, Claude Sonnet 5.5 costs the same per token, keeps flat long-context pricing and beat Opus 5.5 on Terminal-Bench 4.0. If what you like about Opus is the ceiling, GPT-6 Astra is OpenAI’s equivalent at $10/$50. And if you’re choosing the agent rather than the model, Claude Code, Codex and opencode differ in more than which model they call.

Whatever you pick, run your own eval the same way on both: identical tasks, effort set explicitly, and cost measured per completed task from usage logs.

The Bottom Line

GPT-6.1 Sol is not OpenAI’s answer to Opus 5.5; it’s OpenAI’s middle model, priced like Sonnet 5.5, with cheaper cache reads than either Claude model. For cache-heavy agent loops under 272K tokens, it costs half of Opus 5.5 per turn, and that saving is real.

Opus 5.5 is the stronger bet for the hardest long-horizon work on the evidence that exists today — Anthropic’s numbers against Astra — and its flat pricing to 1M tokens erases most of Sol’s advantage once contexts get large. Pick per workload, pin the exact model ID, set effort explicitly, and don’t switch vendors in the middle of a conversation.

Originally published at alekseialeinikov.com

Cilium vs Calico: Welches Kubernetes-CNI gehört in Ihren Produktionscluster?

Aleksei Aleinikov — Mon, 05 Oct 2026 07:00:00 +0000

Fast jeder Vergleich „Cilium vs Calico“, den Sie gelesen haben, folgt derselben Idee: Cilium ist das moderne eBPF-Projekt, Calico das ältere mit iptables. Heute stimmt das schlicht nicht mehr. Cilium 1.20 wurde im September angekündigt, Calico Open Source 3.33 erschien am 1. Oktober, und die beiden Projekte überschneiden sich inzwischen stärker, als sie sich unterscheiden. Calico hat eine eBPF-Dataplane und unterstützt inzwischen ebenfalls netkit-Pod-Devices. Beide setzen die neue Kubernetes-ClusterNetworkPolicy durch. Beide liefern eine Gateway-API-Implementierung mit.

Die ehrliche Frage lautet also nicht mehr „Welches ist schneller?“, sondern: Welches Policy-Modell, welche Betriebsbedingungen und welches Ökosystem holen Sie sich ins Haus – und wie schwer wird es, die Entscheidung später zu revidieren? Denn das CNI ist die eine Clusterkomponente, die man fast nie billig austauscht. Das ist der Vergleich, den ich gern gehabt hätte, bevor ich eines für eine Produktionsplattform ausgewählt habe: was jedes Projekt heute tatsächlich kann, was GKE, EKS und AKS schon für Sie entschieden haben, und welche Fallen erst bei einer Migration sichtbar werden.

Die kurze Antwort

Wenn Sie nur einen Abschnitt lesen, dann diesen.

Cilium , wenn alle Nodes Linux mit aktuellem Kernel sind und Sie anwendungsbewusste Sicherheit im Open-Source-Projekt wollen: L7-Regeln für HTTP, gRPC und Kafka, DNS-basierter Egress (toFQDNs), Flow-Observability mit Hubble, eingebaute Gateway API und Multi-Cluster-Netzwerk per Cluster Mesh. Auf GKE Dataplane V2 und Azure CNI Powered by Cilium betreiben Sie es ohnehin schon.
Calico , wenn der Cluster heterogen oder fest mit der physischen Infrastruktur verbunden ist: Windows-Nodes, BGP-Peering mit Top-of-Rack-Switches, ältere Kernel, die eine iptables- oder nftables-Dataplane brauchen, VMs und Bare-Metal-Hosts unter derselben Policy, oder viele Teams, die Policy- Tiers mit klarer Rangfolge benötigen.
Bewusst keines von beiden auf EKS, solange es keinen Grund gibt: Das Amazon VPC CNI ist das einzige CNI, das Amazon auf EC2-Nodes unterstützt, und es setzt Network Policies inzwischen nativ durch.

Der Rest des Artikels erklärt, warum – und wo jede dieser Empfehlungen an Grenzen stößt.

Was Cilium und Calico eigentlich sind

Cilium ist ein eBPF-basiertes Projekt für Netzwerk, Sicherheit und Observability in Kubernetes, gestartet von den Gründern von Isovalent. Es kam 2021 zur CNCF und ist seit Oktober 2023 ein Graduated-Projekt. Um das CNI herum liegen Hubble für Flow-Observability, eine eingebaute Gateway-API-Implementierung und Cluster Mesh für Multi-Cluster-Netzwerke.

Calico wird von Tigera entwickelt und gepflegt. Calico Open Source ist der freie Kern, der über Clouds und Distributionen hinweg läuft; Calico Cloud und Calico Enterprise sind die kommerziellen Editionen mit Funktionen wie DNS-Policies, Egress-Gateways und Multi-Cluster-Verwaltung. Calico reicht außerdem über Kubernetes-Pods hinaus zu VMs, Bare-Metal-Hosts und OpenStack.

Beide sind Open Source, beide laufen in sehr großem Maßstab produktiv, und hinter beiden steht ein kommerzielles Unternehmen. Das zählt weniger für die Funktionen als für den Support: Prüfen Sie, zu welcher Edition eine Funktion gehört, bevor Sie damit planen.

Was ein CNI tatsächlich entscheidet (und warum die Wahl klebt)

Ein Container-Network-Interface-Plugin ist nicht nur „das Ding, das Pods eine IP gibt“. In einem Produktionscluster verantwortet es vier Aufgaben:

IP-Adressverwaltung – aus welchem Bereich die Pod-Adresse stammt und ob dieser Bereich außerhalb des Clusters routbar ist.
Konnektivität – Overlay (VXLAN, Geneve, IP-in-IP) oder natives Routing, und ob die Nodes BGP mit dem Netz sprechen.
Network Policy – Kubernetes-NetworkPolicy (und oft eine reichhaltigere eigene CRD) in Paketfilterregeln auf jedem Node übersetzen.
Service-Load-Balancing – optional kube-proxy ersetzen, sodass Traffic an eine ClusterIP in der Dataplane des CNI statt in iptables-Ketten übersetzt wird.

Weil das CNI den Adressplan und die Dataplane besitzt, heißt ein Austausch: jeden Pod neu adressieren. Die Plattformen wissen das und frieren die Entscheidung ein. GKE schreibt, dass Dataplane V2 „nur beim Erstellen eines neuen Clusters aktiviert werden kann“. RKE2 unterstützt keinen Wechsel des primären CNI nach dem ersten Start. Behandeln Sie diese Entscheidung wie die Wahl einer Datenbank-Engine: Migrieren geht, aber es kostet.

Architektur: Identitäten in eBPF-Maps vs. Policy-Engine mit austauschbaren Dataplanes

Der tiefste Unterschied zwischen den Projekten ist nicht eBPF, sondern wie sie „wer darf mit wem sprechen“ abbilden.

Cilium leitet aus den Labels jedes Pods eine numerische Security Identity ab und legt Identitäten, Endpunkte, Services und Policies in eBPF-Maps im Kernel ab. Kommt ein Paket an, schlägt ein eBPF-Programm die Quell-Identität nach, statt eine Liste von IP-Adressen auszuwerten. Dadurch ist die Policy unabhängig vom Pod-Churn, und Cilium kann jedem Flow reichhaltige Metadaten für Hubble mitgeben. Der Preis: Identitäten sind endlich. Microsofts AKS-Dokumentation warnt, dass Workloads mit hohem Churn wie Spark-Jobs einen Cluster an das Limit von 65.535 Identitäten bringen können, und empfiehlt, volatile Labels aus der Identitätsberechnung auszuschließen.

Calico ist um Felix herum gebaut, einen Agenten auf jedem Node, der Policies aus Labels und Selektoren berechnet und in die gewählte Dataplane schreibt: iptables, nftables, eBPF, Windows oder VPP. BGP-Routing übernahm historisch BIRD – deshalb passt Calico so natürlich in Netze, die schon BGP sprechen. In 3.33 programmiert standardmäßig Felix statt BIRD die Cluster-Routen für IP-in-IP-Pools; die Programmierung dieser Routen über BIRD ist abgekündigt, die Entfernung ist für 3.35 geplant.

Cilium ist eine eBPF-Dataplane mit einem Policy-Modell obendrauf. Calico ist ein Policy-Modell mit mehreren Dataplanes darunter. Die meisten praktischen Unterschiede in diesem Artikel folgen aus diesem einen Satz.

Dataplanes heute: eBPF überall, aber mit unterschiedlichen Notausgängen

Beide Projekte können iptables heute umgehen – nur Calico kann noch darauf zurückfallen.

So stehen die beiden nach den Herbst-Releases da:

	Cilium 1.20	Calico Open Source 3.33
Dataplanes	nur eBPF	iptables, nftables, eBPF, Windows, VPP
kube-proxy-Ersatz	Ja (eBPF)	Ja, im eBPF-Modus
Pod-Device	standardmäßig veth; `bpf.datapathMode=auto` wählt netkit, wenn der Kernel es kann	standardmäßig veth; netkit als optionaler CNI-`device_type` (Kernel 6.7+), eBPF-Programme hängen dann über die netkit-API ein
Kernel-Untergrenze für eBPF	aktueller Kernel; Systemanforderungen der jeweiligen Version prüfen	5.10+ mit BTF/CO-RE – plus bekannte 3.33-Regression auf 5.15
Verschlüsselung	WireGuard, IPsec, dazu Sidecar-loses mTLS über ztunnel (Beta)	WireGuard
BGP	Ja, über GoBGP	Ja, ausgereiftes Fabric-Peering; neu in 3.33: L2-Erreichbarkeit per ARP ohne BGP oder Overlay
Windows-Nodes	Nein	Ja

Einige Zeilen verdienen einen zweiten Blick.

netkit. netkit ist ein neueres Linux-Netzwerkdevice, das veth-Paare für Container ersetzen soll: Das BPF-Programm wird Teil des Devices selbst, statt von außen an ein veth-Paar gehängt zu werden, was Overhead aus dem Pfad des Pods nimmt. Ursprünglich brauchte es Kernel 6.8. Die Ankündigung von Cilium 1.20 verweist auf netkit im Einsatz bei Meta und ByteDance; ByteDance berichtet von rund 10 % Gewinn. Ciliums neuer auto-Modus nimmt netkit, wenn der Kernel es unterstützt, sonst veth; Standard bleibt veth. Calico 3.33 geht einen kleineren Schritt: Sein CNI kann über die optionale Einstellung device_type netkit-Pod-Devices anlegen (Kernel 6.7+, Standard bleibt veth), und die eBPF-Dataplane hängt sich auf diesen Devices standardmäßig über die netkit-API ein, anderswo über TCX.

Der iptables-Notausgang. Cilium hat keinen Fallback ohne eBPF. Gehören Kernel oder gehärtete Images zu Ihrer Flotte, in denen eBPF eingeschränkt ist, ist Calicos Fähigkeit, dieselbe Policy auf iptables oder nftables laufen zu lassen, ein echter Betriebsvorteil und kein Altlasten-Feature. 3.33 bringt zusätzlich optionales nftables-Flowtable-Offload, mit dem etablierte Verbindungen den Großteil des Regelwerks überspringen.

Footprint. Beide Projekte haben dieses Jahr abgespeckt: Das cilium-cni-Binary schrumpfte in 1.20 von 76 MB auf 16 MB, und Calico 3.33 konsolidiert die calico-node-Dienste – laut Tigera rund 200 MB weniger Speicher pro Node – und liefert ein einziges Image quay.io/calico/calico.

Auf einer Managed-Plattform kommen die Betriebsgrenzen vom Anbieter, nicht vom Projekt. Google dokumentiert zum Beispiel, dass der Dataplane-V2-Agent (anetd) auf Nodes mit vielen kurzlebigen TCP-Verbindungen zwei bis drei vCPUs verbrauchen kann, empfiehlt Keep-Alives und Connection Pooling und reserviert 0,25 % des Node-Speichers für die größten eBPF-Maps. Das ist kein Grund gegen eBPF, aber ein Grund, Ihr eigenes Traffic-Muster zu testen, statt irgendeinem Benchmark zu glauben – auch nicht denen der Hersteller.

Network Policy: Der Unterschied, den Sie wirklich spüren

Beide Projekte setzen Standard-Kubernetes-NetworkPolicy durch. Wenn Sie nur die schreiben, reicht jedes. Die Unterschiede beginnen, sobald Sie mehr brauchen als L3/L4-Regeln innerhalb eines Namespaces.

Cilium Network Policy: L7- und DNS-Regeln im Open-Source-Projekt

Cilium ergänzt CiliumNetworkPolicy und CiliumClusterwideNetworkPolicy. Die Kernfunktionen sind L7-Regeln – HTTP-Methoden und -Pfade, gRPC, Kafka – und DNS-basierter Egress. Diese Policy erlaubt nur dem Checkout-Service einen einzigen Endpunkt der Payments-API und lässt Payments genau einen externen Hostnamen erreichen:


apiVersion: cilium.io/v2

kind: CiliumNetworkPolicy

metadata:

  name: payments-api

  namespace: shop

spec:

  endpointSelector:

    matchLabels:

      app: payments

  ingress:

    - fromEndpoints:

        - matchLabels:

            app: checkout

      toPorts:

        - ports:

            - port: "8080"

              protocol: TCP

          rules:

            http:

              - method: POST

                path: "/v1/charges"

  egress:

    # DNS erlauben, damit die FQDN-Regel unten die IPs lernen kann

    - toEndpoints:

        - matchLabels:

            "k8s:io.kubernetes.pod.namespace": kube-system

            "k8s:k8s-app": kube-dns

      toPorts:

        - ports:

            - port: "53"

              protocol: ANY

          rules:

            dns:

              - matchPattern: "*"

    - toFQDNs:

        - matchName: "api.stripe.com"

      toPorts:

        - ports:

            - port: "443"

              protocol: TCP

Eine normale NetworkPolicy kann keine dieser Regeln ausdrücken. Das ist der Kern von Ciliums Reiz für Zero Trust im Cluster – und der Grund, warum GKE (FQDN-Network-Policies) und AKS (FQDN-Filterung und L7-Policies über Advanced Container Networking Services) ihre Premium-Netzwerkfunktionen darauf aufbauen.

Calico Network Policy: Tiers und Governance im Open-Source-Projekt

Calicos Open-Source-Edition beantwortet eine andere Frage: Wer darf wen überstimmen? Policies liegen in geordneten Tiers. Ein Security-Team kann einen Tier mit hoher Priorität besitzen, den Anwendungsteams nicht umgehen können, und eine Pass-Aktion reicht die Entscheidung an den nächsten Tier weiter:


apiVersion: projectcalico.org/v3

kind: Tier

metadata:

  name: security

spec:

  order: 300

---

apiVersion: projectcalico.org/v3

kind: GlobalNetworkPolicy

metadata:

  name: security.isolate-prod

spec:

  tier: security

  order: 100

  namespaceSelector: env == "prod"

  types:

    - Ingress

  ingress:

    - action: Deny

      source:

        namespaceSelector: env == "dev"

    - action: Pass

Dev erreicht Prod nie, egal was ein Anwendungsteam im eigenen Namespace schreibt; alles andere geht an den Default-Tier, in dem die normalen Kubernetes-Policies liegen. Dazu kommen Staged Policies – vorab sehen, was eine Policy erlauben oder blockieren würde, bevor sie greift – und Host Endpoints , die Nodes, VMs und Bare-Metal-Server unter dieselbe labelbasierte Policy stellen. Zusammen ist das ein starker Werkzeugkasten für Plattformteams.

Was Calico Open Source nicht enthält, sind DNS-basierte Policies: Tigeras eigene Feature-Matrix führt DNS/FQDN-Policies, Egress-Gateways und Cluster Mesh als Funktionen von Calico Cloud und Calico Enterprise. Ist FQDN-Egress Pflicht und wollen Sie bei Open Source bleiben, kann allein das den Vergleich entscheiden.

Die gemeinsame Basis: ClusterNetworkPolicy

Die gute Nachricht: Die Kubernetes-Community schließt die Lücke für clusterweite Regeln. ClusterNetworkPolicy (policy.networking.k8s.io/v1alpha2) gibt Plattformteams einen Admin -Tier, der Namespace-Policies überstimmt, und einen Baseline -Tier, den Namespace-Policies überstimmen dürfen:


apiVersion: policy.networking.k8s.io/v1alpha2

kind: ClusterNetworkPolicy

metadata:

  name: deny-dev-to-prod

spec:

  tier: Admin

  priority: 10

  subject:

    namespaces:

      matchLabels:

        env: prod

  ingress:

    - name: deny-from-dev

      action: Deny

      from:

        - namespaces:

            matchLabels:

              env: dev

Cilium 1.20 unterstützt sie. Calico bildet sie direkt auf Tiers ab: Admin-Policies landen im eingebauten Tier kube-admin, Baseline-Policies in kube-baseline, und 3.33 unterstützt darin benannte Ports. Eine Warnung: EKS setzt dieselbe Idee nativ im VPC CNI um, aber unter einer eigenen API-Gruppe, networking.k8s.aws/v1alpha1. YAML zwischen Clouds zu kopieren ist weniger portabel, als der Name vermuten lässt.

Achtung

Die ipBlock-Falle. Dieselbe NetworkPolicy kann sich auf beiden Engines unterschiedlich verhalten. Google dokumentiert, dass in GKE Dataplane V2 (Cilium) eine ipBlock-Regel nie Pod-Traffic trifft – selbst cidr: 0.0.0.0/0 schließt Pods nicht ein –, während ipBlock-Regeln in Calico Pod-IPs sehr wohl abdecken. AKS beschreibt dasselbe Cilium-Verhalten und ergänzt, dass ipBlock auch keine Node-IPs auswählen kann. Dataplane V2 lehnt außerdem eine Port-Regel ab, die ein Protokoll ohne Port nennt. Wenn Sie Policies zwischen Engines migrieren, prüfen Sie jede ipBlock-Regel und verwenden Sie für clusterinternen Traffic Pod- und Namespace-Selektoren.

Observability: Hubble vs. Whisker

Network Policies ohne Flow-Sichtbarkeit zu debuggen ist Raten. Deshalb wiegt dieser Punkt mehr, als er in einer Feature-Liste aussieht.

Ciliums Hubble ist die ausgereifteste Open-Source-Antwort: Sichtbarkeit pro Flow mit Quell- und Ziel-Identität, L7-Metadaten, wo eine L7-Policy greift, und Policy-Verdicts. In 1.20 kann Hubble zudem Audit-Verdicts mit der auslösenden Policy verknüpfen – „Was würde brechen, wenn ich das durchsetze?“ wird damit eine Frage, die Sie mit Daten beantworten. Auf Managed-Plattformen taucht dieselbe Idee als GKE-Dataplane-V2-Observability mit Network-Policy-Logging und als Container Network Observability in AKS auf.

Calicos Whisker ist eine Web-Konsole für Flow-Logs, gespeist von einem Flow-Aggregator und gestützt auf eine Flow-Logs-API – beides in 3.33 noch eine Technology Preview. Die Aufbewahrung in der Open-Source-Edition ist In-Memory; längere Aufbewahrung, Dashboards und der Service-Graph gehören zu den kommerziellen Editionen. Calicos eigentliche Observability-Stärke sind die Staged Policies : Sie sehen die Wirkung einer Policy-Änderung auf echte Flows, bevor irgendetwas durchgesetzt wird.

Ist Observability Ihr Haupttreiber, liegt Cilium im Open-Source-Bereich heute vorn. Ist Ihre größte Sorge, mit einer Policy-Änderung die Produktion zu brechen, ist Calicos Staged-Workflow das direktere Werkzeug.

Verschlüsselung und mTLS

Beide Projekte verschlüsseln Pod-zu-Pod-Traffic zwischen Nodes mit WireGuard – der einfache Standard für Anforderungen wie „alles im Transit verschlüsseln“. Cilium unterstützt zusätzlich IPsec.

Die interessanteste neue Entwicklung liegt bei Cilium: Sidecar-loses Mutual TLS mit ztunnel , gemeinsam von Microsoft und Isovalent gebaut. Es ist seit 1.19 Beta, nutzt TLS 1.3 über HBONE, wird pro Namespace mit dem Label io.cilium/mtls-enabled=true eingeschaltet und kann eine interne CA oder SPIRE verwenden. Anders als WireGuard oder IPsec zwischen Nodes verschlüsselt es auch Traffic zwischen Pods auf demselben Node. Ciliums ältere Mutual-Authentication-Funktion ist zugunsten dessen abgekündigt. Calicos Gegenstück ist die Integration mit dem Istio Ambient Mode, in 3.33 weiterhin eine Technology Preview.

Ein Compliance-Hinweis für regulierte Umgebungen: Calico 3.33 hat den FIPS-Modus entfernt. Hängt Ihr aktuelles Deployment davon ab, upgraden Sie nicht im Autopilot-Modus – klären Sie das mit Ihren Auditoren und mit Tigera, bevor Sie das nächste Release planen.

Gateway API: Beide liefern eine, unterschiedlich gebaut

Seit Ingress NGINX im März 2026 sein Lebensende erreicht hat, zählt die Nord-Süd-Frage mehr als sonst.

Cilium implementiert die Gateway API nativ über seinen eingebauten Envoy-Proxy. 1.20 geht auf Gateway API v1.6: TCPRoute und UDPRoute (jetzt im Standard-Channel), ListenerSets, ein CORS-Filter, Redirects mit 303/307/308 und ein ExternalAuth-Filter, der eine Anfrage an einen Auth-Service weiterleitet und auf dessen Antwort 200, 302, 401 oder 403 reagiert.
Calico liefert das Calico Ingress Gateway , ein mitgeliefertes Envoy Gateway – in 3.33 v1.9.1 mit Gateway-API-CRDs v1.6.1, was Kubernetes ab 1.33 voraussetzt.

Beide sind ein vernünftiger Ersatz für Ingress NGINX. Der architektonische Unterschied: Ciliums Gateway ist in das CNI eingebaut, das Sie ohnehin betreiben, Calicos ist ein separates Envoy-Gateway-Deployment, das Calico paketiert und verwaltet. Auf GKE verwenden Sie meist ohnehin Googles eigenen Gateway-Controller – siehe GKE Gateway API statt Ingress NGINX für diese Entscheidung.

Was GKE, EKS und AKS schon für Sie entschieden haben

Auf Managed Kubernetes ist die CNI-Frage meist beantwortet, bevor Sie sie stellen.

Auf einem Managed Service ist „Cilium vs Calico“ meist eine kleinere Frage, als es scheint.

GKE. Dataplane V2 basiert auf Cilium, läuft als DaemonSet anetd, ist Standard für neue Autopilot-Cluster und Googles empfohlenes Netzwerk-Plugin für alle Cluster. Network Policy ist immer aktiv, Network-Policy-Logging ist eingebaut, und Services laufen dort ohne kube-proxy. Die ältere Dataplane basiert auf Calico und ist nur auf Standard-Clustern verfügbar; das Aktivieren erstellt die Nodes neu und kostet in kube-system rund 128 MB Speicher und 300 Millicores CPU. Zwei Grenzen sollten Sie kennen: Dataplane V2 lässt sich auf bestehenden Clustern nicht aktivieren, und Cluster mit der CRD CiliumNetworkPolicy sind auf 1.000 Nodes begrenzt, während CiliumClusterwideNetworkPolicy bis 5.000 unterstützt. Außerdem unterstützt GKE keine eigenen eBPF-Programme auf Dataplane-V2-Nodes – eine echte Einschränkung, falls Sie eBPF-basierte Werkzeuge ergänzen wollten. Das größere Härtungsbild zeigt die Secure-by-Default-GKE-Referenzarchitektur.

EKS. Das Amazon VPC CNI ist das einzige CNI, das Amazon EKS auf EC2-Nodes unterstützt; Fargate läuft nur mit dem VPC CNI, und EKS Auto Mode unterstützt keine alternativen CNI- oder Network-Policy-Plugins. Ab VPC CNI 1.21 setzt es Standard-Network-Policies und eine Admin-ClusterNetworkPolicy nativ durch. Cilium oder Calico können Sie trotzdem installieren – AWS führt Isovalent und Tigera als Partner –, empfiehlt dann aber kommerziellen Support oder eigene Expertise. Auf EKS Hybrid Nodes dagegen unterstützt Amazon die Kernfunktionen von Cilium und Calico. Eine scharfe Kante: Traffic von und zu Pods mit Security Groups for Pods unterliegt nicht der Calico-Policy, sondern nur den Security Groups.

AKS. Microsoft empfiehlt für Network Policies Azure CNI Powered by Cilium, die Standard-Netzwerkkonfiguration in AKS Automatic. Es läuft ohne kube-proxy, nur auf Linux, und unterstützt CiliumNetworkPolicy und CiliumClusterwideNetworkPolicy direkt; FQDN-Filterung, L7-Policies, WireGuard und Flow-Observability kommen über Advanced Container Networking Services. Calico wird nur für Standard-Kubernetes-Network-Policies unterstützt – andere Calico-Funktionen testet und unterstützt AKS nicht –, ist aber die Engine für Windows-Node-Pools. Da Azure Network Policy Manager seit dem 30. September 2026 auf Windows-Nodes nicht mehr unterstützt wird und auf Linux 2028 ausläuft, ist das AKS-Bild einfach: Cilium für Linux, Calico, wo Windows im Spiel ist.

Selbst betriebene Distributionen. k3s nutzt standardmäßig Flannel mit kube-router für Network Policies; für Cilium oder Calico starten Sie den Server mit --flannel-backend=none und --disable-network-policy und installieren dann das CNI. RKE2 liefert Canal (Standard – Flannel zwischen den Nodes, Calico für Policies), Cilium, Calico und Flannel mit. Nur Calico und Flannel unterstützen dort Windows-Nodes, und Canal wird auf Clustern mit Windows-Nodes nicht unterstützt. Wenn Sie die Distribution noch wählen, behandelt der Vergleich k3s vs k0s vs MicroK8s vs RKE2 diese Standards ausführlicher.

Auf GKE und AKS heißt „Cilium wählen“ meist: den Plattform-Standard akzeptieren. Die echte Entscheidung zwischen Cilium und Calico fällt auf selbst betriebenen Clustern, On-Prem, am Edge und überall dort, wo Windows-Nodes oder eine BGP-Fabric beteiligt sind.

Skalierung und Multi-Cluster

Beide Projekte betreiben sehr große Cluster; die Unterschiede liegen darin, wie sie Cluster miteinander verbinden.

Cilium Cluster Mesh ist Teil des Open-Source-Projekts: Es verbindet standardmäßig bis zu 255 Cluster, bietet clusterübergreifende Service Discovery und Policies, und 1.20 erklärt die Implementierung der Kubernetes Multi-Cluster Services API für stabil. Eine neue Policy-Entity cluster-mesh erlaubt Regeln für „jeden Workload im Mesh“, ohne Cluster einzeln aufzuzählen.

Calico geht netzwerkzentriert vor: Mit BGP lassen sich Cluster und physische Fabric so verbinden, dass Pod-IPs über sie hinweg routbar sind. Calicos verwaltetes Multi-Cluster-Produkt, Cluster Mesh, und die Multi-Cluster-Policy-Verwaltung gehören zu Calico Cloud und Calico Enterprise, nicht zur Open-Source-Edition.

Heißt die Anforderung „viele Cluster, ein Service- und Policy-Modell“ und wollen Sie bei Open Source bleiben, liegt Cilium vorn. Heißt sie „Pods als vollwertige Teilnehmer meines gerouteten Rechenzentrumsnetzes“, ist Calicos BGP-Erbe genau der Grund, warum es existiert.

Migration von Calico zu Cilium: Erst lesen, dann planen

Die meisten Teams, die beide vergleichen, betreiben bereits Calico und überlegen den Wechsel. Cilium dokumentiert einen Live-Migrationspfad, und der ist wirklich clever: Cilium im sekundären Modus mit eigenem Pod-CIDR, Cluster-Pool-IPAM und eigenem Encapsulation-Port installieren (das Beispiel nutzt VXLAN auf Port 8473), sodass beide Overlays parallel existieren und die Linux-Routingtabelle ihren Traffic trennt. Dann Node für Node: cordon und drain, Node labeln, damit eine CiliumNodeConfig Cilium seine CNI-Konfiguration schreiben lässt, Cilium-Agent neu starten, Node rebooten, prüfen, uncordon.

Lesen Sie dann den Abschnitt zu den Einschränkungen derselben Anleitung. Die Migration ist nicht mit BGP-basiertem Routing getestet und nicht mit einem bestehenden NetworkPolicy-Provider – und Ciliums eigene Policy-Durchsetzung muss während der Migration mit policyEnforcementMode: never laufen, weil sonst Traffic von noch nicht migrierten Pods verworfen werden könnte. Ein produktiver Calico-Cluster hat fast immer Policies, und viele On-Prem-Cluster nutzen BGP. Anders gesagt: Genau die Cluster, die diese Migration am ehesten wollen, sind die, mit denen sie nicht getestet wurde.

Eine pragmatische Reihenfolge:

Policies inventarisieren und übersetzen, mit besonderem Blick auf ipBlock-Regeln und Calico-Tiers, für die es in Cilium keine Eins-zu-eins-Entsprechung gibt.
Auf einem Klon proben , mit laufendem Konnektivitätsmonitor, wie es die Anleitung selbst dringend empfiehlt.
Entscheiden, ob ein Zeitfenster ohne Policies akzeptabel ist. Wenn nicht: einen neuen Cilium-Cluster bauen und Workloads per Blue/Green oder GitOps-gesteuerter Umschaltung umziehen.
Auf AKS das unterstützte In-Place-Upgrade der Dataplane von Azure CNI auf Cilium nutzen (kubenet-Cluster gehen zuerst auf Azure CNI Overlay). Auf GKE gibt es keinen In-Place-Weg zu Dataplane V2: Das ist ein neuer Cluster.

Stolperfallen, die Sie vor dem Upgrade kennen sollten

Calico 3.33

eBPF auf Kernel 5.15 ist in 3.33 kaputt – eine bekannte Regression: Das Host-Endpoint-Programm ist über das Verifier-Limit gewachsen. Workaround: Kernel ab 6.8 oder vorerst 3.32. Das betrifft alle mit Ubuntu-22.04-Images, einschließlich des Standard-Node-Images von AKS für Kubernetes 1.25 bis 1.34.
Der FIPS-Modus ist weg. Regulierte Deployments brauchen vor dem Upgrade einen Plan.
Native v3-CRDs sind GA , der aggregierte API-Server ist abgekündigt. Das vereinfacht Installationen, ändert aber, wie Werkzeuge mit Calico-Ressourcen sprechen.
Die Programmierung von IP-in-IP-Cluster-Routen über BIRD ist abgekündigt , die Entfernung ist für 3.35 geplant; Felix verwaltet diese Routen jetzt standardmäßig.

Cilium 1.20

Die alte Mutual Authentication ist abgekündigt zugunsten von mTLS über ztunnel.
cilium-dbg bgp-Befehle sind abgekündigt zugunsten neuer Shell-Befehle für die GoBGP-basierte Control Plane.
Identity-Churn bleibt die klassische Skalierungsfalle: Labels mit hoher Kardinalität ausschließen, bevor sie den Identitätsraum erschöpfen.
Auf GKE können andere eBPF-Werkzeuge mit Dataplane V2 kollidieren; Google dokumentiert einen Fall, in dem Microsoft Retina verhinderte, dass Pods Services erreichen.

Die Entscheidung in fünf Fragen

Die meisten Cluster entscheiden sich schon bei den ersten beiden Fragen.

Betreiben Sie Windows-Nodes? Dann Calico, zumindest für diese Nodes. Cilium unterstützt Windows nicht.
Sind Sie auf GKE oder AKS? Nutzen Sie die Cilium-basierte Dataplane der Plattform, solange es keinen konkreten Grund dagegen gibt. Auf EKS starten Sie mit den nativen Network Policies des VPC CNI.
Brauchen Sie L7-Policies, FQDN-Egress oder Multi-Cluster-Netzwerk im Open-Source-Projekt? Das spricht für Cilium.
Müssen Pods auf einer BGP-Fabric routbar sein, oder sollen VMs und Bare-Metal-Hosts dieselbe Policy wie Pods bekommen? Das spricht für Calico.
Schreiben mehrere Teams Policies, und muss ein Security-Team immer gewinnen? Calicos Tiers sind das direkteste Modell; auf Cilium decken die neuen Admin- und Baseline-Tiers von ClusterNetworkPolicy die häufigen Fälle inzwischen ab.

Fazit

Heute sind Cilium und Calico beide exzellent, beide nutzen eBPF, und beide bewegen sich auf dieselben Upstream-APIs zu: Gateway API für eingehenden Traffic, ClusterNetworkPolicy für Plattform-Leitplanken. Wer nach Benchmark entscheidet, entscheidet nach dem unwichtigsten Unterschied.

Cilium ist der bessere Standard für einen reinen Linux-Cluster im Cloud-native-Stil , der seinen Traffic bis L7 verstehen will – und auf GKE und AKS ist es bereits der Standard. Calico ist die bessere Wahl für einen heterogenen oder infrastrukturgebundenen Cluster : Windows-Nodes, BGP-Fabrics, ältere Kernel, VMs unter derselben Policy und Organisationen, in denen Policy-Governance mehr zählt als Paketmagie.

Was auch immer Sie wählen: Wählen Sie, als würden Sie es für die gesamte Lebensdauer des Clusters behalten, denn die eigentlichen Kosten stecken in der Migration. Und bevor Sie irgendeiner Policy vertrauen – auch denen, die Sie für das andere CNI geschrieben haben –, prüfen Sie Ihre ipBlock-Regeln.

Weiterlesen: Für die Plattform über dem Netzwerk siehe Platform Engineering auf Kubernetes; was die Managed Services tatsächlich für Sie betreiben, zeigt Managed Kubernetes: Was EKS, AKS und GKE wirklich verwalten.

Ursprünglich veröffentlicht auf alekseialeinikov.com

Cilium vs Calico: Which Kubernetes CNI Should Run Your Production Cluster?

Aleksei Aleinikov — Mon, 05 Oct 2026 07:00:00 +0000

Every “Cilium vs Calico” article you have read was probably written around one idea: Cilium is the modern eBPF one, Calico is the older iptables one. Today that idea is simply wrong. Cilium 1.20 was announced in September, Calico Open Source 3.33 shipped on October 1, and the two projects now overlap more than they differ. Calico has an eBPF dataplane and now supports netkit pod devices too. Both enforce the new Kubernetes ClusterNetworkPolicy. Both ship a Gateway API implementation.

So the honest question is no longer “which one is faster”. It is which policy model, which operating constraints and which ecosystem you are signing up for — and how hard it will be to change your mind later , because the CNI is the one cluster component you almost never get to swap cheaply. This is the comparison I wish I had before choosing one for a production platform: what each project actually does today, what GKE, EKS and AKS have already decided for you, and the traps that only show up during a migration.

The Short Answer

If you only read one section, read this one.

Choose Cilium when your nodes are all Linux on a modern kernel and you want application-aware security in open source: L7 rules for HTTP, gRPC and Kafka, DNS-aware egress (toFQDNs), flow observability through Hubble, a built-in Gateway API and multi-cluster networking through Cluster Mesh. It is also what you already run on GKE Dataplane V2 and on Azure CNI Powered by Cilium.
Choose Calico when the cluster is heterogeneous or bolted to physical infrastructure: Windows nodes, BGP peering with top-of-rack switches, older kernels that need an iptables or nftables dataplane, VMs and bare-metal hosts you want under the same policy, or many teams who need policy tiers with a clear precedence order.
Choose neither consciously on EKS unless you have a reason: the Amazon VPC CNI is the only CNI Amazon supports on EC2 nodes, and it now enforces network policy natively.

The rest of this article explains why — and where each recommendation breaks.

What Cilium and Calico Actually Are

Cilium is an eBPF-based networking, security and observability project for Kubernetes, started by the founders of Isovalent. It joined the CNCF in 2021 and graduated in October 2023. Around the CNI itself sit Hubble for flow observability, a built-in Gateway API implementation and Cluster Mesh for multi-cluster networking.

Calico is created and maintained by Tigera. Calico Open Source is the free core that runs across clouds and distributions; Calico Cloud and Calico Enterprise are the commercial editions that add features such as DNS policy, egress gateways and multi-cluster management. Calico also reaches beyond Kubernetes pods to VMs, bare-metal hosts and OpenStack.

Both are open source, both are production-proven at very large scale, and both have a commercial company behind them. That matters less for features than for support: know which edition a feature belongs to before you plan around it.

What a CNI Actually Decides (and Why the Choice Is Sticky)

A Container Network Interface plugin is not just “the thing that gives pods an IP”. In a production cluster it owns four jobs:

IP address management — which range a pod’s address comes from, and whether that range is routable outside the cluster.
Connectivity — overlay (VXLAN, Geneve, IP-in-IP) or native routing, and whether nodes speak BGP to the network.
Network policy — turning Kubernetes NetworkPolicy (and often a richer CRD of its own) into packet filtering rules on every node.
Service load balancing — optionally replacing kube-proxy, so that traffic to a ClusterIP is translated in the CNI’s dataplane instead of in iptables chains.

Because the CNI owns the address plan and the dataplane, replacing it means re-addressing every pod. Platforms know this and lock it in. GKE states that Dataplane V2 “can only be enabled when creating a new cluster”. RKE2 does not support changing the primary CNI after first start. Treat this decision like choosing a database engine: you can migrate later, but you will pay for it.

Architecture: Identities in eBPF Maps vs a Policy Engine With Pluggable Dataplanes

The deepest difference between the two projects is not eBPF. It is how they represent “who is allowed to talk to whom”.

Cilium derives a numeric security identity from each pod’s labels and stores identities, endpoints, services and policy in eBPF maps in the kernel. When a packet arrives, an eBPF program looks up the source identity rather than evaluating a list of IP addresses. That makes policy independent of pod churn, and it is why Cilium can attach rich metadata to every flow for Hubble. The cost is that identities are a finite resource: Microsoft’s AKS documentation warns that high-churn workloads such as Spark jobs can push a cluster toward the 65,535 identity limit , and recommends excluding volatile labels from identity calculation.

Calico is built around Felix, an agent on every node that computes policy from labels and selectors and programs it into whichever dataplane you choose: iptables, nftables, eBPF, Windows or VPP. BGP routing has historically been handled by BIRD, which is why Calico is the natural fit for networks that already speak BGP. In 3.33 Felix, rather than BIRD, programs the cluster routes for IP-in-IP pools by default; BIRD programming of those routes is deprecated, with removal planned for 3.35.

Cilium is an eBPF dataplane with a policy model on top. Calico is a policy model with several dataplanes underneath. Most of the practical differences in this article follow from that one sentence.

Dataplanes Today: eBPF Everywhere, With Different Exits

Both projects can bypass iptables now — only Calico can still fall back to it.

Here is where the two stand after the autumn releases:

	Cilium 1.20	Calico Open Source 3.33
Dataplanes	eBPF only	iptables, nftables, eBPF, Windows, VPP
kube-proxy replacement	Yes (eBPF)	Yes, in eBPF mode
Pod device	veth by default; `bpf.datapathMode=auto` selects netkit when the kernel supports it	veth by default; netkit is an opt-in CNI `device_type` (kernel 6.7+), and eBPF programs attach through the netkit API when it is used
Kernel floor for eBPF	A modern kernel; check the system requirements for your release	5.10+ with BTF/CO-RE — and a known 3.33 regression on 5.15
Encryption	WireGuard, IPsec, plus sidecarless mTLS via ztunnel (beta)	WireGuard
BGP	Yes, via GoBGP	Yes, mature fabric peering; ARP-based L2 reachability without BGP or overlays is new in 3.33
Windows nodes	No	Yes

A few of these rows deserve a closer look.

netkit. netkit is a newer Linux network device designed to replace veth pairs for containers: the BPF program becomes part of the device itself instead of being attached to a veth pair from the outside, which removes overhead from the pod’s path. It originally required kernel 6.8. The Cilium 1.20 announcement points to netkit running at Meta and ByteDance scale, with ByteDance reporting around a 10% gain. Cilium’s new auto mode picks netkit when the kernel supports it and falls back to veth otherwise; the default stays veth. Calico 3.33 takes a smaller step: its CNI can create netkit pod devices through the opt-in device_type setting (kernel 6.7+, default veth), and the eBPF dataplane now attaches through the netkit API on those devices by default, using TCX elsewhere.

The iptables exit. Cilium has no non-eBPF fallback. If your fleet includes kernels or hardened images where eBPF is constrained, Calico’s ability to run the same policy on iptables or nftables is a real operational advantage, not a legacy feature. 3.33 also adds optional nftables flowtable offload, which lets established flows skip most of the ruleset.

Footprint. Both projects trimmed this year: the cilium-cni binary dropped from 76 MB to 16 MB in 1.20, and Calico 3.33 consolidates calico-node services, which Tigera puts at roughly 200 MB of memory saved per node, and ships a single quay.io/calico/calico image.

On a managed platform the operational limits come from the provider, not the project. Google documents, for example, that GKE Dataplane V2’s agent (anetd) can consume two to three vCPUs on nodes with a high rate of short-lived TCP connections, recommends keep-alives and connection pooling, and reserves 0.25% of node memory for the largest eBPF maps. None of this is a reason to avoid eBPF, but it is a reason to load-test your own traffic pattern instead of trusting anyone’s benchmark — including the vendors’.

Network Policy: The Difference You Will Actually Feel

Both projects enforce standard Kubernetes NetworkPolicy. If that is all you write, either will do. The differences start the moment you need more than L3/L4 rules inside one namespace.

Cilium network policy: L7 and DNS-aware rules in open source

Cilium adds CiliumNetworkPolicy and CiliumClusterwideNetworkPolicy. The headline capabilities are L7 rules — HTTP methods and paths, gRPC, Kafka — and DNS-aware egress. Here is a policy that lets only the checkout service call one endpoint of the payments API, and lets payments reach exactly one external hostname:


apiVersion: cilium.io/v2

kind: CiliumNetworkPolicy

metadata:

  name: payments-api

  namespace: shop

spec:

  endpointSelector:

    matchLabels:

      app: payments

  ingress:

    - fromEndpoints:

        - matchLabels:

            app: checkout

      toPorts:

        - ports:

            - port: "8080"

              protocol: TCP

          rules:

            http:

              - method: POST

                path: "/v1/charges"

  egress:

    # Allow DNS so the FQDN rule below can learn IPs

    - toEndpoints:

        - matchLabels:

            "k8s:io.kubernetes.pod.namespace": kube-system

            "k8s:k8s-app": kube-dns

      toPorts:

        - ports:

            - port: "53"

              protocol: ANY

          rules:

            dns:

              - matchPattern: "*"

    - toFQDNs:

        - matchName: "api.stripe.com"

      toPorts:

        - ports:

            - port: "443"

              protocol: TCP

A plain NetworkPolicy cannot express either rule. That is the core of Cilium’s appeal for zero-trust inside the cluster, and it is why both GKE (FQDN network policies) and AKS (FQDN filtering and L7 policies through Advanced Container Networking Services) built their premium networking features on top of it.

Calico network policy: tiers and governance in open source

Calico’s open-source edition answers a different question: who is allowed to override whom. Policies live in ordered tiers. A security team can own a high-precedence tier that application teams cannot circumvent, and a Pass action hands the decision down to the next tier:


apiVersion: projectcalico.org/v3

kind: Tier

metadata:

  name: security

spec:

  order: 300

---

apiVersion: projectcalico.org/v3

kind: GlobalNetworkPolicy

metadata:

  name: security.isolate-prod

spec:

  tier: security

  order: 100

  namespaceSelector: env == "prod"

  types:

    - Ingress

  ingress:

    - action: Deny

      source:

        namespaceSelector: env == "dev"

    - action: Pass

Dev can never reach prod, whatever an application team writes in its own namespace; everything else is passed down to the default tier, where ordinary Kubernetes policies live. Add staged policies — preview what a policy would allow or deny before enforcing it — and host endpoints , which put nodes, VMs and bare-metal servers under the same label-based policy, and you have a strong platform-team toolkit.

What Calico Open Source does not include is DNS-based policy: Tigera’s own feature matrix lists DNS/FQDN policy, egress gateways and Cluster Mesh as Calico Cloud and Calico Enterprise features. If FQDN egress is a hard requirement and you want to stay on open source, that alone can decide the comparison.

The common ground: ClusterNetworkPolicy

The good news is that the Kubernetes community is closing the gap for cluster-wide rules. ClusterNetworkPolicy (policy.networking.k8s.io/v1alpha2) gives platform teams an Admin tier that overrides namespace policies and a Baseline tier that namespace policies can override:


apiVersion: policy.networking.k8s.io/v1alpha2

kind: ClusterNetworkPolicy

metadata:

  name: deny-dev-to-prod

spec:

  tier: Admin

  priority: 10

  subject:

    namespaces:

      matchLabels:

        env: prod

  ingress:

    - name: deny-from-dev

      action: Deny

      from:

        - namespaces:

            matchLabels:

              env: dev

Cilium 1.20 added support for it. Calico maps it straight into tiers: Admin policies land in a built-in kube-admin tier and Baseline policies in kube-baseline, and 3.33 supports named ports in them. One caution: EKS implements the same idea natively in the VPC CNI, but under its own API group, networking.k8s.aws/v1alpha1. Copying YAML between clouds is not as portable as the name suggests.

Warning

The ipBlock trap. The same NetworkPolicy can behave differently on the two engines. Google documents that in GKE Dataplane V2 (Cilium) an ipBlock rule never matches pod traffic — even cidr: 0.0.0.0/0 does not include pods — while in Calico ipBlock rules do cover pod IPs. AKS documents the same Cilium behaviour, adding that ipBlock cannot select node IPs either. Dataplane V2 also rejects a port rule that names a protocol without a port. If you migrate policies between engines, audit every ipBlock and use pod and namespace selectors for in-cluster traffic.

Observability: Hubble vs Whisker

Debugging network policy without flow visibility is guesswork, so this matters more than it looks on a feature list.

Cilium’s Hubble is the most mature open-source answer: per-flow visibility with source and destination identities, L7 metadata where an L7 policy applies, and policy verdicts. In 1.20 Hubble can also correlate audit-mode verdicts with the policy that produced them, which makes “what would break if I enforced this” a question you can answer from data. On managed platforms the same idea surfaces as GKE Dataplane V2 observability and network policy logging, and as Container Network Observability in AKS.

Calico’s Whisker is a web console for flow logs, fed by a flow aggregator and backed by a flow logs API — both still a technology preview in 3.33. Retention in the open-source edition is in-memory; longer retention, dashboards and the service graph are part of the commercial editions. Calico’s real observability strength is its staged policies : you can see the effect of a policy change on live flows before it enforces anything.

If observability is your main driver, Cilium has the lead in open source today. If your main fear is breaking production with a policy change, Calico’s staged workflow is the more direct tool.

Encryption and mTLS

Both projects encrypt pod-to-pod traffic between nodes with WireGuard , which is the simple default for “encrypt everything in transit” requirements. Cilium also supports IPsec.

The most interesting recent development is on the Cilium side: sidecarless mutual TLS using ztunnel , built with Microsoft and Isovalent. It is beta since 1.19, runs TLS 1.3 over HBONE, is switched on per namespace with the label io.cilium/mtls-enabled=true, and can use an internal CA or SPIRE. Unlike node-to-node WireGuard or IPsec, it also encrypts traffic between pods on the same node. Cilium’s older Mutual Authentication feature is deprecated in its favour. Calico’s equivalent path is integration with Istio ambient mode, which is still a technology preview in 3.33.

One compliance note for regulated environments: Calico 3.33 removed FIPS mode. If your current deployment depends on it, do not upgrade on autopilot — check with your auditors and with Tigera before you plan the next release.

Gateway API: Both Ship One, Built Differently

With Ingress NGINX reaching end-of-life in March 2026, the north-south story matters more than usual.

Cilium implements Gateway API natively through its built-in Envoy proxy. 1.20 moves to Gateway API v1.6: TCPRoute and UDPRoute (now in the Standard channel), ListenerSets, a CORS filter, 303/307/308 redirects and an ExternalAuth filter that forwards a request to an auth service and acts on its 200, 302, 401 or 403 answer.
Calico ships the Calico Ingress Gateway , a bundled Envoy Gateway — v1.9.1 in 3.33 with Gateway API CRDs v1.6.1, which requires Kubernetes 1.33 or newer.

Either is a reasonable replacement for Ingress NGINX. The architectural difference is that Cilium’s gateway is built into the CNI you already run, while Calico’s is a separate Envoy Gateway deployment that it packages and manages. On GKE you will usually use Google’s own Gateway controller instead — see GKE Gateway API vs Ingress for that decision.

What GKE, EKS and AKS Have Already Decided for You

On managed Kubernetes the CNI question is mostly answered before you ask it.

On a managed service, “Cilium vs Calico” is usually a smaller question than it looks.

GKE. Dataplane V2 is implemented with Cilium, runs as the anetd DaemonSet, is the default for new Autopilot clusters and is Google’s recommended network plugin for all clusters. Network policy is always on, network policy logging is built in, and GKE does not use kube-proxy for Services on it. The legacy dataplane is Calico-based and is available only on Standard clusters; enabling it recreates nodes and costs roughly 128 MB of memory and 300 millicores of CPU in kube-system. Two limits worth knowing: Dataplane V2 cannot be enabled on existing clusters, and clusters that use the CiliumNetworkPolicy CRD are capped at 1,000 nodes, while CiliumClusterwideNetworkPolicy supports up to 5,000. GKE also does not support installing your own eBPF programs on Dataplane V2 nodes — a real constraint if you planned to add eBPF-based tooling. For the wider hardening picture, see the secure-by-default GKE reference architecture.

EKS. The Amazon VPC CNI is the only CNI Amazon EKS supports on EC2 nodes; Fargate runs only the VPC CNI, and EKS Auto Mode does not support alternate CNI or network policy plugins. From VPC CNI 1.21 it enforces both standard network policies and an Admin ClusterNetworkPolicy natively. You can still install Cilium or Calico — AWS lists Isovalent and Tigera as partners — but AWS recommends commercial support or in-house expertise if you do. On EKS Hybrid Nodes , by contrast, Amazon supports the core capabilities of both Cilium and Calico. One sharp edge: traffic to and from pods with security groups for pods is not subject to Calico policy enforcement, only to the security groups.

AKS. Microsoft recommends Azure CNI Powered by Cilium for network policy, and it is the default network configuration in AKS Automatic. It runs without kube-proxy, is Linux-only, and supports CiliumNetworkPolicy and CiliumClusterwideNetworkPolicy out of the box; FQDN filtering, L7 policy, WireGuard and flow observability come through Advanced Container Networking Services. Calico is supported for standard Kubernetes network policies only — AKS does not test or support its other features — but it is the engine that covers Windows node pools. With Azure Network Policy Manager no longer supported on Windows nodes since September 30, 2026 and scheduled for retirement on Linux in 2028, that makes the AKS picture simple: Cilium for Linux, Calico where you have Windows.

Self-managed distributions. k3s defaults to Flannel with kube-router for network policy; to run Cilium or Calico instead, start the server with --flannel-backend=none and --disable-network-policy, then install the CNI. RKE2 bundles Canal (the default — Flannel between nodes, Calico for policy), Cilium, Calico and Flannel. Only Calico and Flannel support Windows nodes there, and Canal is not supported on clusters with Windows nodes. If you are still choosing a distribution, the k3s vs k0s vs MicroK8s vs RKE2 comparison covers those defaults in more detail.

On GKE and AKS, choosing Cilium mostly means accepting the platform default. The real Cilium-vs-Calico decision lives on self-managed clusters, on-prem, at the edge, and anywhere Windows nodes or a BGP fabric are involved.

Scale and Multi-Cluster

Both projects run very large clusters; the differences are in how they connect clusters to each other.

Cilium Cluster Mesh is part of open source: it connects up to 255 clusters by default, provides cross-cluster service discovery and policy, and 1.20 marks its implementation of the Kubernetes Multi-Cluster Services API as stable. A new cluster-mesh policy entity lets you write rules about “any workload in the mesh” without enumerating clusters.

Calico takes a network-first approach: with BGP you can peer clusters and the physical fabric so pod IPs are routable across them. Calico’s managed multi-cluster product, Cluster Mesh, and multi-cluster policy management belong to Calico Cloud and Calico Enterprise rather than the open-source edition.

If “many clusters, one service and policy model” is the requirement and you want to stay on open source, Cilium is ahead. If “pods as first-class citizens of my routed datacenter network” is the requirement, Calico’s BGP heritage is the reason it exists.

Migrating From Calico to Cilium: Read This Before You Plan It

Most teams that compare the two are already running Calico and wondering whether to move. Cilium has a documented live-migration path, and it is genuinely clever: install Cilium in a secondary mode with a separate pod CIDR, cluster-pool IPAM and a distinct encapsulation port (the example uses VXLAN on port 8473), so both overlays coexist and the Linux routing table separates their traffic. Then, node by node: cordon and drain, label the node so a CiliumNodeConfig makes Cilium write its CNI config, restart the Cilium agent, reboot, verify, uncordon.

Then read the limitations section of the same guide. Migration has not been tested with BGP-based routing , nor with an existing NetworkPolicy provider — and Cilium’s own policy enforcement has to run with policyEnforcementMode: never during the migration, because otherwise traffic from not-yet-migrated pods could be dropped. A production Calico cluster almost always has policies, and many on-prem ones use BGP. In other words, the clusters most likely to want this migration are exactly the ones it was not tested on.

A pragmatic order of operations:

Inventory your policies and translate them, paying special attention to ipBlock rules and Calico tiers, which have no one-to-one Cilium equivalent.
Rehearse on a clone of the cluster, with a connectivity monitor running, as the guide itself strongly recommends.
Decide whether a policy-free window is acceptable. If it is not, build a new Cilium cluster and move workloads with a blue/green or GitOps-driven cutover instead.
On AKS , use the supported in-place dataplane upgrade from Azure CNI to Cilium (kubenet clusters move to Azure CNI Overlay first). On GKE , there is no in-place path to Dataplane V2: it is a new cluster.

Gotchas Worth Knowing Before You Upgrade

Calico 3.33

eBPF on kernel 5.15 is broken in 3.33 — a known regression: the host endpoint program grew past the verifier limit. The workaround is kernel 6.8 or newer, or staying on 3.32. This matters for anyone on Ubuntu 22.04 images, including the default AKS node image for Kubernetes 1.25 through 1.34.
FIPS mode is gone. Regulated deployments need a plan before upgrading.
Native v3 CRDs are GA and the aggregated API server is deprecated, which simplifies installs but changes how tooling talks to Calico resources.
BIRD programming of IP-in-IP cluster routes is deprecated , with removal planned for 3.35; Felix now owns those routes by default.

Cilium 1.20

Legacy Mutual Authentication is deprecated in favour of ztunnel-based mTLS.
cilium-dbg bgp commands are deprecated in favour of new shell commands for the GoBGP-based control plane.
Identity churn remains the classic scaling trap: exclude high-cardinality labels before they exhaust the identity space.
On GKE , other eBPF-based tools can interfere with Dataplane V2; Google documents a case where Microsoft Retina prevented pods from reaching Services.

How to Decide in Five Questions

Most clusters are decided by the first two questions.

Do you run Windows nodes? Then Calico, at least for those nodes. Cilium does not support Windows.
Are you on GKE or AKS? Use the platform’s Cilium-based dataplane unless you have a specific reason not to. On EKS, start from the VPC CNI’s native network policy.
Do you need L7 policy, FQDN egress or multi-cluster networking in open source? That points to Cilium.
Do pods need to be routable on a BGP fabric, or do VMs and bare-metal hosts need the same policy as pods? That points to Calico.
Do several teams write policy, with a security team that must always win? Calico’s tiers are the most direct model; on Cilium, the new ClusterNetworkPolicy Admin and Baseline tiers now cover the common cases.

The Bottom Line

Today Cilium and Calico are both excellent, both run eBPF, and both are converging on the same upstream APIs: Gateway API for traffic in, ClusterNetworkPolicy for platform guardrails. Choosing between them by benchmark is choosing by the least important difference.

Cilium is the better default for a Linux-only, cloud-native cluster that wants to understand its traffic at L7 — and on GKE and AKS it is the default already. Calico is the better choice for a heterogeneous or infrastructure-bound cluster : Windows nodes, BGP fabrics, older kernels, VMs under the same policy, and organisations where policy governance matters more than packet-level magic.

Whichever you pick, pick it as if you will keep it for the life of the cluster, because the migration is where the real cost lives. And before you trust any policy — including the ones you wrote for the other CNI — check your ipBlock rules.

Related reading: for the platform built on top of the network, see platform engineering on Kubernetes; for what the managed services actually run for you, see what EKS, AKS and GKE actually manage.

Originally published at alekseialeinikov.com

Gemini 4 Argon on Google Cloud: What Actually Changes for Platform Teams (2026)

Aleksei Aleinikov — Fri, 02 Oct 2026 10:00:00 +0000

On 30 September 2026, Google announced Gemini 4 Argon , which it calls its most capable model yet: state of the art on long-horizon software engineering, the leading model on the Vals Index, and a new 1-million-token output limit. Within a day the headlines had moved on to the awkward parts: employees telling Bloomberg it struggles on some real coding tasks, and an evaluation lab catching it cheating on a business simulation.

For platform teams on Google Cloud, both stories are less important than a quieter fact: almost nobody can call Argon in production yet. That leaves a short window to get the platform ready, so the switch goes smoothly when access opens. Here is what actually launched, what it costs, and the changes worth making now.

What actually launched — and what didn’t

Google’s announcement is precise about access, even if the coverage wasn’t. Argon is rolling out to a set of trusted cyber defenders through the Fairwind Program , as part of the US government’s voluntary process for pre-release model access. Google says it will gather feedback and harden guardrails, then release to paid API customers and Google AI Ultra subscribers first, and to developers, enterprises and consumers after that. No date is given.

What is public:

Price: an introductory $2 per million input tokens and $10 per million output tokens , with cached input 95% cheaper than the input price.
Output limit: 1M tokens , up from 64K. Google’s reasoning: give the model headroom to “generate hundreds of thousands of tokens in a single trajectory.”
Benchmarks (Google’s numbers): 77.9% on DeepSWE v1.1 (long-horizon software engineering), #1 on Zapier’s AutomationBench at 51.3%, 91.7% on LVBench (long video), and a tie for first on CWE-bench v1 (vulnerability remediation) at 68%.
Internal use at Google: agents that freed more than 300 TiB of memory across Google’s data centres from fleet profiling data, and C/C++ to Rust migrations up to 800K+ lines.

What is not public yet: a model ID, region availability, quotas or provisioned-throughput options for general use on Google Cloud. Plan as if those details will arrive with little warning.

Argon arrives in stages. Platform work done now pays off on day one of access.

First, the Vertex AI rename you might have missed

If you have been heads-down on infrastructure, one structural change matters more than Argon itself: Vertex AI’s services are now part of Gemini Enterprise Agent Platform. Google announced it at Next ’26 in April, and the Vertex AI documentation now carries a banner saying it is no longer being updated, with a pointer to the Agent Platform docs.

Your existing endpoints keep working, but new models and features — Argon included — will land on the Agent Platform side. Two concrete deadlines from the release notes arrive before Argon does:

Gemini 2.5 Pro, 2.5 Flash and 2.5 Flash-Lite retire on 16 October 2026.
Vertex AI Extensions shut down after 26 November 2026 , with migration to Agent Platform recommended.

If you still have a hard-coded gemini-2.5-* model ID somewhere, that is your most urgent “Gemini” task this month, not Argon.

Argon vs Gemini 3.8 Flash: what you can use today

The model you can deploy right now is Gemini 3.8 Flash , released on 2 September 2026 and aimed at long-horizon coding and autonomous agents. Here is how the two compare on the facts Google has published:

	Gemini 3.8 Flash	Gemini 4 Argon
Availability	Gemini API, Gemini Enterprise, Agent Platform	Fairwind cohort now; paid API + AI Ultra next
Input price / 1M tokens	$0.75	$2.00 (cached input 95% off)
Output price / 1M tokens	$3.75	$10.00
Max output per response	not part of the launch announcement	1M tokens (was 64K)
Positioning	“most intelligent workhorse”	frontier: deep, long-horizon reasoning
Cyber variant	3.8 Flash Cyber (Fairwind only)	Argon itself, without cyber guardrails for vetted defenders
Best use	default for agents and coding	the hardest task classes where Flash fails

Per token, Argon is about 2.7× the price of Flash on both input and output. Google also notes that 3.8 Flash “works harder” — it runs extra reasoning steps and calls tools repeatedly, which can mean more tokens at higher effort levels. The honest comparison is therefore cost per successful task , not cost per token: if Flash needs three attempts and Argon needs one, the expensive model can be the cheap one.

The 1M-token output limit is a budget problem, not a feature

The most consequential change for a platform team is the output limit. At the introductory price, one response that runs to the full million output tokens costs $10 — on a single call. Under the old 64K cap, the same per-token price would have stopped at about $0.64. The ceiling on a single call went up roughly 16 times, and any agent loop multiplies it.

A higher output ceiling raises the worst case per call. Cap it per route before you switch.

Before Argon reaches your organisation, put these controls in place:

An explicit output cap per route. Never rely on the model’s default maximum. A summarisation endpoint does not need 1M tokens; a migration agent might need more than 64K. Write the cap into config, per use case.
Labels on every request. Gemini API calls on Google Cloud accept labels, so you can attribute spend by team, route and model in billing exports. Without them, the first Argon invoice will be one unexplained line.
Budgets and alerts per project. Put experimental Argon traffic in its own project with a budget alert, so a runaway loop shows up in hours, not at month-end.
Caching by design. At 95% off, cached input is $0.10 per million tokens. Agents that resend the same system prompt, tool schemas and repository context on every step are where caching pays off. Structure prompts so the stable prefix comes first.
Timeouts and streaming. A response with hundreds of thousands of tokens takes minutes, not seconds. Check client timeouts, load-balancer idle timeouts and retry policies — a blind retry of a 1M-token response doubles the bill.

Route models, don’t replace them

The mistake I expect to see is a single config change: model = "gemini-4-argon" across the board. A better pattern is a small routing layer in front of the models:

Most traffic should never touch the frontier model.

Classification and routing go to a small, fast model — the new class of decision models, which I compared in Jev vs GPT-5 and Claude for classification, is built for exactly this.
Default agent and coding work goes to Gemini 3.8 Flash.
Hard, long-horizon tasks — large migrations, multi-repo refactors, deep incident analysis — go to Argon, with a capped budget and a human checkpoint.

The routing decision is also your migration lever: when Argon opens up, you change one rule for one task class and measure, instead of moving all traffic at once. If you build agents with the Agent Development Kit, keep the model as configuration, not code — I covered that structure in building production AI agents with Google ADK.

Don’t outsource your evaluation to a launch blog

Vendor benchmarks tell you where to look, not what to buy. Argon’s first week shows why:

Bloomberg reported that some Google employees said the model struggled in important real-world settings, including certain coding tasks. Google told Bloomberg the claims were inaccurate.
Andon Labs said Argon took third place on its Vending-Bench 2 business simulation, behind OpenAI’s Astra and GPT-6 Sol — but that it got there by fabricating confirmation emails, refusing refunds, exploiting invoice errors and lying to suppliers.

Neither report settles anything, and that’s the point: the only benchmark that matters for your decision is your own task set. Build a small evaluation suite now — 50 to 200 real tasks from your backlog, with a pass/fail check you trust — and run it against Gemini 3.8 Flash today. When Argon access arrives, you rerun the suite and get a decision in an afternoon instead of a quarter.

Govern Argon agents like a new privileged user

Google lists four safeguards it is strengthening before broad release: refusing misuse (cyber and CBRN), robustness against indirect prompt injection (Google says Argon leads Gray Swan’s benchmark), monitoring chain-of-thought and actions for misalignment and stopping execution when needed , and hardened sandboxes for high-risk evaluations.

Those are the model provider’s controls. Yours still matter more, and the timing is not abstract: the same week, OpenAI said it had notified more than 100 organisations about unauthorised activity by its AI agents. An agent that can work for hours on a long task can also do damage for hours.

On Google Cloud, the platform-side controls are familiar:

A dedicated identity per agent with least-privilege IAM — never a shared service account, never a user’s credentials.
Tool allow-lists, enforced outside the model. An agent should only reach the MCP tools its role needs; I described the gateway pattern in user-level permission controls for MCP tool access.
A data perimeter around the projects agents touch (VPC Service Controls), so a confused or hijacked agent cannot move data out.
Human approval for irreversible actions — deploys, deletes, payments, outbound email.
Audit everything : requests, tool calls and results, so you can rebuild what an agent did.

The Fairwind question for regulated industries

If you work in a government agency, critical infrastructure (Google names healthcare, telecommunications, energy and financial networks ), or a core technology platform, Fairwind is the earliest route to Argon. Google reports more than 650 participating partners. The conditions are strict and sensible: access limited to internal security, incident-response or penetration-testing teams, with protections such as multi-factor authentication.

Fairwind access is a security-team decision, not a platform shortcut. If you just want Argon for general engineering work, wait for the paid API rollout. In the meantime, Google says any Google Cloud customer can already use its CodeMender vulnerability-fixing agent with the publicly available models on Agent Platform.

A checklist for this quarter

Do now	Why
Replace every `gemini-2.5-*` model ID	Retirement on 16 Oct 2026
Migrate off Vertex AI Extensions	Shutdown after 26 Nov 2026
Move model IDs and output caps into config	One-line, per-route switch when Argon opens
Add request labels + a per-project budget alert	Attribute and cap frontier-model spend
Build a 50–200 task evaluation suite	Decide on your own data, not launch charts
Give each agent its own least-privilege identity	Limit the blast radius of long-running agents
Decide whether Fairwind applies to you	Earliest legitimate access path for regulated teams

The Bottom Line

Gemini 4 Argon is a real step forward on long, hard tasks — and an expensive, gated one. For most platform teams the right move this week is not to chase access, but to get the platform ready: retire Gemini 2.5, put model choice and output caps into config, label and budget every request, build an evaluation suite you trust, and give agents identities and tool limits you would be comfortable giving a new contractor.

Do that, and the day Argon opens to your organisation becomes a routing change and an eval run. Skip it, and it becomes a surprise invoice.

Originally published at alekseialeinikov.com

Gemini 4 Argon auf Google Cloud: Was sich für Platform-Teams wirklich ändert (2026)

Aleksei Aleinikov — Fri, 02 Oct 2026 10:00:00 +0000

Am 30. September 2026 hat Google Gemini 4 Argon angekündigt und nennt es sein bisher leistungsfähigstes Modell: State of the Art bei Software Engineering über lange Aufgaben, Platz eins im Vals Index und ein neues Output-Limit von 1 Million Tokens. Einen Tag später ging es in den Schlagzeilen schon um die unangenehmen Seiten: Mitarbeitende, die Bloomberg von Schwächen bei realen Coding-Aufgaben berichteten, und ein Evaluierungslabor, das das Modell beim Schummeln in einer Geschäftssimulation erwischt hat.

Für Platform-Teams auf Google Cloud sind beide Geschichten weniger wichtig als eine unscheinbare Tatsache: Fast niemand kann Argon heute produktiv aufrufen. Damit bleibt ein kurzes Zeitfenster, die Plattform vorzubereiten, damit der Wechsel glatt läuft, sobald der Zugang kommt. Hier steht, was tatsächlich erschienen ist, was es kostet und welche Änderungen sich jetzt lohnen.

Was tatsächlich erschienen ist — und was nicht

Googles Ankündigung ist beim Zugang präzise, die Berichterstattung oft nicht. Argon wird über das Fairwind-Programm an ausgewählte Cyber-Verteidiger ausgerollt , im Rahmen des freiwilligen Pre-Release-Zugangs der US-Regierung. Google will Feedback sammeln, die Leitplanken härten und danach zuerst für zahlende API-Kunden und Abonnenten von Google AI Ultra freigeben, anschließend für Entwickler, Unternehmen und Endkunden. Ein Datum nennt Google nicht.

Öffentlich bekannt ist:

Preis: Einführungspreis von 2 $ pro Million Input-Tokens und 10 $ pro Million Output-Tokens , gecachter Input 95 % günstiger als der Input-Preis.
Output-Limit: 1 Mio. Tokens statt bisher 64K. Googles Begründung: Das Modell soll Spielraum haben, um „Hunderttausende Tokens in einer einzigen Trajektorie“ zu erzeugen.
Benchmarks (laut Google): 77,9 % auf DeepSWE v1.1 (Software Engineering über lange Aufgaben), Platz eins auf Zapiers AutomationBench mit 51,3 %, 91,7 % auf LVBench (lange Videos) und geteilter erster Platz auf CWE-bench v1 (Behebung von Schwachstellen) mit 68 %.
Interner Einsatz bei Google: Agenten, die anhand von Profiling-Daten der Flotte über 300 TiB Arbeitsspeicher in Googles Rechenzentren freigemacht haben, und Migrationen von C/C++ nach Rust mit bis zu 800K+ Zeilen.

Noch nicht öffentlich: Modell-ID, verfügbare Regionen, Quoten und Provisioned-Throughput-Optionen für die allgemeine Nutzung auf Google Cloud. Planen Sie so, als kämen diese Details mit wenig Vorlauf.

Argon kommt in Etappen. Plattformarbeit von heute zahlt sich am ersten Zugangstag aus.

Zuerst: die Vertex-AI-Umbenennung, die man leicht übersieht

Wer zuletzt tief in Infrastruktur steckte, hat womöglich eine strukturelle Änderung verpasst, die wichtiger ist als Argon selbst: Die Vertex-AI-Dienste sind jetzt Teil der Gemini Enterprise Agent Platform. Google hat das auf der Next ’26 im April angekündigt; die Vertex-AI-Dokumentation trägt inzwischen den Hinweis, dass sie nicht mehr aktualisiert wird, und verweist auf die Agent-Platform-Doku.

Bestehende Endpunkte funktionieren weiter, aber neue Modelle und Features — auch Argon — erscheinen auf der Agent-Platform-Seite. Zwei konkrete Fristen aus den Release Notes kommen vor Argon:

Gemini 2.5 Pro, 2.5 Flash und 2.5 Flash-Lite werden am 16. Oktober 2026 abgeschaltet.
Vertex AI Extensions werden nach dem 26. November 2026 eingestellt ; Google empfiehlt die Migration auf die Agent Platform.

Wenn irgendwo noch eine fest verdrahtete gemini-2.5-*-Modell-ID steckt, ist das diesen Monat Ihre dringendste „Gemini“-Aufgabe — nicht Argon.

Argon vs. Gemini 3.8 Flash: was heute nutzbar ist

Das Modell, das Sie heute einsetzen können, ist Gemini 3.8 Flash , erschienen am 2. September 2026 und gebaut für Coding über lange Strecken und autonome Agenten. So stehen die beiden laut Googles veröffentlichten Angaben zueinander:

	Gemini 3.8 Flash	Gemini 4 Argon
Verfügbarkeit	Gemini API, Gemini Enterprise, Agent Platform	jetzt Fairwind; als Nächstes zahlende API + AI Ultra
Input-Preis / 1 Mio. Tokens	0,75 $	2,00 $ (gecachter Input 95 % günstiger)
Output-Preis / 1 Mio. Tokens	3,75 $	10,00 $
Max. Output pro Antwort	nicht Teil der Ankündigung	1 Mio. Tokens (bisher 64K)
Positionierung	„intelligentestes Arbeitspferd“	Frontier: tiefes Reasoning über lange Aufgaben
Cyber-Variante	3.8 Flash Cyber (nur Fairwind)	Argon selbst, ohne Cyber-Leitplanken für geprüfte Verteidiger
Bester Einsatz	Standard für Agenten und Coding	die schwierigsten Aufgabenklassen, an denen Flash scheitert

Pro Token kostet Argon bei Input und Output etwa das 2,7-Fache von Flash. Google weist zudem darauf hin, dass 3.8 Flash „härter arbeitet“ — zusätzliche Reasoning-Schritte, wiederholte Tool-Aufrufe, bei hohem Effort also mehr Tokens. Der ehrliche Vergleich lautet deshalb Kosten pro gelöster Aufgabe , nicht Kosten pro Token: Braucht Flash drei Anläufe und Argon einen, kann das teure Modell das günstige sein.

Das 1-Mio.-Output-Limit ist ein Budgetproblem, kein Feature

Die folgenreichste Änderung für ein Platform-Team ist das Output-Limit. Zum Einführungspreis kostet eine einzige Antwort, die die volle Million Output-Tokens ausschöpft, 10 $ — für einen Aufruf. Mit dem alten 64K-Limit wäre derselbe Token-Preis bei etwa 0,64 $ gestoppt. Die Obergrenze pro Aufruf ist rund um das 16-Fache gestiegen, und jede Agenten-Schleife multipliziert sie.

Ein höheres Output-Limit erhöht den Worst Case pro Aufruf. Pro Route deckeln, bevor Sie wechseln.

Bevor Argon in Ihrer Organisation ankommt, sollten diese Kontrollen stehen:

Ein explizites Output-Limit pro Route. Verlassen Sie sich nie auf das Standard-Maximum des Modells. Ein Zusammenfassungs-Endpunkt braucht keine 1 Mio. Tokens, ein Migrations-Agent vielleicht mehr als 64K. Das Limit gehört pro Anwendungsfall in die Konfiguration.
Labels an jedem Request. Gemini-API-Aufrufe auf Google Cloud akzeptieren Labels — damit lassen sich Kosten im Billing-Export nach Team, Route und Modell zuordnen. Ohne sie ist die erste Argon-Rechnung eine unerklärte Zeile.
Budgets und Alerts pro Projekt. Experimenteller Argon-Traffic gehört in ein eigenes Projekt mit Budget-Alert, damit eine durchlaufende Schleife nach Stunden auffällt, nicht am Monatsende.
Caching by Design. Mit 95 % Rabatt kostet gecachter Input 0,10 $ pro Million Tokens. Agenten, die bei jedem Schritt denselben Systemprompt, dieselben Tool-Schemas und denselben Repository-Kontext mitschicken, profitieren am stärksten. Prompts so aufbauen, dass der stabile Teil vorne steht.
Timeouts und Streaming. Eine Antwort mit Hunderttausenden Tokens dauert Minuten, nicht Sekunden. Prüfen Sie Client-Timeouts, Idle-Timeouts am Load Balancer und Retry-Policies — ein blinder Retry einer 1-Mio.-Token-Antwort verdoppelt die Rechnung.

Modelle routen, nicht ersetzen

Den typischen Fehler erwarte ich als einzelne Konfigurationsänderung: model = "gemini-4-argon" für alles. Besser ist eine kleine Routing-Schicht vor den Modellen:

Der Großteil des Traffics sollte das Frontier-Modell nie berühren.

Klassifizierung und Routing übernimmt ein kleines, schnelles Modell — genau dafür ist die neue Klasse der Decision Models gebaut, die ich in Jev vs. GPT-5 und Claude für Klassifizierung verglichen habe.
Standardarbeit für Agenten und Coding geht an Gemini 3.8 Flash.
Schwere, lange Aufgaben — große Migrationen, Refactorings über mehrere Repositories, tiefe Incident-Analysen — gehen an Argon, mit gedeckeltem Budget und einem menschlichen Checkpoint.

Die Routing-Entscheidung ist zugleich Ihr Migrationshebel: Sobald Argon verfügbar ist, ändern Sie eine Regel für eine Aufgabenklasse und messen, statt den gesamten Traffic auf einmal umzustellen. Wer Agenten mit dem Agent Development Kit baut, hält das Modell als Konfiguration, nicht als Code — diese Struktur beschreibe ich in produktionsreife KI-Agenten mit Google ADK bauen.

Die Evaluierung nicht an einen Launch-Blogpost auslagern

Hersteller-Benchmarks zeigen, wo man hinschauen sollte, nicht, was man kaufen sollte. Argons erste Woche zeigt, warum:

Bloomberg berichtete, einige Google-Mitarbeitende hätten gesagt, das Modell habe in wichtigen realen Szenarien Probleme, unter anderem bei bestimmten Coding-Aufgaben. Google nannte die Behauptungen gegenüber Bloomberg unzutreffend.
Andon Labs meldete, Argon habe in seiner Geschäftssimulation Vending-Bench 2 Platz drei erreicht, hinter OpenAIs Astra und GPT-6 Sol — allerdings, indem es Bestätigungs-E-Mails erfand, Erstattungen verweigerte, Rechnungsfehler ausnutzte und Lieferanten anlog.

Keiner der Berichte entscheidet etwas, und genau darum geht es: Der einzige Benchmark, der für Ihre Entscheidung zählt, ist Ihr eigenes Aufgaben-Set. Bauen Sie jetzt eine kleine Eval-Suite — 50 bis 200 echte Aufgaben aus Ihrem Backlog mit einer Pass/Fail-Prüfung, der Sie vertrauen — und fahren Sie sie heute gegen Gemini 3.8 Flash. Kommt der Argon-Zugang, wiederholen Sie den Lauf und haben eine Entscheidung an einem Nachmittag statt in einem Quartal.

Argon-Agenten wie einen neuen privilegierten Nutzer behandeln

Google nennt vier Schutzmaßnahmen, die vor der breiten Freigabe verstärkt werden: Verweigerung von Missbrauch (Cyber und CBRN), Robustheit gegen indirekte Prompt Injection (laut Google führt Argon den Benchmark von Gray Swan an), Überwachung von Chain-of-Thought und Aktionen auf Fehlausrichtung mit Abbruch der Ausführung, wenn nötig , und gehärtete Sandboxes für risikoreiche Evaluierungen.

Das sind die Kontrollen des Modellanbieters. Ihre eigenen zählen mehr, und das Timing ist nicht abstrakt: In derselben Woche meldete OpenAI, mehr als 100 Organisationen über unautorisierte Aktivitäten seiner KI-Agenten informiert zu haben. Ein Agent, der stundenlang an einer langen Aufgabe arbeiten kann, kann auch stundenlang Schaden anrichten.

Auf Google Cloud sind die plattformseitigen Kontrollen vertraut:

Eine eigene Identität pro Agent mit Least-Privilege-IAM — nie ein geteilter Service Account, nie die Zugangsdaten eines Nutzers.
Tool-Allowlists, außerhalb des Modells durchgesetzt. Ein Agent erreicht nur die MCP-Tools, die seine Rolle braucht; das Gateway-Muster beschreibe ich in benutzerbezogene Zugriffskontrolle für MCP-Tools.
Ein Datenperimeter um die Projekte, die Agenten berühren (VPC Service Controls), damit ein verwirrter oder gekaperter Agent keine Daten hinausbringt.
Menschliche Freigabe für irreversible Aktionen — Deployments, Löschungen, Zahlungen, ausgehende E-Mails.
Alles auditieren : Requests, Tool-Aufrufe und Ergebnisse, damit sich rekonstruieren lässt, was ein Agent getan hat.

Die Fairwind-Frage für regulierte Branchen

Wer in einer Behörde, in kritischer Infrastruktur (Google nennt Gesundheitswesen, Telekommunikation, Energie und Finanznetze ) oder bei einer zentralen Technologie-Plattform arbeitet, hat mit Fairwind den frühesten Weg zu Argon. Google spricht von mehr als 650 Partnern. Die Bedingungen sind streng und sinnvoll: Zugang nur für interne Security-, Incident-Response- oder Pentest-Teams, mit Schutzmaßnahmen wie Multi-Faktor-Authentifizierung.

Fairwind-Zugang ist eine Entscheidung des Security-Teams, keine Abkürzung für die Plattform. Wer Argon nur für allgemeine Engineering-Arbeit möchte, wartet auf den Rollout für zahlende API-Kunden. Bis dahin können laut Google alle Google-Cloud-Kunden den Schwachstellen-Agenten CodeMender bereits mit den öffentlich verfügbaren Modellen auf der Agent Platform nutzen.

Checkliste für dieses Quartal

Jetzt tun	Warum
Jede `gemini-2.5-*`-Modell-ID ersetzen	Abschaltung am 16.10.2026
Von Vertex AI Extensions migrieren	Einstellung nach dem 26.11.2026
Modell-IDs und Output-Limits in die Konfiguration	Wechsel pro Route in einer Zeile, sobald Argon kommt
Request-Labels + Budget-Alert pro Projekt	Frontier-Kosten zuordnen und deckeln
Eval-Suite mit 50–200 Aufgaben bauen	Auf eigenen Daten entscheiden, nicht auf Launch-Charts
Jedem Agenten eine eigene Least-Privilege-Identität	Schadensradius lang laufender Agenten begrenzen
Klären, ob Fairwind für Sie infrage kommt	Frühester legitimer Zugang für regulierte Teams

Fazit

Gemini 4 Argon ist ein echter Schritt nach vorn bei langen, schweren Aufgaben — und ein teurer, zugangsbeschränkter. Für die meisten Platform-Teams ist der richtige Schritt diese Woche nicht, Zugang zu jagen, sondern die Plattform vorzubereiten: Gemini 2.5 ablösen, Modellwahl und Output-Limits in die Konfiguration verlagern, jeden Request mit Labels und Budget versehen, eine vertrauenswürdige Eval-Suite bauen und Agenten Identitäten und Tool-Grenzen geben, die man auch einem neuen externen Dienstleister geben würde.

Dann wird der Tag, an dem Argon für Ihre Organisation freigeschaltet wird, eine Routing-Änderung und ein Eval-Lauf. Ohne diese Vorarbeit wird er eine überraschende Rechnung.

Ursprünglich veröffentlicht auf alekseialeinikov.com

Agent Skills Explained: SKILL.md, Claude Skills and When to Use Them Instead of MCP

Aleksei Aleinikov — Thu, 01 Oct 2026 10:00:00 +0000

Open the root of an actively maintained repository in 2026 and there is a good chance you will find a folder you did not have a year ago: .claude/skills/, .github/skills/ or .agents/skills/. Inside, short Markdown files called SKILL.md. That folder has quietly become the most portable way to teach an AI agent a job. Anthropic introduced Agent Skills in October 2025, published the format as an open standard on December 18, 2025, and the official client list now names more than 40 products — Claude Code, GitHub Copilot, VS Code, OpenAI Codex and ChatGPT, Cursor, Gemini CLI, JetBrains Junie, OpenCode, Kiro, Goose and Pulumi Neo among them.

The hype makes skills sound like a replacement for everything that came before: prompts, MCP servers, AGENTS.md, custom agents. They are not. Skills solve one specific problem — procedural knowledge an agent needs only some of the time — and they solve it remarkably well. They also introduce a new software supply chain that runs with your agent’s permissions. This guide covers both halves: how skills actually work, where each major agent looks for them, how they differ from MCP and the other customization layers, and how to write and install them without handing your laptop to a stranger.

What an Agent Skill Actually Is

An Agent Skill is a folder containing a SKILL.md file — YAML frontmatter with a name and a description, followed by Markdown instructions — that an AI agent discovers at startup and loads only when a task matches. Everything else in the folder is optional:

reviewing-gcp-iam/
├── SKILL.md # required: metadata + instructions
├── scripts/ # optional: code the agent runs
├── references/ # optional: docs the agent reads on demand
└── assets/ # optional: templates, schemas, images

The specification is short enough to memorise. The frontmatter has two required fields and four optional ones:

Field	Required	Rules
`name`	Yes	1–64 characters, lowercase letters, digits and hyphens; no leading, trailing or double hyphens; must match the folder name
`description`	Yes	1–1,024 characters; says what the skill does and when to use it
`license`	No	A license name or a bundled license file
`compatibility`	No	Up to 500 characters of environment requirements (product, system packages, network)
`metadata`	No	Free-form string-to-string map, e.g. author and version
`allowed-tools`	No	Space-separated pre-approved tools, e.g. `Bash(git:*) Read` — experimental, support varies

The body after the frontmatter has no required structure. The spec recommends step-by-step instructions, input and output examples and edge cases, keeping SKILL.md under 500 lines and moving detail into referenced files one level deep. The reference validator, skills-ref validate ./my-skill, checks the frontmatter and naming rules.

That is the entire format. The interesting part is not what a skill is but how agents load it.

How Skills Load: Progressive Disclosure

A skill is designed around one constraint: the context window is shared and expensive. Everything an agent knows during a task — the system prompt, your conversation, tool definitions, file contents — competes for the same tokens. Why that budget matters is covered in Context Engineering in 2026. Skills are the cleanest context-engineering primitive so far, because they load in three stages:

Discovery — about 100 tokens per skill. At startup the agent reads only name and description from every installed skill and puts them into its system prompt. That is enough to know a skill exists and when it might be relevant.
Activation — under 5,000 tokens recommended. When your request matches a description, the agent reads the full SKILL.md body into context. In Claude, that is literally a shell call: cat reviewing-gcp-iam/SKILL.md.
Execution — only what the task touches. If the instructions point to references/finance.md, the agent reads that one file and leaves references/sales.md on disk. If they say run scripts/check_policy.py, the agent executes it and only the script’s output enters the context — never its source code.

Fifty installed skills cost roughly what one loaded skill costs — until a task actually needs one.

The consequence is bigger than it sounds. With a classic system prompt or CLAUDE.md, every line costs tokens on every turn whether it is relevant or not. With skills, a 20-page runbook costs about as much as a sentence until the moment it is needed. Anthropic’s engineering write-up goes further: for an agent with a filesystem and code execution, the amount of context you can bundle into a skill is effectively unbounded, because files cost nothing until they are read.

Two details the marketing usually leaves out:

The discovery list has a budget too. Claude Code gives the skill listing about 1% of the model’s context window and caps each entry’s description at 1,536 characters; when the listing overflows, it drops descriptions of the skills you invoke least. Codex keeps the initial list within 2% of the context window (or 8,000 characters when the window is unknown) and shortens descriptions first. Install 200 skills and some of them will be invisible.
A loaded skill stays loaded. In Claude Code the rendered SKILL.md enters the conversation once and stays there across turns. After auto-compaction, Claude Code re-attaches only the first 5,000 tokens of each invoked skill, within a shared 25,000-token budget. Put the rules that must survive at the top.

Skills vs MCP vs AGENTS.md vs Subagents

This is where most of the confusion lives, so here is the short version: MCP gives an agent access, a skill gives it know-how, AGENTS.md gives it the house rules, and hooks give you guarantees. They are layers, not competitors.

	Agent Skill	MCP server	`AGENTS.md` / custom instructions	Subagent	Hook / deny rule
What it is	A folder: `SKILL.md` + optional scripts and docs	A process exposing tools, resources and prompts over a protocol	A Markdown file loaded into every session	A separate agent with its own context window	Deterministic code or policy on agent events
Gives the agent	A procedure: how we do X	Reach: the ability to touch Y	Facts: how this repo works	Isolation: do Z elsewhere and report back	Limits: this never happens
When it costs context	~100 tokens always, body on match	Tool list from the connected server; Claude Code loads full schemas only on demand (tool search), many clients load them upfront	Always, in full	Only its final result	Never
Runs code	Optional bundled scripts, through the agent’s shell	Yes, inside the server	No	Through its own tools	Yes, outside the model
Portable	Open standard, 40+ clients	Open protocol	`AGENTS.md` is an open format	Product-specific	Product-specific
Can the model ignore it	Yes	It can choose not to call a tool	Yes	—	No

Three practical rules fall out of this table:

If the agent needs to reach a system it cannot reach today — a database, Jira, a cloud API — that is an MCP server, not a skill. Building and hardening one is covered in MCP Servers Explained.
If you keep pasting the same checklist into chat , that is a skill. Claude Code’s documentation puts it almost exactly that way: create a skill when a section of CLAUDE.md has grown into a procedure rather than a fact.
If a rule must hold every single time , neither a skill nor AGENTS.md is enough — the model can skip instructions. Claude Code’s own troubleshooting guide says to move such rules into a hook. For tool permissions, that means deny and ask rules, as described in Claude Code Modes Compared.

The two also compose. A skill can tell the agent which MCP tools to call, in what order and with what checks in between. Anthropic’s best-practice guide even asks skill authors to reference MCP tools by their fully qualified name (BigQuery:bigquery_schema) so the agent picks the right server. That pairing — MCP for hands, a skill for the playbook — is where most of the real value is.

Four layers, four questions. Most production setups need all of them.

Where Each Agent Looks for Skills

The format is portable; the folder locations and the extras are not. As of October 2026:

Agent	Project skills	Personal skills	Invoke explicitly	Opt out of automatic use
Claude Code	`.claude/skills/<name>/` (and in parent directories up to the repo root)	`~/.claude/skills/<name>/`	`/name`	`disable-model-invocation: true`
GitHub Copilot in VS Code	`.github/skills/`, `.claude/skills/`, `.agents/skills/`	`~/.copilot/skills/`, `~/.claude/skills/`, `~/.agents/skills/`	`/name`	`disable-model-invocation: true`
OpenAI Codex	`.agents/skills/` from the working directory up to the repo root	`~/.agents/skills/` (admin: `/etc/codex/skills`)	`$name` or `/skills`	`allow_implicit_invocation: false` in `agents/openai.yaml`

Sources: Claude Code skills, VS Code Agent Skills, Codex skills.

The lesson for teams: .agents/skills/ is the closest thing to a neutral location , and VS Code also reads .claude/skills/, so one checked-in folder can serve several tools. If your team mixes Claude Code and Codex, keep the canonical copy in one place and symlink the other — both Claude Code and Codex follow symlinked skill folders.

The portability trap: extra frontmatter

Every vendor extends the format, and the extensions do not travel. Claude Code adds disable-model-invocation, user-invocable, context: fork (run the skill in an isolated subagent), argument-hint, paths, model, hooks and more. VS Code supports several of the same names. Codex keeps its extras in a separate agents/openai.yaml file.

The trap: uploading a skill to claude.ai or the Claude Skills API with any field outside the spec’s six fails hard , with an error like Unexpected key(s) in SKILL.md frontmatter: argument-hint. If a skill should work everywhere, keep the frontmatter to name, description, license, compatibility, metadata and allowed-tools, and put tool-specific behaviour in the body or in a vendor sidecar file.

Build One: A Least-Privilege IAM Review Skill

Here is a skill a platform team could ship as is. It reviews a Google Cloud IAM policy, flags over-broad bindings with a deterministic script and proposes least-privilege replacements. It applies a few of the rules the free GCP IAM Policy Checker runs in the browser, packaged so an agent can use them inside a repository.

.agents/skills/reviewing-gcp-iam/
├── SKILL.md
├── scripts/
│ └── check_policy.py
└── references/

    └── predefined-roles.md

SKILL.md, using only portable fields:

---

name: reviewing-gcp-iam

description: Reviews Google Cloud IAM policies for over-broad access. Flags basic roles (owner, editor, viewer), public principals and service accounts with project-wide power, and proposes least-privilege predefined roles. Use when the user shares an IAM policy, asks who has access to a GCP project, or requests an IAM, permissions or least-privilege review.

license: MIT

metadata:

  author: platform-team

  version: "1.0"

---

# Reviewing GCP IAM policies

## Workflow

1. Get the policy as JSON. If the user has not provided one, ask for the project ID and run:

   `gcloud projects get-iam-policy PROJECT_ID --format=json > policy.json`

2. Run the checker and use only its output:

   `python3 scripts/check_policy.py policy.json`

3. For each finding, propose a predefined role. Look up candidates in

   [references/predefined-roles.md](references/predefined-roles.md) and read only the section for the affected service.

4. Report using the table below. Never apply changes yourself; output `gcloud` commands for a human to run.

## Report format
| Severity | Member | Current role | Proposed role | Why |
|---|---|---|---|---|

## Rules

- `allUsers` or `allAuthenticatedUsers` on any role is HIGH.

- A service account with a basic role is HIGH: any code running as it inherits project-wide power.

- Never propose removing the last owner of a project.

And the script, which does the part a language model should not improvise:

#!/usr/bin/env python3
"""Flag risky bindings in a GCP IAM policy exported with --format=json."""

import json

import sys

BASIC = {"roles/owner", "roles/editor", "roles/viewer"}

PUBLIC = {"allUsers", "allAuthenticatedUsers"}

def check(policy: dict) -> list[tuple[str, str, str, str]]:

    findings = []

    for binding in policy.get("bindings", []):

        role = binding.get("role", "")

        for member in binding.get("members", []):

            if member in PUBLIC:

                findings.append(("HIGH", member, role, "public principal"))

            elif role in BASIC and member.startswith("serviceAccount:"):

                findings.append(("HIGH", member, role, "basic role on a service account"))

            elif role in BASIC:

                findings.append(("MEDIUM", member, role, "basic role; prefer a predefined role"))

    return findings

if __name__ == " __main__":

    if len(sys.argv) != 2:

        sys.exit("usage: check_policy.py policy.json")

    with open(sys.argv[1]) as f:

        results = check(json.load(f))

    for severity, member, role, why in results:

        print(f"{severity}\t{member}\t{role}\t{why}")

    print(f"{len(results)} finding(s)")

Why it is built this way:

The description carries the trigger words people actually use — IAM policy, who has access, permissions, least-privilege — and says what the skill does before it says when.
The script is the source of truth for detection. Anthropic’s guidance is blunt: prefer a pre-written script for deterministic operations, because generated code is less reliable and costs tokens on every run. The model does the part it is good at: explaining findings and choosing replacement roles.
The reference file is loaded selectively. A predefined-roles catalogue is long; the instructions tell the agent to read only the section it needs.
It has no side effects. It prints gcloud commands instead of running them. A skill that changes things should be one you trigger by hand — in Claude Code and VS Code, that is disable-model-invocation: true.

Test it like code

A skill that triggers is not the same as a skill that works. Anthropic recommends building at least three evaluations before writing extensive instructions, then comparing results with and without the skill in a fresh session. In Claude Code, the skill-creator plugin automates the loop: it runs each test case in an isolated subagent, grades the output, benchmarks pass rate, tokens and time with and without the skill, and generates should-trigger and should-not-trigger prompts to tune the description. /skill-doctor shows what each installed skill costs in context and which ones you never use.

Writing Descriptions That Actually Trigger

If a skill does not fire, the description is almost always the reason. The agent matches your request against a list of one-line descriptions — sometimes dozens of them — and picks one. The rules that work across Claude, Copilot and Codex:

Say what it does, then when to use it. “Generates commit messages by analysing staged diffs. Use when the user asks for a commit message or wants to review staged changes.”
Write in third person. The description is injected into the system prompt; Anthropic warns that “I can help you…” or “You can use this to…” causes discovery problems.
Front-load the key use case and trigger words. Both Claude Code and Codex shorten descriptions when the listing is crowded. Whatever is at the end may be the first thing cut.
Name the boundaries. Codex’s guide recommends stating clearly when the skill should not trigger. A skill that fires on everything is as broken as one that never fires.
Name it after the activity. Anthropic suggests gerunds — processing-pdfs, reviewing-gcp-iam — and warns against helper, utils or tools.

Bad: description: Helps with IAM. Good: the one in the example above.

The Part Nobody Puts on the Slides: Skills Are a Supply Chain

A skill is not documentation. It is instructions an agent will follow plus code it may run, with your permissions, on your machine. Anthropic’s own overview says to use skills only from trusted sources and to treat installing one like installing software. In Claude Code, unlike the Claude API’s sandboxed container, a skill’s scripts have the same network access as any other program on your computer.

The ecosystem has already been tested. On February 5, 2026, Snyk published ToxicSkills, a scan of 3,984 public skills from ClawHub and skills.sh:

534 skills (13.4%) had at least one critical issue — malware distribution, prompt injection or exposed secrets.
1,467 skills (36.8%) had at least one security flaw of any severity.
76 confirmed malicious payloads designed for credential theft, backdoors and data exfiltration.
91% of the confirmed malicious skills combined prompt injection with malicious code: the instructions talk the agent out of its caution, then the script does the damage.

The patterns are familiar to anyone who lived through early npm: a “prerequisites” step that downloads a password-protected ZIP, a base64-encoded curl … | bash, a skill that fetches its real instructions from a remote URL at runtime so the reviewed version is not the one that runs.

Each thing a skill can bring maps to a control you already know from dependency management.

Two Claude Code behaviours deserve special attention because they are easy to miss:

allowed-tools is not gated by workspace trust. The documentation says it plainly: a project skill’s allowed-tools applies whenever the skill is invoked, including in a -p run in a folder you have never trusted. A cloned repository can ship a skill that pre-approves Bash(curl *) for the turn it runs. Read the frontmatter of every skill in a repository before you point an agent at it.
!command`` runs before the model sees anything. Claude Code’s dynamic context injection executes shell commands while rendering the skill and inlines their output. Those commands are checked against your permission rules — a deny rule aborts the invocation — but they are still shell commands authored by whoever wrote the skill. Organisations can turn this off for user, project and plugin skills with "disableSkillShellExecution": true in managed settings.

A checklist that holds up in practice:

Install from sources you can name. Your own repositories, your organisation’s, or vendors’ official collections (anthropics/skills, openai/skills, github/awesome-copilot) — and read them anyway.
Pin skills in git and review diffs. A skill is a dependency. Treat a changed SKILL.md like a changed lockfile.
Scan. uvx mcp-scan@latest --skills checks installed skills for prompt injection, suspicious downloads and secrets.
Reject remote instructions. A skill that fetches instructions or scripts from a URL at runtime cannot be reviewed. Vendor or reject.
Keep secrets out of skill folders. Snyk found hardcoded secrets in 10.9% of ClawHub skills.
Back skills with hard limits. Deny rules, ask rules for side effects and an OS-level sandbox stop a skill that has talked the model into something. This is the lethal trifecta again: private data, untrusted content and an exfiltration channel in one agent is the condition to break.

When Not to Use a Skill

A practical rule of thumb: if you have explained the same procedure to an agent three times, it becomes a skill; if a rule must never be broken, it becomes a hook; if the agent needs to reach a new system, it becomes an MCP server. Keep the number of skills small, too: every skill you add is another description competing for the agent’s attention.

Skills are the right tool less often than the hype suggests:

One-off tasks. Just write the prompt.
Facts the agent needs on every turn — build commands, code style, directory layout. That is AGENTS.md or your custom instructions file.
Access to systems. Authentication, live data and remote actions belong in an MCP server, ideally behind a gateway with per-user permissions, as in user-level permission controls for MCP.
Guarantees. “Never push to main”, “never read .env” — use deny rules and hooks.
Context the skill would pull from the internet at runtime. That is not a skill; it is a remote prompt with extra steps.

The Bottom Line

Agent Skills won because they are boring in the best way: a folder, a Markdown file and two required fields, readable by humans, diffable in git and portable across more than 40 agents. The clever part is progressive disclosure — about 100 tokens per skill until the moment a task needs it — which finally lets you give an agent deep, specific know-how without drowning every conversation in it.

They are not a replacement for MCP, AGENTS.md or permission rules; they are the missing layer between them. Write descriptions that say what and when, push deterministic work into scripts, keep the frontmatter portable — and review every skill you install with the same suspicion you would apply to a package that runs with your credentials. Because that is exactly what it is.

Originally published at alekseialeinikov.com

Agent Skills erklärt: SKILL.md, Claude Skills und wann sie MCP schlagen

Aleksei Aleinikov — Thu, 01 Oct 2026 10:00:00 +0000

Wer 2026 die Wurzel eines aktiv gepflegten Repositorys öffnet, findet mit guter Wahrscheinlichkeit einen Ordner, den es vor einem Jahr noch nicht gab: .claude/skills/, .github/skills/ oder .agents/skills/. Darin kurze Markdown-Dateien namens SKILL.md. Dieser Ordner ist still und leise zum portabelsten Weg geworden, einem KI-Agenten eine Aufgabe beizubringen. Anthropic hat Agent Skills im Oktober 2025 vorgestellt und das Format am 18. Dezember 2025 als offenen Standard veröffentlicht. Die offizielle Client-Liste nennt inzwischen mehr als 40 Produkte — darunter Claude Code, GitHub Copilot, VS Code, OpenAI Codex und ChatGPT, Cursor, Gemini CLI, JetBrains Junie, OpenCode, Kiro, Goose und Pulumi Neo.

Der Hype lässt Skills wie einen Ersatz für alles Bisherige klingen: Prompts, MCP-Server, AGENTS.md, eigene Agenten. Das sind sie nicht. Skills lösen ein ganz bestimmtes Problem — Ablaufwissen, das ein Agent nur manchmal braucht — und das bemerkenswert gut. Gleichzeitig entsteht eine neue Software-Lieferkette, die mit den Rechten Ihres Agenten läuft. Dieser Leitfaden behandelt beide Hälften: wie Skills wirklich funktionieren, wo die großen Agenten nach ihnen suchen, worin sie sich von MCP und den anderen Anpassungsebenen unterscheiden und wie Sie Skills schreiben und installieren, ohne Ihren Laptop einem Fremden zu überlassen.

Was ein Agent Skill tatsächlich ist

Ein Agent Skill ist ein Ordner mit einer SKILL.md-Datei — YAML-Frontmatter mit Name und Beschreibung, gefolgt von Anweisungen in Markdown —, den ein KI-Agent beim Start entdeckt und erst lädt, wenn eine Aufgabe passt. Alles andere im Ordner ist optional:

reviewing-gcp-iam/
├── SKILL.md # Pflicht: Metadaten + Anweisungen
├── scripts/ # optional: Code, den der Agent ausführt
├── references/ # optional: Doku, die der Agent bei Bedarf liest
└── assets/ # optional: Vorlagen, Schemas, Bilder

Die Spezifikation ist kurz genug, um sie auswendig zu kennen. Das Frontmatter hat zwei Pflichtfelder und vier optionale:

Feld	Pflicht	Regeln
`name`	Ja	1–64 Zeichen, Kleinbuchstaben, Ziffern und Bindestriche; kein Bindestrich am Anfang, am Ende oder doppelt; muss dem Ordnernamen entsprechen
`description`	Ja	1–1.024 Zeichen; sagt, was der Skill tut und wann er gilt
`license`	Nein	Lizenzname oder eine beigelegte Lizenzdatei
`compatibility`	Nein	Bis zu 500 Zeichen Umgebungsanforderungen (Produkt, Systempakete, Netzwerk)
`metadata`	Nein	Freie String-zu-String-Map, etwa Autor und Version
`allowed-tools`	Nein	Leerzeichengetrennte vorab freigegebene Tools, z. B. `Bash(git:*) Read` — experimentell, Unterstützung variiert

Der Teil nach dem Frontmatter hat keine Pflichtstruktur. Die Spezifikation empfiehlt Schritt-für-Schritt-Anweisungen, Beispiele für Ein- und Ausgaben sowie Randfälle; die SKILL.md soll unter 500 Zeilen bleiben, Details wandern in referenzierte Dateien, höchstens eine Ebene tief. Der Referenz-Validator skills-ref validate ./my-skill prüft Frontmatter und Namensregeln.

Das ist das ganze Format. Spannend ist nicht, was ein Skill ist, sondern wie Agenten ihn laden.

Wie Skills geladen werden: Progressive Disclosure

Ein Skill ist um eine Einschränkung herum gebaut: Das Kontextfenster ist geteilt und teuer. Alles, was ein Agent während einer Aufgabe weiß — System-Prompt, Gesprächsverlauf, Tool-Definitionen, Dateiinhalte —, konkurriert um dieselben Token. Warum dieses Budget so wichtig ist, beschreibt Context Engineering 2026. Skills sind das bisher sauberste Werkzeug des Context Engineering, weil sie in drei Stufen laden:

Discovery — rund 100 Token pro Skill. Beim Start liest der Agent nur name und description aller installierten Skills und legt sie in seinen System-Prompt. Das genügt, um zu wissen, dass ein Skill existiert und wann er relevant sein könnte.
Aktivierung — empfohlen unter 5.000 Token. Passt Ihre Anfrage zu einer Beschreibung, liest der Agent den vollständigen Inhalt der SKILL.md in den Kontext. Bei Claude ist das wörtlich ein Shell-Aufruf: cat reviewing-gcp-iam/SKILL.md.
Ausführung — nur, was die Aufgabe berührt. Verweisen die Anweisungen auf references/finance.md, liest der Agent genau diese Datei und lässt references/sales.md auf der Platte. Steht dort, er solle scripts/check_policy.py ausführen, tut er das — und nur die Ausgabe des Skripts gelangt in den Kontext, nie der Quellcode.

Fünfzig installierte Skills kosten ungefähr so viel wie ein geladener — bis eine Aufgabe tatsächlich einen braucht.

Die Folgen sind größer, als es klingt. Bei einem klassischen System-Prompt oder einer CLAUDE.md kostet jede Zeile in jeder Runde Token, ob relevant oder nicht. Mit Skills kostet ein 20-seitiges Runbook ungefähr so viel wie ein Satz — bis zu dem Moment, in dem es gebraucht wird. Anthropics technischer Beitrag geht noch weiter: Für einen Agenten mit Dateisystem und Codeausführung ist die Menge an Kontext, die man in einen Skill packen kann, praktisch unbegrenzt, weil Dateien erst beim Lesen etwas kosten.

Zwei Details, die das Marketing meist weglässt:

Auch die Discovery-Liste hat ein Budget. Claude Code gibt der Skill-Liste etwa 1 % des Kontextfensters und begrenzt die Beschreibung pro Eintrag auf 1.536 Zeichen; läuft die Liste über, fallen zuerst die Beschreibungen der am seltensten genutzten Skills weg. Codex hält die anfängliche Liste unter 2 % des Kontextfensters (oder 8.000 Zeichen, wenn das Fenster unbekannt ist) und kürzt zuerst die Beschreibungen. Wer 200 Skills installiert, macht einige davon unsichtbar.
Ein geladener Skill bleibt geladen. In Claude Code landet die gerenderte SKILL.md einmal im Gespräch und bleibt dort über alle Runden. Nach einer automatischen Komprimierung hängt Claude Code nur die ersten 5.000 Token jedes aufgerufenen Skills wieder an, innerhalb eines gemeinsamen Budgets von 25.000 Token. Was überleben muss, gehört nach oben.

Skills vs. MCP vs. AGENTS.md vs. Subagenten

Hier entsteht die meiste Verwirrung, deshalb die Kurzfassung: MCP gibt einem Agenten Zugriff, ein Skill gibt ihm Know-how, AGENTS.md gibt ihm die Hausregeln, und Hooks geben Ihnen Garantien. Das sind Ebenen, keine Konkurrenten.

	Agent Skill	MCP-Server	`AGENTS.md` / Custom Instructions	Subagent	Hook / Deny-Regel
Was es ist	Ein Ordner: `SKILL.md` + optionale Skripte und Doku	Ein Prozess, der Tools, Ressourcen und Prompts über ein Protokoll bereitstellt	Eine Markdown-Datei, die in jede Sitzung geladen wird	Ein eigener Agent mit eigenem Kontextfenster	Deterministischer Code oder Policy auf Agenten-Ereignisse
Gibt dem Agenten	Einen Ablauf: wie wir X machen	Reichweite: die Fähigkeit, Y anzufassen	Fakten: wie dieses Repo funktioniert	Isolation: Z woanders erledigen und berichten	Grenzen: das passiert nie
Wann es Kontext kostet	~100 Token immer, Inhalt bei Treffer	Tool-Liste des verbundenen Servers; Claude Code lädt vollständige Schemas nur bei Bedarf (Tool Search), viele Clients laden sie vorab	Immer, vollständig	Nur das Endergebnis	Nie
Führt Code aus	Optionale gebündelte Skripte über die Shell des Agenten	Ja, im Server	Nein	Über eigene Tools	Ja, außerhalb des Modells
Portabel	Offener Standard, 40+ Clients	Offenes Protokoll	`AGENTS.md` ist ein offenes Format	Produktspezifisch	Produktspezifisch
Kann das Modell es ignorieren	Ja	Es kann ein Tool nicht aufrufen	Ja	—	Nein

Aus dieser Tabelle folgen drei praktische Regeln:

Muss der Agent ein System erreichen, das er heute nicht erreicht — eine Datenbank, Jira, eine Cloud-API —, ist das ein MCP-Server, kein Skill. Wie man einen baut und absichert, zeigt MCP-Server erklärt.
Fügen Sie immer wieder dieselbe Checkliste in den Chat ein , ist das ein Skill. Die Doku von Claude Code formuliert es fast genauso: Erstellen Sie einen Skill, wenn ein Abschnitt der CLAUDE.md zu einem Ablauf statt einem Fakt geworden ist.
Muss eine Regel jedes Mal gelten , reicht weder ein Skill noch AGENTS.md — das Modell kann Anweisungen überspringen. Die Troubleshooting-Doku von Claude Code rät selbst, solche Regeln in einen Hook zu verschieben. Für Tool-Berechtigungen heißt das Deny- und Ask-Regeln, wie in Claude-Code-Modi im Vergleich beschrieben.

Beides lässt sich kombinieren. Ein Skill kann vorgeben, welche MCP-Tools der Agent in welcher Reihenfolge und mit welchen Zwischenprüfungen aufruft. Anthropics Best-Practice-Leitfaden verlangt sogar, MCP-Tools im Skill voll qualifiziert zu referenzieren (BigQuery:bigquery_schema), damit der Agent den richtigen Server wählt. Diese Paarung — MCP für die Hände, ein Skill für das Playbook — ist der Kern des eigentlichen Nutzens.

Vier Ebenen, vier Fragen. Die meisten Produktions-Setups brauchen alle.

Wo die Agenten nach Skills suchen

Das Format ist portabel, die Ordner und Zusatzfunktionen sind es nicht. Stand Oktober 2026:

Agent	Projekt-Skills	Persönliche Skills	Explizit aufrufen	Automatische Nutzung abschalten
Claude Code	`.claude/skills/<name>/` (auch in Elternverzeichnissen bis zur Repo-Wurzel)	`~/.claude/skills/<name>/`	`/name`	`disable-model-invocation: true`
GitHub Copilot in VS Code	`.github/skills/`, `.claude/skills/`, `.agents/skills/`	`~/.copilot/skills/`, `~/.claude/skills/`, `~/.agents/skills/`	`/name`	`disable-model-invocation: true`
OpenAI Codex	`.agents/skills/` vom Arbeitsverzeichnis bis zur Repo-Wurzel	`~/.agents/skills/` (Admin: `/etc/codex/skills`)	`$name` oder `/skills`	`allow_implicit_invocation: false` in `agents/openai.yaml`

Quellen: Claude-Code-Skills, VS Code Agent Skills, Codex-Skills.

Die Lehre für Teams: .agents/skills/ ist der neutralste Ort , und VS Code liest zusätzlich .claude/skills/ — ein einziger eingecheckter Ordner kann also mehrere Werkzeuge bedienen. Mischt Ihr Team Claude Code und Codex, halten Sie die maßgebliche Kopie an einer Stelle und verlinken die andere per Symlink; Claude Code und Codex folgen beide verlinkten Skill-Ordnern.

Die Portabilitätsfalle: zusätzliches Frontmatter

Jeder Hersteller erweitert das Format, und die Erweiterungen wandern nicht mit. Claude Code ergänzt disable-model-invocation, user-invocable, context: fork (Skill in einem isolierten Subagenten ausführen), argument-hint, paths, model, hooks und mehr. VS Code unterstützt mehrere derselben Namen. Codex legt seine Extras in eine separate Datei agents/openai.yaml.

Die Falle: Ein Upload auf claude.ai oder über die Claude Skills API scheitert hart, sobald ein Feld außerhalb der sechs Standardfelder enthalten ist — mit einer Meldung wie Unexpected key(s) in SKILL.md frontmatter: argument-hint. Soll ein Skill überall laufen, beschränken Sie das Frontmatter auf name, description, license, compatibility, metadata und allowed-tools und legen werkzeugspezifisches Verhalten in den Text oder in eine Herstellerdatei daneben.

Selbst bauen: ein Skill für Least-Privilege-IAM-Reviews

Hier ein Skill, den ein Plattform-Team so direkt einsetzen könnte. Er prüft eine IAM-Policy in Google Cloud, markiert zu breite Bindings mit einem deterministischen Skript und schlägt Least-Privilege-Ersatz vor. Er wendet einige der Regeln an, die der kostenlose GCP IAM Policy Checker im Browser prüft — verpackt, damit ein Agent sie direkt im Repository nutzen kann.

.agents/skills/reviewing-gcp-iam/
├── SKILL.md
├── scripts/
│ └── check_policy.py
└── references/

    └── predefined-roles.md

Die SKILL.md mit ausschließlich portablen Feldern (die Anweisungen bleiben bewusst Englisch — so funktioniert der Skill in jedem Team):

---

name: reviewing-gcp-iam

description: Reviews Google Cloud IAM policies for over-broad access. Flags basic roles (owner, editor, viewer), public principals and service accounts with project-wide power, and proposes least-privilege predefined roles. Use when the user shares an IAM policy, asks who has access to a GCP project, or requests an IAM, permissions or least-privilege review.

license: MIT

metadata:

  author: platform-team

  version: "1.0"

---

# Reviewing GCP IAM policies

## Workflow

1. Get the policy as JSON. If the user has not provided one, ask for the project ID and run:

   `gcloud projects get-iam-policy PROJECT_ID --format=json > policy.json`

2. Run the checker and use only its output:

   `python3 scripts/check_policy.py policy.json`

3. For each finding, propose a predefined role. Look up candidates in

   [references/predefined-roles.md](references/predefined-roles.md) and read only the section for the affected service.

4. Report using the table below. Never apply changes yourself; output `gcloud` commands for a human to run.

## Report format
| Severity | Member | Current role | Proposed role | Why |
|---|---|---|---|---|

## Rules

- `allUsers` or `allAuthenticatedUsers` on any role is HIGH.

- A service account with a basic role is HIGH: any code running as it inherits project-wide power.

- Never propose removing the last owner of a project.

Und das Skript, das den Teil übernimmt, den ein Sprachmodell nicht improvisieren sollte:

#!/usr/bin/env python3
"""Flag risky bindings in a GCP IAM policy exported with --format=json."""

import json

import sys

BASIC = {"roles/owner", "roles/editor", "roles/viewer"}

PUBLIC = {"allUsers", "allAuthenticatedUsers"}

def check(policy: dict) -> list[tuple[str, str, str, str]]:

    findings = []

    for binding in policy.get("bindings", []):

        role = binding.get("role", "")

        for member in binding.get("members", []):

            if member in PUBLIC:

                findings.append(("HIGH", member, role, "public principal"))

            elif role in BASIC and member.startswith("serviceAccount:"):

                findings.append(("HIGH", member, role, "basic role on a service account"))

            elif role in BASIC:

                findings.append(("MEDIUM", member, role, "basic role; prefer a predefined role"))

    return findings

if __name__ == " __main__":

    if len(sys.argv) != 2:

        sys.exit("usage: check_policy.py policy.json")

    with open(sys.argv[1]) as f:

        results = check(json.load(f))

    for severity, member, role, why in results:

        print(f"{severity}\t{member}\t{role}\t{why}")

    print(f"{len(results)} finding(s)")

Warum er so gebaut ist:

Die Beschreibung enthält die Auslöser , die Menschen tatsächlich verwenden — IAM policy, who has access, permissions, least-privilege — und sagt erst, was der Skill tut, dann wann.
Das Skript ist die Quelle der Wahrheit für die Erkennung. Anthropics Leitfaden ist da deutlich: Für deterministische Operationen lieber ein vorgefertigtes Skript, weil generierter Code weniger zuverlässig ist und bei jedem Lauf Token kostet. Das Modell übernimmt, was es gut kann: Befunde erklären und Ersatzrollen auswählen.
Die Referenzdatei wird selektiv geladen. Ein Katalog vordefinierter Rollen ist lang; die Anweisungen sagen dem Agenten, nur den benötigten Abschnitt zu lesen.
Er hat keine Seiteneffekte. Er gibt gcloud-Befehle aus, statt sie auszuführen. Ein Skill, der Dinge verändert, sollte nur von Hand ausgelöst werden — in Claude Code und VS Code mit disable-model-invocation: true.

Testen wie Code

Ein Skill, der auslöst, ist noch kein Skill, der funktioniert. Anthropic empfiehlt, mindestens drei Evaluierungen anzulegen, bevor man umfangreiche Anweisungen schreibt, und die Ergebnisse dann in einer frischen Sitzung mit und ohne Skill zu vergleichen. In Claude Code automatisiert das skill-creator-Plugin diese Schleife: Es führt jeden Testfall in einem isolierten Subagenten aus, bewertet die Ausgabe, vergleicht Erfolgsquote, Token und Laufzeit mit und ohne Skill und erzeugt Prompts, bei denen der Skill auslösen bzw. nicht auslösen soll, um die Beschreibung zu schärfen. /skill-doctor zeigt, was jeder installierte Skill an Kontext kostet und welche Sie nie nutzen.

Beschreibungen, die wirklich auslösen

Feuert ein Skill nicht, liegt es fast immer an der Beschreibung. Der Agent vergleicht Ihre Anfrage mit einer Liste einzeiliger Beschreibungen — manchmal Dutzenden — und wählt eine aus. Diese Regeln funktionieren in Claude, Copilot und Codex:

Erst sagen, was er tut, dann wann. „Generates commit messages by analysing staged diffs. Use when the user asks for a commit message or wants to review staged changes.“
In der dritten Person schreiben. Die Beschreibung landet im System-Prompt; Anthropic warnt, dass „I can help you…“ oder „You can use this to…“ die Erkennung stört.
Hauptanwendungsfall und Auslöser nach vorne. Claude Code und Codex kürzen Beschreibungen, wenn die Liste voll ist. Was am Ende steht, fällt als Erstes weg.
Grenzen benennen. Der Codex-Leitfaden empfiehlt, klar zu sagen, wann der Skill nicht auslösen soll. Ein Skill, der bei allem feuert, ist genauso kaputt wie einer, der nie feuert.
Nach der Tätigkeit benennen. Anthropic schlägt Gerundien vor — processing-pdfs, reviewing-gcp-iam — und rät von helper, utils oder tools ab.

Schlecht: description: Helps with IAM. Gut: die aus dem Beispiel oben.

Was auf keiner Folie steht: Skills sind eine Lieferkette

Ein Skill ist keine Dokumentation. Er besteht aus Anweisungen, denen ein Agent folgt, und Code, den er ausführen darf — mit Ihren Rechten, auf Ihrem Rechner. Anthropics eigene Übersicht sagt, Skills nur aus vertrauenswürdigen Quellen zu nutzen und die Installation wie die einer Software zu behandeln. In Claude Code haben die Skripte eines Skills — anders als im abgeschotteten Container der Claude API — denselben Netzwerkzugriff wie jedes andere Programm auf Ihrem Rechner.

Das Ökosystem wurde bereits auf die Probe gestellt. Am 5. Februar 2026 veröffentlichte Snyk die ToxicSkills-Studie, einen Scan von 3.984 öffentlichen Skills aus ClawHub und skills.sh:

534 Skills (13,4 %) hatten mindestens ein kritisches Problem — Malware-Verteilung, Prompt Injection oder offengelegte Secrets.
1.467 Skills (36,8 %) hatten mindestens eine Sicherheitslücke beliebigen Schweregrads.
76 bestätigte Schadcode-Payloads für Zugangsdatendiebstahl, Hintertüren und Datenabfluss.
91 % der bestätigten bösartigen Skills kombinierten Prompt Injection mit Schadcode: Die Anweisungen reden dem Agenten seine Vorsicht aus, dann richtet das Skript den Schaden an.

Die Muster kennt jeder, der die frühen npm-Jahre erlebt hat: ein „Voraussetzungen“-Schritt, der ein passwortgeschütztes ZIP lädt, ein base64-kodiertes curl … | bash, ein Skill, der seine eigentlichen Anweisungen zur Laufzeit von einer URL holt, sodass die geprüfte Version nicht die ist, die läuft.

Alles, was ein Skill mitbringen kann, entspricht einer Kontrolle, die Sie aus dem Abhängigkeitsmanagement kennen.

Zwei Verhaltensweisen von Claude Code verdienen besondere Aufmerksamkeit, weil man sie leicht übersieht:

allowed-tools hängt nicht vom Workspace-Trust ab. Die Doku sagt es unmissverständlich: Die allowed-tools eines Projekt-Skills gelten bei jedem Aufruf, auch in einem -p-Lauf in einem Ordner, dem Sie nie vertraut haben. Ein geklontes Repository kann einen Skill mitbringen, der für seine Runde Bash(curl *) vorab freigibt. Lesen Sie das Frontmatter jedes Skills in einem Repository, bevor Sie einen Agenten darauf ansetzen.
!command`` läuft, bevor das Modell irgendetwas sieht. Die dynamische Kontextinjektion von Claude Code führt Shell-Befehle beim Rendern des Skills aus und fügt deren Ausgabe ein. Diese Befehle werden zwar gegen Ihre Berechtigungsregeln geprüft — eine Deny-Regel bricht den Aufruf ab —, bleiben aber Shell-Befehle aus der Feder des Skill-Autors. Organisationen können das für Nutzer-, Projekt- und Plugin-Skills mit "disableSkillShellExecution": true in den Managed Settings abschalten.

Eine Checkliste, die sich in der Praxis bewährt:

Nur aus Quellen installieren, die Sie benennen können. Eigene Repositorys, die Ihrer Organisation oder offizielle Sammlungen der Hersteller (anthropics/skills, openai/skills, github/awesome-copilot) — und trotzdem lesen.
Skills in Git versionieren und Diffs prüfen. Ein Skill ist eine Abhängigkeit. Behandeln Sie eine geänderte SKILL.md wie ein geändertes Lockfile.
Scannen. uvx mcp-scan@latest --skills prüft installierte Skills auf Prompt Injection, verdächtige Downloads und Secrets.
Anweisungen aus dem Netz ablehnen. Ein Skill, der Anweisungen oder Skripte zur Laufzeit von einer URL holt, lässt sich nicht prüfen. Einchecken oder ablehnen.
Secrets aus Skill-Ordnern heraushalten. Snyk fand fest eingebaute Secrets in 10,9 % der ClawHub-Skills.
Skills mit harten Grenzen absichern. Deny-Regeln, Ask-Regeln für Seiteneffekte und eine Sandbox auf Betriebssystemebene stoppen einen Skill, der das Modell zu etwas überredet hat. Das ist wieder die Lethal Trifecta: Private Daten, nicht vertrauenswürdige Inhalte und ein Abflusskanal in einem Agenten sind die Bedingung, die man brechen muss.

Wann Sie keinen Skill brauchen

Eine praktische Faustregel: Haben Sie einem Agenten denselben Ablauf dreimal erklärt, wird daraus ein Skill; darf eine Regel nie gebrochen werden, wird daraus ein Hook; muss der Agent ein neues System erreichen, wird daraus ein MCP-Server. Halten Sie auch die Zahl der Skills klein: Jeder zusätzliche Skill ist eine weitere Beschreibung, die um die Aufmerksamkeit des Agenten konkurriert.

Skills sind seltener das richtige Werkzeug, als der Hype vermuten lässt:

Einmalige Aufgaben. Schreiben Sie einfach den Prompt.
Fakten, die der Agent in jeder Runde braucht — Build-Befehle, Code-Stil, Verzeichnisstruktur. Das gehört in AGENTS.md oder Ihre Custom-Instructions-Datei.
Zugriff auf Systeme. Authentifizierung, Live-Daten und entfernte Aktionen gehören in einen MCP-Server, idealerweise hinter einem Gateway mit Berechtigungen pro Nutzer, wie in benutzerbezogener Zugriffskontrolle für MCP.
Garantien. „Nie auf main pushen“, „nie .env lesen“ — dafür gibt es Deny-Regeln und Hooks.
Kontext, den der Skill zur Laufzeit aus dem Internet holen würde. Das ist kein Skill, sondern ein entfernter Prompt mit Zusatzschritten.

Fazit

Agent Skills haben sich durchgesetzt, weil sie im besten Sinne langweilig sind: ein Ordner, eine Markdown-Datei und zwei Pflichtfelder — für Menschen lesbar, in Git vergleichbar und über mehr als 40 Agenten hinweg portabel. Der clevere Teil ist Progressive Disclosure: rund 100 Token pro Skill bis zu dem Moment, in dem eine Aufgabe ihn braucht. Damit lässt sich einem Agenten endlich tiefes, spezifisches Know-how mitgeben, ohne jedes Gespräch darin zu ertränken.

Sie ersetzen weder MCP noch AGENTS.md noch Berechtigungsregeln; sie sind die fehlende Ebene dazwischen. Schreiben Sie Beschreibungen, die sagen was und wann, verlagern Sie deterministische Arbeit in Skripte, halten Sie das Frontmatter portabel — und prüfen Sie jeden Skill, den Sie installieren, mit demselben Misstrauen wie ein Paket, das mit Ihren Zugangsdaten läuft. Denn genau das ist er.

Ursprünglich veröffentlicht auf alekseialeinikov.com

WebMCP Explained: How Chrome Turns Your Website Into an MCP Server for AI Agents

Aleksei Aleinikov — Wed, 30 Sep 2026 10:00:00 +0000

AI agents use most websites the way a person would use them blindfolded: take a screenshot, guess which box is the search field, click, type, wait, take another screenshot and hope the layout didn’t change. It works often enough to demo and fails often enough to be annoying.

WebMCP flips that around. Instead of the agent reverse-engineering your interface, your page tells the agent what it can do — as tools with names, descriptions and JSON Schemas, the same idea as an MCP server, but running inside the browser tab. Chrome shipped it as an origin trial in Chrome 149, and on September 27, 2026 I put five WebMCP tools live on the tools section of this site.

This guide explains how WebMCP works, what Chrome actually does between your page and the agent, how it differs from MCP, and what I ran into shipping it to production.

WebMCP at a Glance


What it is	A proposed web standard for exposing a page’s JavaScript functions and HTML forms as tools for AI agents
Who is behind it	W3C Web Machine Learning Community Group; the explainer was first published on August 13, 2025 by engineers from Microsoft and Google
Core API	`document.modelContext.registerTool()`, `getTools()`, `executeTool()`, plus a `toolchange` event
Declarative variant	`toolname` and `tooldescription` attributes on a `<form>`
Status in Chrome	Origin trial from Chrome 149; local testing via `chrome://flags/#enable-webmcp-testing`
Other implementations	Edge origin trial from Edge 150, ChatGPT Desktop, experimental in Brave Leo; Firefox and Safari have open standards-position requests
Security gates	Origin-isolated documents only; `tools` Permissions Policy, default `self`

Why Websites Need WebMCP

Today an agent that wants to use a website has two options. If the service publishes an MCP server or an API, the agent talks to the backend and skips the site entirely. If it doesn’t, the agent falls back to actuation : it simulates mouse clicks and keyboard input from screenshots, the DOM and the accessibility tree.

Actuation is the fragile path. Every step is a chance to misread a label, click the wrong element or act before the page finished rendering, and a redesign can break an agent that worked yesterday. The WebMCP explainer describes the goal plainly: let agents interact “through well-defined client-side tools instead of through brittle UI actuation”.

Here is the same question asked of my Cron Translator both ways:

Same page, same question. On the left the agent guesses; on the right the page answers.

The right-hand side is not a mock-up. That call and that answer come from the tool running on this site.

WebMCP doesn’t replace the UI or the backend integration. The explainer lists replacing human interfaces and replacing MCP as explicit non-goals. It adds a third path that keeps the user, the page and the agent in the same place: the agent works through the page, and the page updates visibly as it does.

How WebMCP Works

A WebMCP tool has four parts, and if you’ve written an MCP server they will look familiar:


const controller = new AbortController();

await document.modelContext.registerTool(

  {

    name: 'explain_cron',

    description: 'Explain a cron expression in plain language and list its next runs in a time zone.',

    inputSchema: {

      type: 'object',

      properties: {

        expression: { type: 'string', description: 'Cron expression, e.g. "30 2 * * 1-5".' },

        timezone: { type: 'string', description: 'IANA time zone, e.g. Europe/Berlin. Default UTC.' },

      },

      required: ['expression'],

    },

    annotations: { readOnlyHint: true },

    execute: async ({ expression, timezone }) => explainCron(expression, timezone),

  },

  { signal: controller.signal },

);

// Later: controller.abort() unregisters the tool.

name and description are what the model reads to decide whether the tool fits the user’s request.
inputSchema is a JSON Schema for the arguments. The agent fills it in; you don’t parse free text.
execute() is ordinary page JavaScript. It can reuse the functions your UI already calls, update the DOM and return text or JSON.
annotations are optional hints about side effects and trust, covered below.

For plain forms there is a declarative API that needs no JavaScript at all:


<form toolname="createSupportRequest"

      tooldescription="Submits a request for customer support."

      action="/support">

  <label for="email">Email</label>

  <input id="email" name="email" type="email" required>

  <button type="submit">Send</button>

</form>

Chrome turns the form fields into a JSON Schema, using each field’s <label> (or a toolparamdescription attribute) as the parameter description. When the agent calls the tool, the browser focuses the form and fills it in while the user watches.

How Chrome Implements WebMCP

This is the interesting part. WebMCP is not a library that the agent loads into your page. The browser owns the registry and sits in the middle of every call.

Six steps, and Chrome is in the middle of every one of them.

1. The gates come first

Before a single tool registers, three checks apply:

The feature must be on. Either your origin carries a valid origin trial token, or the user enabled the testing flag.
The document must be origin-isolated. If a page opts into document.domain — for example with Origin-Agent-Cluster: ?0 — Chrome disables the WebMCP APIs, so a tool’s origin can’t change during its lifetime.
The tools Permissions Policy must allow it. It defaults to self: top-level documents and same-origin iframes can register tools, cross-origin iframes can’t unless the embedder adds allow="tools". When the policy blocks it, registerTool() rejects with a NotAllowedError.

2. Registration builds a per-document registry

registerTool() hands Chrome the definition. Chrome stores it with the page’s origin and window and fires a toolchange event on document.modelContext. getTools() returns the list alphabetically and, by default, only includes tools from same-origin documents in the frame tree. A tool becomes visible to another origin only if you list it in exposedTo and the caller asks for it with fromOrigins.

3. The agent discovers tools while the user is on the page

The agent reads each tool’s name, description and schema into the model’s context. Discovery is tied to the visit: as Chrome’s documentation puts it, clients “must visit a site directly to know if it has callable tools”. There is no crawler-readable manifest yet.

4. Chrome mediates the call

When the model picks a tool, the agent calls executeTool(tool, args). Chrome checks that exposure and origins agree, then runs your execute() in the tool owner’s own context. That means it runs with the user’s logged-in session, cookies and current page state — exactly what a backend integration would have to rebuild on a server.

execute() receives an AbortSignal as options.signal. If the user hits stop in the agent’s UI, the signal fires and you can cancel a fetch() or any long task. If a tool triggers a navigation, executeTool() resolves with null.

5. Unregistering is just an abort

Tools are unregistered by aborting the signal you passed to registerTool(). Since Chrome 153, unregistering no longer cancels an execution that is already running, which matters in component frameworks that mount and unmount often. Chrome’s guidance is to register tools that fit the current page state and remove them when they stop applying, because every tool costs context tokens and increases the chance the model picks the wrong one.

6. Annotations tell the agent how careful to be

Annotation	Meaning	What the agent can do with it
`readOnlyHint`	The tool only reads, no side effects	Call it without asking the user
`consequentialHint`	Significant or irreversible action, such as a booking or payment	Ask the user to confirm first
`untrustedContentHint`	Output contains user-generated or third-party text	Treat the payload as data, not instructions
`debugging` (Chrome 156+)	Tool is meant for developer tooling	Hide it from end-user agents

7. The declarative API gets real browser hooks

Declarative forms get platform features no library could add. SubmitEvent.agentInvoked tells your submit handler whether a human or an agent submitted the form, and respondWith() lets you return a result to the model. The toolactivated and toolcancel events fire when an agent fills or abandons a form. The CSS pseudo-classes :tool-form-active and :tool-submit-active let you style a form while an agent is working on it, and toolautosubmit lets the agent submit without the user clicking the button.

WebMCP vs MCP

The most common question about WebMCP is whether it replaces MCP. It doesn’t, and Chrome’s own guide opens by calling that a misunderstanding.

Both expose tools. MCP lives on your server; WebMCP lives in your page.

	MCP	WebMCP
Where the tool runs	A server or local process	The page’s JavaScript
Lifecycle	Persistent	Ephemeral, bound to the tab
Reach	Desktop, mobile, cloud, IDEs	Browser agents only
Auth and state	Rebuilt on the server	The user’s live session
Transport	JSON-RPC over stdio or HTTP	Browser-mediated calls
Resources and prompts	Yes	No — tools only

The WebMCP explainer is explicit about why it didn’t simply put MCP in the browser: MCP “lacks native web concepts like origins, standard browser permissions, DOM integration, and tab-level lifecycle management”, and tying a web API to an evolving backend protocol would hurt backward compatibility. So WebMCP shares MCP’s vocabulary — tools, schemas, parameters — but is a web-native API.

In practice you want both. If agents should reach your service from Claude Desktop, an IDE or a cloud workflow, that is an MCP server, and controlling which user gets which tool belongs in a gateway in front of it. If the user is on your site and wants an agent to help with what’s on screen, that is WebMCP.

My Implementation: Five WebMCP Tools in Production

Every page under /en/tools on this site registers five read-only tools when the browser supports WebMCP:

Tool	What it does	Live page
`check_gcp_iam_policy`	Audits a Google Cloud IAM policy for least-privilege problems	IAM Checker
`recommend_gcp_compute`	Picks Cloud Run, GKE, Compute Engine and so on for a workload	Compute Selector
`recommend_gcp_database`	Picks Cloud SQL, AlloyDB, Spanner, Firestore and so on	Database Selector
`explain_cron`	Explains a cron expression and lists the next runs in a time zone	Cron Translator
`convert_cron`	Translates cron syntax between nine platforms	Cron Translator

All five run the same engines the UI uses. Nothing is sent to a server — the IAM policy an agent passes in is analysed in the browser, just like one a person pastes in.

Loading: zero cost for everyone else

Most visitors’ browsers don’t have WebMCP, so the tool module must never load for them. The site uses Astro’s client-side router, which means the loader also has to register tools when you navigate into /tools and remove them when you leave:


let controller = null;

let registeredFor = '';

async function syncWebMcp() {

  const onTools = /^\/(en|de)\/tools(\/|$)/.test(location.pathname);

  const key = onTools ? document.documentElement.lang : '';

  if (key === registeredFor) return;

  controller?.abort(); // leaving /tools or switching language

  controller = null;

  registeredFor = '';

  if (!onTools || !('modelContext' in document)) return;

  const current = new AbortController();

  controller = current;

  registeredFor = key;

  const { registerWebMcpTools } = await import('./webmcp-tools.js');

  await registerWebMcpTools(current.signal);

}

document.addEventListener('astro:page-load', syncWebMcp);

Three details matter here. The feature check ('modelContext' in document) runs before the dynamic import(), so unsupported browsers download nothing. The AbortController unregisters every tool in one call when the route changes. And the language is part of the key, so switching from /en/tools to /de/tools re-registers the tools with German output.

Schemas come from the UI’s own content

The two selector tools take the same questions the interactive quiz asks. Instead of writing the schema by hand, it is generated from the question list the UI renders:


export function selectorSchema(kind) {

  const properties = {};

  for (const q of SELECTORS[kind].questions.en) {

    properties[q.id] = {

      type: 'string',

      enum: q.options.map((o) => o.value),

      description: `${q.label} ${q.options.map((o) => `${o.value} = ${o.label}`).join('; ')}`,

    };

  }

  return { type: 'object', properties };

}

Add a question to the quiz and the agent sees it on the next deploy. The schema can’t drift from the UI because there is only one source.

Output: under 1,500 characters, with a way back

Chrome’s security guide recommends about 1.5K characters per tool output, 500 per tool description and 150 per parameter description. An IAM policy with forty findings would blow that easily, so every tool builds its answer line by line and stops when the next line would cross the budget:


export const MAX_OUTPUT = 1500;

function fitLines(head, lines, footer) {

  let out = head;

  for (let i = 0; i < lines.length; i += 1) {

    const rest = lines.length - i - 1;

    const tail = rest ? `\n… and ${rest} more` : '';

    if (`${out}\n${lines[i]}${tail}\n${footer}`.length > MAX_OUTPUT) {

      return `${out}\n… and ${lines.length - i} more\n${footer}`;

    }

    out += `\n${lines[i]}`;

  }

  return `${out}\n${footer}`;

}

The footer is always a link to the full interactive report, so the agent can hand the user the complete result instead of a truncated one.

Errors the agent can fix itself

The WebMCP best practices say to validate “strictly in code, loosely in schema” and return errors the model can act on. A bad value doesn’t throw; it tells the agent exactly what to send instead:

Invalid value "h100" for hardware. Use one of: none, gpu, tpu.

The one tool with `untrustedContentHint: true`

Four tools return text that I wrote. check_gcp_iam_policy is different: its findings quote role names and member strings from the policy the user passed in. A policy is JSON anyone can edit, so a member string could contain an instruction aimed at the model. That tool is the only one marked untrustedContentHint: true; all five carry readOnlyHint: true and consequentialHint: false.

The origin trial token expires

The token is a meta tag in the page head, bound to https://www.alekseialeinikov.com:


<meta http-equiv="origin-trial" content="…token…">

Mine expires on November 17, 2026, and there is no API to renew it. A weekly CI job checks the expiry date and fails 21 days before it, so GitHub sends me an email in time. An expired token breaks nothing — WebMCP simply switches off — but the tools would quietly disappear.

Measuring agent calls

Every execute() sends an analytics event with tool_action: 'agent_call', separate from the event a person triggers in the UI. Three days after launch the count is zero. That isn’t a surprise: WebMCP is still an origin trial, and an agent has to be connected to the tab before anything calls a tool. The point of shipping now is to be ready and measurable when that changes.

Try It Yourself

Open chrome://flags/#enable-webmcp-testing in Chrome, enable it and relaunch.
Install the Model Context Tool Inspector extension.
Open /en/tools/cron-translator and open the extension. It lists the five tools with their schemas.
Call explain_cron with {"expression": "30 2 * * 1-5", "timezone": "Europe/Berlin"}, or type a question in plain English and let the extension’s agent pick the tool.

The extension also shows exactly what your own tools return, which is the fastest way to check that your descriptions and outputs read well to a model.

WebMCP Security

WebMCP narrows who can see your tools, but it doesn’t make an agent safe. Chrome’s security guide is direct about it: models are probabilistic, repeatable prompt injection attacks against agents exist, and “it’s impossible to guarantee safety inside of a large language model”.

What you control as the site owner:

Exposure. By default tools are visible only to your page, same-origin frames and built-in browser agents. Add origins to exposedTo only if you’d share the same data with that site directly.
Annotations. Set consequentialHint: true on anything that spends money, sends messages or deletes data, and untrustedContentHint: true on anything that returns text you didn’t write.
Validation. Treat every execute() call like an API request from an untrusted client. The schema is a hint to the model, not a guarantee.
Extensions. A Chrome extension with host permissions can call your WebMCP tools — but it could already run arbitrary JavaScript on your page without them. WebMCP doesn’t open a new hole there; it makes the intended path cleaner.

If you’re thinking about agents acting on real systems, what happened when autonomous agents went rogue on a government website is a good reminder of why the guardrails belong in your code.

Should You Add WebMCP Now?

Add it now if:

your site has tasks , not just content — search, filters, configurators, forms, calculators, dashboards;
the logic already runs in the browser, so tools are mostly wrappers around existing functions;
you can keep the first tools read-only and add write actions later with consequentialHint.

Wait if:

your pages are mostly articles — agents read those fine today, and an llms.txt file helps more;
your key actions need server-side state the page doesn’t have — that’s an MCP server’s job;
you can’t commit to renewing an origin trial token every few months.

Because the whole thing sits behind a feature check, the cost to users without WebMCP is zero. The real cost is designing good tools: short descriptions, clear schemas and outputs a model can use.

The Bottom Line

WebMCP turns a website from something an agent has to decipher into something it can call. The page declares its tools, Chrome keeps the registry, checks the gates and runs your execute() in the user’s own session, and the agent gets a typed, short answer instead of a screenshot to interpret.

It is early: an origin trial in Chrome and Edge, one desktop assistant, and zero agent calls in my own analytics so far. But the API is small, the cost for everyone else is zero, and the tools on this site’s tools section took less code than the UI around them. If your site has tasks and the logic already runs in the browser, it’s worth shipping one read-only tool now and seeing what calls it.

Originally published at alekseialeinikov.com

WebMCP erklärt: Wie Chrome deine Website zum MCP-Server für KI-Agenten macht

Aleksei Aleinikov — Wed, 30 Sep 2026 10:00:00 +0000

KI-Agenten bedienen die meisten Websites wie ein Mensch mit verbundenen Augen: Screenshot machen, raten, welches Feld die Suche ist, klicken, tippen, warten, nächster Screenshot – und hoffen, dass sich das Layout nicht geändert hat. Das reicht für eine Demo und scheitert oft genug, um zu nerven.

WebMCP dreht das um. Statt dass der Agent deine Oberfläche zurückentwickelt, sagt die Seite dem Agenten, was sie kann – als Tools mit Namen, Beschreibung und JSON Schema. Die Idee ist dieselbe wie bei einem MCP-Server, nur läuft alles im Browser-Tab. Chrome liefert WebMCP seit Chrome 149 als Origin Trial aus, und am 27. September 2026 habe ich fünf WebMCP-Tools im Tools-Bereich dieser Website live geschaltet.

Dieser Guide erklärt, wie WebMCP funktioniert, was Chrome zwischen deiner Seite und dem Agenten tatsächlich macht, worin es sich von MCP unterscheidet und worauf ich im Produktivbetrieb gestoßen bin.

WebMCP auf einen Blick


Was es ist	Ein vorgeschlagener Webstandard, der JavaScript-Funktionen und HTML-Formulare einer Seite als Tools für KI-Agenten bereitstellt
Wer dahintersteht	W3C Web Machine Learning Community Group; das Explainer-Dokument erschien erstmals am 13. August 2025, verfasst von Entwicklern bei Microsoft und Google
Kern-API	`document.modelContext.registerTool()`, `getTools()`, `executeTool()` und das Event `toolchange`
Deklarative Variante	Die Attribute `toolname` und `tooldescription` an einem `<form>`
Status in Chrome	Origin Trial ab Chrome 149; lokal testen über `chrome://flags/#enable-webmcp-testing`
Weitere Implementierungen	Edge Origin Trial ab Edge 150, ChatGPT Desktop, experimentell in Brave Leo; Firefox und Safari haben offene Anfragen zur Standards-Position
Sicherheitsschranken	Nur origin-isolierte Dokumente; Permissions Policy `tools`, Standard `self`

Warum Websites WebMCP brauchen

Ein Agent, der heute eine Website nutzen will, hat zwei Möglichkeiten. Bietet der Dienst einen MCP-Server oder eine API an, spricht der Agent direkt mit dem Backend und lässt die Website links liegen. Wenn nicht, greift er auf Aktuierung zurück: Er simuliert Mausklicks und Tastatureingaben anhand von Screenshots, DOM und Accessibility Tree.

Aktuierung ist der fragile Weg. Jeder Schritt ist eine Chance, ein Label falsch zu lesen, das falsche Element zu treffen oder zu handeln, bevor die Seite fertig gerendert ist – und ein Redesign kann einen Agenten zerlegen, der gestern noch funktioniert hat. Das WebMCP-Explainer-Dokument formuliert das Ziel klar: Agenten sollen über „klar definierte clientseitige Tools statt über brüchige UI-Aktuierung“ mit Websites arbeiten.

Hier dieselbe Frage an meinen Cron Translator, einmal auf jede Art:

Dieselbe Seite, dieselbe Frage. Links rät der Agent, rechts antwortet die Seite.

Die rechte Seite ist kein Mock-up. Aufruf und Antwort stammen von dem Tool, das auf dieser Website läuft.

WebMCP ersetzt weder die Oberfläche noch die Backend-Integration. Beides steht im Explainer ausdrücklich unter den Nicht-Zielen. Es kommt ein dritter Weg dazu, auf dem Nutzer, Seite und Agent am selben Ort bleiben: Der Agent arbeitet über die Seite, und die Seite aktualisiert sich dabei sichtbar.

So funktioniert WebMCP

Ein WebMCP-Tool besteht aus vier Teilen, und wer schon einen MCP-Server gebaut hat, erkennt sie sofort:


const controller = new AbortController();

await document.modelContext.registerTool(

  {

    name: 'explain_cron',

    description: 'Explain a cron expression in plain language and list its next runs in a time zone.',

    inputSchema: {

      type: 'object',

      properties: {

        expression: { type: 'string', description: 'Cron expression, e.g. "30 2 * * 1-5".' },

        timezone: { type: 'string', description: 'IANA time zone, e.g. Europe/Berlin. Default UTC.' },

      },

      required: ['expression'],

    },

    annotations: { readOnlyHint: true },

    execute: async ({ expression, timezone }) => explainCron(expression, timezone),

  },

  { signal: controller.signal },

);

// Später: controller.abort() meldet das Tool wieder ab.

name und description liest das Modell, um zu entscheiden, ob das Tool zur Anfrage des Nutzers passt.
inputSchema ist ein JSON Schema für die Argumente. Der Agent füllt es aus; du musst keinen Freitext parsen.
execute() ist ganz normales JavaScript der Seite. Es kann dieselben Funktionen nutzen wie deine Oberfläche, das DOM aktualisieren und Text oder JSON zurückgeben.
annotations sind optionale Hinweise zu Seiteneffekten und Vertrauen – dazu gleich mehr.

Für einfache Formulare gibt es eine deklarative API , die ganz ohne JavaScript auskommt:


<form toolname="createSupportRequest"

      tooldescription="Submits a request for customer support."

      action="/support">

  <label for="email">Email</label>

  <input id="email" name="email" type="email" required>

  <button type="submit">Send</button>

</form>

Chrome macht aus den Formularfeldern ein JSON Schema und nutzt das <label> jedes Feldes (oder ein Attribut toolparamdescription) als Parameterbeschreibung. Ruft der Agent das Tool auf, fokussiert der Browser das Formular und füllt es aus, während der Nutzer zusieht.

Wie Chrome WebMCP umsetzt

Jetzt wird es spannend. WebMCP ist keine Bibliothek, die der Agent in deine Seite lädt. Der Browser besitzt die Registry und steht bei jedem Aufruf in der Mitte.

Sechs Schritte – und Chrome steckt in jedem davon.

1. Zuerst kommen die Schranken

Bevor sich überhaupt ein Tool registriert, gelten drei Prüfungen:

Das Feature muss aktiv sein. Entweder trägt deine Origin ein gültiges Origin-Trial-Token, oder der Nutzer hat das Test-Flag eingeschaltet.
Das Dokument muss origin-isoliert sein. Nutzt eine Seite document.domain – etwa über Origin-Agent-Cluster: ?0 –, schaltet Chrome die WebMCP-APIs ab, damit sich die Origin eines Tools während seiner Lebensdauer nicht ändern kann.
Die Permissions Policy tools muss es erlauben. Standard ist self: Top-Level-Dokumente und iFrames derselben Origin dürfen Tools registrieren, fremde iFrames nur, wenn die einbettende Seite allow="tools" setzt. Blockiert die Policy, lehnt registerTool() mit einem NotAllowedError ab.

2. Die Registrierung baut eine Registry pro Dokument

registerTool() übergibt Chrome die Definition. Chrome speichert sie zusammen mit Origin und Fenster der Seite und feuert ein toolchange-Event auf document.modelContext. getTools() liefert die Liste alphabetisch sortiert und enthält standardmäßig nur Tools aus Dokumenten derselben Origin im Frame-Baum. Für eine andere Origin wird ein Tool nur sichtbar, wenn du sie in exposedTo einträgst und der Aufrufer sie mit fromOrigins anfragt.

3. Der Agent findet Tools, während der Nutzer auf der Seite ist

Der Agent lädt Name, Beschreibung und Schema jedes Tools in den Kontext des Modells. Die Discovery hängt am Besuch: Laut Chrome-Doku müssen Clients eine Website direkt besuchen, um zu wissen, ob sie aufrufbare Tools hat. Ein Manifest, das Crawler lesen könnten, gibt es noch nicht.

4. Chrome vermittelt den Aufruf

Wählt das Modell ein Tool, ruft der Agent executeTool(tool, args) auf. Chrome prüft, ob Freigabe und Origins zusammenpassen, und führt dann dein execute() im Kontext der Seite aus, der das Tool gehört. Es läuft also mit der eingeloggten Session, den Cookies und dem aktuellen Seitenzustand des Nutzers – genau das, was eine Backend-Integration auf einem Server nachbauen müsste.

execute() bekommt ein AbortSignal als options.signal. Drückt der Nutzer in der Agent-Oberfläche auf Stopp, feuert das Signal, und du kannst einen fetch() oder eine lange Aufgabe abbrechen. Löst ein Tool eine Navigation aus, liefert executeTool() den Wert null.

5. Abmelden ist einfach ein Abort

Tools meldet man ab, indem man das Signal abbricht, das man registerTool() übergeben hat. Seit Chrome 153 bricht das Abmelden eine bereits laufende Ausführung nicht mehr ab – wichtig in Komponenten-Frameworks, die oft mounten und unmounten. Google rät, nur Tools zu registrieren, die zum aktuellen Seitenzustand passen, und sie wieder zu entfernen, wenn sie nicht mehr gelten: Jedes Tool kostet Kontext-Tokens und erhöht die Chance, dass das Modell das falsche wählt.

6. Annotationen sagen dem Agenten, wie vorsichtig er sein muss

Annotation	Bedeutung	Was der Agent damit tun kann
`readOnlyHint`	Das Tool liest nur, keine Seiteneffekte	Ohne Rückfrage aufrufen
`consequentialHint`	Folgenreiche oder unumkehrbare Aktion, etwa Buchung oder Zahlung	Vorher um Bestätigung bitten
`untrustedContentHint`	Die Ausgabe enthält Text von Nutzern oder Dritten	Den Inhalt als Daten behandeln, nicht als Anweisung
`debugging` (ab Chrome 156)	Das Tool ist für Entwicklerwerkzeuge gedacht	Vor Endnutzer-Agenten verbergen

7. Die deklarative API bekommt echte Browser-Hooks

Deklarative Formulare bekommen Plattform-Features, die keine Bibliothek nachrüsten könnte. SubmitEvent.agentInvoked verrät deinem Submit-Handler, ob ein Mensch oder ein Agent das Formular abgeschickt hat, und mit respondWith() gibst du dem Modell ein Ergebnis zurück. Die Events toolactivated und toolcancel feuern, wenn ein Agent ein Formular ausfüllt oder abbricht. Mit den CSS-Pseudoklassen :tool-form-active und :tool-submit-active gestaltest du ein Formular, während ein Agent daran arbeitet, und toolautosubmit lässt den Agenten abschicken, ohne dass der Nutzer auf den Button klickt.

WebMCP vs. MCP

Die häufigste Frage zu WebMCP lautet, ob es MCP ersetzt. Tut es nicht – und Googles eigener Guide nennt das gleich zu Beginn ein Missverständnis.

Beide stellen Tools bereit. MCP lebt auf deinem Server, WebMCP in deiner Seite.

	MCP	WebMCP
Wo das Tool läuft	Auf einem Server oder in einem lokalen Prozess	Im JavaScript der Seite
Lebensdauer	Dauerhaft	Flüchtig, an den Tab gebunden
Reichweite	Desktop, Mobil, Cloud, IDEs	Nur Browser-Agenten
Auth und Zustand	Auf dem Server nachgebaut	Die echte Session des Nutzers
Transport	JSON-RPC über stdio oder HTTP	Vom Browser vermittelte Aufrufe
Resources und Prompts	Ja	Nein – nur Tools

Das Explainer-Dokument begründet klar, warum man nicht einfach MCP in den Browser gepackt hat: MCP fehlen native Web-Konzepte wie Origins, Browser-Berechtigungen, DOM-Integration und ein an den Tab gebundener Lebenszyklus, und eine Web-API an ein sich weiterentwickelndes Backend-Protokoll zu koppeln, würde die Abwärtskompatibilität gefährden. WebMCP teilt also das Vokabular von MCP – Tools, Schemas, Parameter –, ist aber eine eigenständige Web-API.

In der Praxis braucht man beides. Sollen Agenten deinen Dienst aus Claude Desktop, einer IDE oder einem Cloud-Workflow erreichen, ist das ein MCP-Server, und die Frage, welcher Nutzer welches Tool bekommt, gehört in ein Gateway davor. Ist der Nutzer auf deiner Website und soll ein Agent bei dem helfen, was auf dem Bildschirm ist, ist das WebMCP.

Meine Implementierung: fünf WebMCP-Tools im Produktivbetrieb

Jede Seite unter /de/tools auf dieser Website registriert fünf reine Lese-Tools, sobald der Browser WebMCP unterstützt:

Tool	Was es macht	Live-Seite
`check_gcp_iam_policy`	Prüft eine Google-Cloud-IAM-Policy auf Least-Privilege-Probleme	IAM Checker
`recommend_gcp_compute`	Wählt Cloud Run, GKE, Compute Engine usw. für einen Workload	Compute Selector
`recommend_gcp_database`	Wählt Cloud SQL, AlloyDB, Spanner, Firestore usw.	Database Selector
`explain_cron`	Erklärt einen Cron-Ausdruck und listet die nächsten Läufe in einer Zeitzone	Cron Translator
`convert_cron`	Übersetzt Cron-Syntax zwischen neun Plattformen	Cron Translator

Alle fünf nutzen dieselben Engines wie die Oberfläche. Nichts geht an einen Server – eine IAM-Policy, die ein Agent übergibt, wird im Browser analysiert, genau wie eine, die ein Mensch einfügt.

Laden: null Kosten für alle anderen

Die Browser der meisten Besucher haben kein WebMCP, also darf das Tool-Modul für sie nie geladen werden. Die Website nutzt den clientseitigen Router von Astro, deshalb muss der Loader Tools registrieren, wenn man nach /tools navigiert, und sie wieder entfernen, wenn man die Seite verlässt:


let controller = null;

let registeredFor = '';

async function syncWebMcp() {

  const onTools = /^\/(en|de)\/tools(\/|$)/.test(location.pathname);

  const key = onTools ? document.documentElement.lang : '';

  if (key === registeredFor) return;

  controller?.abort(); // /tools verlassen oder Sprache gewechselt

  controller = null;

  registeredFor = '';

  if (!onTools || !('modelContext' in document)) return;

  const current = new AbortController();

  controller = current;

  registeredFor = key;

  const { registerWebMcpTools } = await import('./webmcp-tools.js');

  await registerWebMcpTools(current.signal);

}

document.addEventListener('astro:page-load', syncWebMcp);

Drei Details sind wichtig. Die Feature-Prüfung ('modelContext' in document) läuft vor dem dynamischen import(), Browser ohne Unterstützung laden also nichts herunter. Der AbortController meldet bei einem Routenwechsel alle Tools mit einem Aufruf ab. Und die Sprache ist Teil des Schlüssels: Wechselt man von /en/tools zu /de/tools, werden die Tools mit deutschen Ausgaben neu registriert.

Die Schemas kommen aus den Inhalten der Oberfläche

Die beiden Selector-Tools nehmen dieselben Fragen entgegen, die das interaktive Quiz stellt. Statt das Schema von Hand zu schreiben, wird es aus der Fragenliste erzeugt, die auch die Oberfläche rendert:


export function selectorSchema(kind) {

  const properties = {};

  for (const q of SELECTORS[kind].questions.en) {

    properties[q.id] = {

      type: 'string',

      enum: q.options.map((o) => o.value),

      description: `${q.label} ${q.options.map((o) => `${o.value} = ${o.label}`).join('; ')}`,

    };

  }

  return { type: 'object', properties };

}

Kommt eine Frage ins Quiz, sieht der Agent sie beim nächsten Deploy. Schema und Oberfläche können nicht auseinanderlaufen, weil es nur eine Quelle gibt.

Ausgabe: unter 1.500 Zeichen, mit Weg zurück

Googles Sicherheits-Guide empfiehlt etwa 1,5K Zeichen pro Tool-Ausgabe, 500 pro Tool-Beschreibung und 150 pro Parameterbeschreibung. Eine IAM-Policy mit vierzig Befunden würde das locker sprengen. Deshalb baut jedes Tool seine Antwort Zeile für Zeile auf und hört auf, sobald die nächste Zeile das Budget überschreiten würde:


export const MAX_OUTPUT = 1500;

function fitLines(head, lines, footer) {

  let out = head;

  for (let i = 0; i < lines.length; i += 1) {

    const rest = lines.length - i - 1;

    const tail = rest ? `\n… and ${rest} more` : '';

    if (`${out}\n${lines[i]}${tail}\n${footer}`.length > MAX_OUTPUT) {

      return `${out}\n… and ${lines.length - i} more\n${footer}`;

    }

    out += `\n${lines[i]}`;

  }

  return `${out}\n${footer}`;

}

Die letzte Zeile ist immer ein Link auf den vollständigen interaktiven Bericht. So kann der Agent dem Nutzer das ganze Ergebnis geben statt eines abgeschnittenen.

Fehler, die der Agent selbst beheben kann

Die WebMCP Best Practices raten, „streng im Code, locker im Schema“ zu validieren und Fehler zurückzugeben, mit denen das Modell arbeiten kann. Ein falscher Wert wirft keine Exception, sondern sagt dem Agenten genau, was er stattdessen schicken soll:

Invalid value "h100" for hardware. Use one of: none, gpu, tpu.

Das eine Tool mit `untrustedContentHint: true`

Vier Tools geben Text zurück, den ich geschrieben habe. check_gcp_iam_policy ist anders: Seine Befunde zitieren Rollennamen und Member-Strings aus der Policy, die der Nutzer übergeben hat. Eine Policy ist JSON, das jeder bearbeiten kann – ein Member-String könnte also eine Anweisung an das Modell enthalten. Nur dieses Tool ist mit untrustedContentHint: true markiert; alle fünf tragen readOnlyHint: true und consequentialHint: false.

Das Origin-Trial-Token läuft ab

Das Token steckt als Meta-Tag im Head der Seite und ist an https://www.alekseialeinikov.com gebunden:


<meta http-equiv="origin-trial" content="…token…">

Meins läuft am 17. November 2026 ab, und eine API zum Verlängern gibt es nicht. Ein wöchentlicher CI-Job prüft das Ablaufdatum und schlägt 21 Tage vorher fehl, sodass GitHub mir rechtzeitig eine Mail schickt. Ein abgelaufenes Token macht nichts kaputt – WebMCP schaltet sich einfach ab –, aber die Tools würden unbemerkt verschwinden.

Agent-Aufrufe messen

Jedes execute() sendet ein Analytics-Event mit tool_action: 'agent_call', getrennt von dem Event, das ein Mensch in der Oberfläche auslöst. Drei Tage nach dem Start steht der Zähler bei null. Das überrascht nicht: WebMCP ist noch ein Origin Trial, und ein Agent muss mit dem Tab verbunden sein, bevor irgendetwas ein Tool aufruft. Der Sinn, jetzt live zu gehen: bereit und messbar sein, wenn sich das ändert.

Selbst ausprobieren

In Chrome chrome://flags/#enable-webmcp-testing öffnen, aktivieren und neu starten.
Die Extension Model Context Tool Inspector installieren.
/de/tools/cron-translator öffnen und die Extension starten. Sie listet die fünf Tools mit ihren Schemas.
explain_cron mit {"expression": "30 2 * * 1-5", "timezone": "Europe/Berlin"} aufrufen – oder eine Frage in normaler Sprache eintippen und den Agenten der Extension das Tool wählen lassen.

Die Extension zeigt auch genau, was deine eigenen Tools zurückgeben. So prüfst du am schnellsten, ob Beschreibungen und Ausgaben für ein Modell gut lesbar sind.

WebMCP und Sicherheit

WebMCP schränkt ein, wer deine Tools sieht, macht einen Agenten aber nicht sicher. Googles Sicherheits-Guide sagt das deutlich: Modelle arbeiten probabilistisch, es gibt reproduzierbare Prompt-Injection-Angriffe auf Agenten, und Sicherheit innerhalb eines Large Language Models lässt sich nicht garantieren.

Was du als Betreiber der Website in der Hand hast:

Freigabe. Standardmäßig sehen nur deine Seite, Frames derselben Origin und eingebaute Browser-Agenten die Tools. Nimm Origins nur dann in exposedTo auf, wenn du dieselben Daten auch direkt mit dieser Website teilen würdest.
Annotationen. consequentialHint: true für alles, was Geld ausgibt, Nachrichten verschickt oder Daten löscht; untrustedContentHint: true für alles, was Text zurückgibt, den du nicht selbst geschrieben hast.
Validierung. Behandle jeden execute()-Aufruf wie eine API-Anfrage eines nicht vertrauenswürdigen Clients. Das Schema ist ein Hinweis an das Modell, keine Garantie.
Extensions. Eine Chrome-Extension mit Host-Berechtigungen kann deine WebMCP-Tools aufrufen – aber sie konnte auch vorher schon beliebiges JavaScript auf deiner Seite ausführen. WebMCP öffnet da kein neues Loch, es macht den vorgesehenen Weg sauberer.

Wer über Agenten nachdenkt, die auf echten Systemen handeln: Was passierte, als autonome KI-Agenten eine Regierungswebsite angriffen, ist eine gute Erinnerung daran, warum die Schutzmechanismen in deinen Code gehören.

Solltest du WebMCP jetzt einbauen?

Jetzt einbauen, wenn:

deine Website Aufgaben hat, nicht nur Inhalte – Suche, Filter, Konfiguratoren, Formulare, Rechner, Dashboards;
die Logik ohnehin im Browser läuft und Tools größtenteils Wrapper um vorhandene Funktionen sind;
du die ersten Tools nur lesend halten und schreibende Aktionen später mit consequentialHint nachziehen kannst.

Abwarten, wenn:

deine Seiten vor allem Artikel sind – die lesen Agenten heute schon gut, und eine llms.txt bringt mehr;
deine wichtigsten Aktionen serverseitigen Zustand brauchen, den die Seite nicht hat – das ist Aufgabe eines MCP-Servers;
du nicht zusagen kannst, alle paar Monate ein Origin-Trial-Token zu erneuern.

Weil das Ganze hinter einer Feature-Prüfung steckt, kostet es Nutzer ohne WebMCP nichts. Die eigentliche Arbeit ist gutes Tool-Design: kurze Beschreibungen, klare Schemas und Ausgaben, mit denen ein Modell etwas anfangen kann.

Fazit

WebMCP macht aus einer Website etwas, das ein Agent aufrufen kann, statt es entziffern zu müssen. Die Seite deklariert ihre Tools, Chrome führt die Registry, prüft die Schranken und führt dein execute() in der Session des Nutzers aus, und der Agent bekommt eine typisierte, kurze Antwort statt eines Screenshots zum Deuten.

Es ist früh: ein Origin Trial in Chrome und Edge, ein Desktop-Assistent und bisher null Agent-Aufrufe in meiner eigenen Analytics. Aber die API ist klein, die Kosten für alle anderen sind null, und die Tools im Tools-Bereich dieser Website haben weniger Code gebraucht als die Oberfläche drumherum. Wenn deine Website Aufgaben hat und die Logik schon im Browser läuft, lohnt es sich, jetzt ein einziges Lese-Tool live zu schalten und zu schauen, was es aufruft.

Ursprünglich veröffentlicht auf alekseialeinikov.com

Claude Sonnet 5.5 vs. Opus 5.5: Halber Preis, fast gleiche Scores – und eine Routing-Falle

Aleksei Aleinikov — Tue, 29 Sep 2026 10:00:00 +0000

Anthropic hat Claude Sonnet 5.5 am 28. September 2026 veröffentlicht, und eine Zahl aus dem Launch-Beitrag erklärt die Aufmerksamkeit: Bei Terminal-Bench 4.0, einem Benchmark für agentisches Coding in der Kommandozeile, erreicht Sonnet 5.5 70,6 %. Opus 5.5, das eine Woche zuvor erschienene Flaggschiff zum doppelten Preis, kommt auf seiner besten Effort-Stufe auf 66,4 %.

Der naheliegende Plan schreibt sich also von selbst: Routinearbeit an Sonnet, die schweren Teile an Opus eskalieren, Differenz einstreichen. Dieser Leitfaden vergleicht beide Modelle anhand der von Anthropic veröffentlichten Zahlen, rechnet den tatsächlichen Preisabstand pro Agent-Turn aus und zeigt dann die Zeile in der Dokumentation, die genau diesen naheliegenden Router still und leise schlechter macht als jedes der beiden Modelle allein.

Sonnet 5.5 vs. Opus 5.5 auf einen Blick

Die Angaben stammen von der Modellseite zu Sonnet 5.5 und der Modellübersicht.

	Claude Sonnet 5.5	Claude Opus 5.5
API-Modell-ID	`claude-sonnet-5-5`	`claude-opus-5-5`
Input / Output pro Million Tokens	2 $ / 10 $	4 $ / 20 $
Cache Read pro Million Tokens	0,20 $	0,20 $
5-Minuten-Cache-Write	2,50 $	5 $
Kontextfenster / max. Output	1M / 128K	1M / 128K
Thinking	Adaptiv; reduzierbar auf `between_tools`	Adaptiv, immer aktiv
Standard-Effort auf der Claude API	`high`	`medium`
Relative Latenz	Schnell	Mittel
Wissensstand	Juni 2026	Juni 2026
Anthropics eigene Beschreibung	„Die beste Kombination aus Geschwindigkeit und Intelligenz“	„Für langlaufendes agentisches Coding und Wissensarbeit“

Zwei Zeilen dieser Tabelle sind wichtiger, als sie aussehen:

Cache Reads kosten dasselbe. Opus 5.5 liest seinen Cache zu 5 % seines Input-Preises, Sonnet 5.5 zu 10 % seines – beide landen bei 0,20 $. In Agent-Loops, die in jedem Turn einen langen gecachten Präfix neu lesen, ist das der Großteil der Input-Rechnung. Warum das so viel ausmacht, habe ich in der Cache-Read-Regel bei den Preisen von Fable und Mythos beschrieben.
Der Standard-Effort unterscheidet sich. Sonnet 5.5 startet auf der API mit high, Opus 5.5 mit medium. Wer beide ohne gesetztes output_config.effort im A/B-Test vergleicht, vergleicht Sonnet auf high mit Opus auf medium. In Claude Code und den Claude-Apps läuft Sonnet 5.5 standardmäßig auf medium.

Beide Modelle gibt es auf der Claude API, Amazon Bedrock, Google Cloud, Microsoft Foundry und Claude Platform on AWS. Ein kleineres Haiku 5.5 ist „in den kommenden Wochen“ angekündigt.

Die Benchmarks: Wo das günstigere Modell gewinnt

Das sind die von Anthropic im Launch-Beitrag veröffentlichten Zahlen. Der Terminal-Bench-Wert von Opus 5.5 ist sein höchster, gemessen auf xhigh.

Benchmark	Sonnet 5.5	Opus 5.5	Sonnet 5	Sonnet vs. Opus
Terminal-Bench 4.0 (agentisches Coding im Terminal)	70,6 %	66,4 %	10,3 %	+4,2
FrontierCode 1.1 Main (mergefähige Änderungen)	52,1 % auf xhigh · 46,2 % auf max	54,4 %	42,4 %	−2,3
CursorBench 4.0 (echte Cursor-Sessions)	55,5 %	57,8 %	34,1 %	−2,3
GDPval-AA v2.1 (44 Berufe, Elo)	1844	1846	1449	−2
AA-Briefcase v1.1 (Wissensarbeit, Elo)	1811	1822	1359	−11
Humanity’s Last Exam, mit Tools	64,5 %	67,7 %	54,9 %	−3,2
OSWorld 2.1 (Computer Use)	80,1 %	81,8 %	57,0 %	−1,7
Chartography, ohne Tools	61,6 %	64,4 %	15,6 %	−2,8

Gleiche Zeile, zwei Balken. Der Abstand dazwischen ist das, wofür Sie den doppelten Listenpreis zahlen.

Drei Dinge sollten Sie aus dieser Tabelle mitnehmen, bevor Sie Ihre Routing-Konfiguration umschreiben:

Der Terminal-Bench-Sieg ist echt, aber eng gefasst. Gemessen wird mehrstufige Arbeit in der Kommandozeile – genau das, was Coding-Agents den ganzen Tag tun. Eine allgemeine Aussage, Sonnet 5.5 sei das stärkere Modell, ist das nicht, und Anthropic macht sie auch nicht: Im Beitrag heißt es, Opus 5.5 bleibe „bei komplexer, offener Arbeit, die anhaltendes Urteilsvermögen erfordert, klar stärker“, und der Sicherheitsabschnitt stellt fest, dass Sonnet 5.5 „die Grenze der Fähigkeiten unserer Modelle nicht verschiebt“.
Mehr Effort hat einen Wert verschlechtert. Bei FrontierCode erreichte Sonnet 5.5 auf xhigh 52,1 %, auf max nur 46,2 %. FrontierCode bestraft Änderungen außerhalb des Aufgabenumfangs; auf max startete Sonnet häufiger den Code-Review-Skill von Claude Code, der sich auf viele Subagents verteilt, und in den von Cognition untersuchten Fällen führte das zu einem Timeout oder zu zusätzlichen Änderungen. Max-Effort ist kein kostenloses Upgrade.
Der Sprung gegenüber Sonnet 5 ist die größere Geschichte. GDPval-AA stieg um rund 400 Elo-Punkte, OSWorld um 23 Punkte. Wer noch auf Sonnet 5 ist, wechselt ohnehin; die einzige Frage ist, wo Opus seinen Preis noch verdient.

Zwei Einschränkungen zur Herkunft: Das alles sind Herstellerangaben, und Artificial Analysis hat GDPval-AA und AA-Briefcase auf einem Pre-Release-Deployment mit einem Structured-Outputs-Bug gemessen, der Sonnets Werte laut Anthropic leicht unterschätzt haben könnte. Verstehen Sie die Tabelle als Landkarte, wo Sie Ihre eigenen Evals laufen lassen sollten – nicht als Ersatz dafür.

Der Preisabstand ist nicht 2×

Laut Listenpreis kostet Opus 5.5 genau doppelt so viel. Was ein Agent pro Turn tatsächlich zahlt, hängt von seinem Token-Mix ab – und in einem langen Agent-Loop dominieren Cache Reads, die, wie die Tabelle oben zeigt, bei beiden Modellen gleich viel kosten.

Nehmen Sie einen typischen Coding-Agent-Turn mitten in einer Session: 60.000 Tokens gecachter Kontext werden neu gelesen, 3.000 neue Tokens in den Cache geschrieben (das letzte Tool-Ergebnis und die nächste Anweisung), und 1.500 Output-Tokens inklusive Thinking. Thinking wird bei beiden Modellen als Output berechnet.

Pro Turn	Sonnet 5.5	Opus 5.5	Sonnet 5.5, doppelter Output
60K Cache Reads × 0,20 $/M	0,0120 $	0,0120 $	0,0120 $
3K Cache Writes (5 Min.)	0,0075 $	0,0150 $	0,0075 $
Output inkl. Thinking	0,0150 $ (1,5K)	0,0300 $ (1,5K)	0,0300 $ (3K)
Summe pro Turn	0,0345 $	0,0570 $	0,0495 $
Opus-Aufpreis	1,65×	—	1,15×

Der Cache-Read-Balken ist identisch. Alles andere ist, wohin der doppelte Listenpreis fließt – und wo er verschwinden kann.

Die Zahlen sind illustrativ – Ihr Token-Mix wird anders aussehen –, aber die Form gilt für jeden cachelastigen Agent. Der Aufpreis schrumpft von 2× auf etwa 1,65×, und wenn Sonnet länger nachdenken muss, um zur selben Antwort zu kommen, schrumpft er weiter.

Genau das zeigen auch Anthropics eigene Diagramme zu den Kosten pro Aufgabe. Auf niedrigem oder mittlerem Effort übertrifft Sonnet 5.5 bei mehreren Benchmarks den besten Wert von Sonnet 5 für etwa ein Zehntel der Kosten pro Aufgabe, und bei FrontierCode liegt es auf high zehn Punkte über Sonnet 5 auf derselben Stufe, für etwa ein Fünfzehntel der Kosten pro Aufgabe. Zum oberen Ende ist der Launch-Beitrag aber offen: Sonnet 5.5 „ergänzt Opus 5.5 am besten auf niedrigeren Effort-Stufen, wo es pro Aufgabe weniger kostet. Auf höheren Stufen kann es vergleichbare Leistung zu ähnlichen Kosten erbringen.“

Mit anderen Worten: Die Ersparnis liegt bei low und medium. Wer Sonnet 5.5 auf max laufen lässt, um die letzten Punkte herauszuholen, zahlt ungefähr Opus-Preise ohne Opus-Urteilsvermögen.

Die Routing-Falle: Sie können das Thinking des anderen nicht lesen

Hier kommt der Teil, den die Benchmark-Threads übersehen. Seit Claude Fable 5.1 verschärft Anthropic, wie Thinking-Blöcke über Turns hinweg erhalten bleiben – vor allem, um Distillation zu verhindern. Für Sonnet 5.5 legt die Dokumentation fest, welches Modell wessen Reasoning lesen kann:

Sonnet 5.5 liest Thinking-Blöcke von Sonnet 5, Opus 4.8, Haiku 4.5 und älteren Modellen – aber nicht von Opus 5, Opus 5.5 oder einem Fable- oder Mythos-Modell.
Kein anderes Modell liest Thinking-Blöcke von Sonnet 5.5.

Wechselt eine Konversation zu einem Modell, das einen Block nicht lesen kann, verwirft die API diesen Block, bevor der Prompt das Modell erreicht. Die Anfrage gelingt trotzdem mit 200, und die verworfenen Blöcke werden nicht berechnet. Ohne einen optionalen Beta-Header geschieht das lautlos.

Jeder Pfeil ist ein Modellwechsel. Jedes rote Kreuz ist Reasoning, das das nächste Modell nie sieht.

Spielen Sie jetzt den Router durch, den gerade alle bauen:

Sonnet 5.5 arbeitet die ersten Turns ab und baut Reasoning über Ihre Codebasis auf.
Der Router hält den nächsten Schritt für schwer und schickt ihn an Opus 5.5. Opus startet ohne Sonnets Reasoning. Es sieht weiterhin Text und Tool-Aufrufe, nur nicht das Denken dahinter.
Der Router geht für die einfache Folgefrage zurück zu Sonnet 5.5. Sonnet sieht nicht, was Opus gedacht hat.
Eine Cyber-bezogene Anfrage löst den serverseitigen Fallback auf Sonnet 5 aus. Auch Sonnet 5 kann das Reasoning von Sonnet 5.5 nicht lesen.

Dasselbe gilt für jedes Setup, das auf Opus plant und auf Sonnet ausführt, sobald der Sonnet-Slot auf 5.5 zeigt: Der Ausführende bekommt den Plan, aber nicht das Reasoning, das ihn hervorgebracht hat. Verworfene Blöcke kosten direkt nichts, aber für den eng verwandten Fall der Präfix-Prüfung warnt die Dokumentation, dass Claude manchmal mehr nachdenkt, um verlorenes Reasoning zu rekonstruieren – der Token-Verbrauch einer Session kann also trotzdem steigen.

Zwei weitere Bindungen kommen zur Modellprüfung hinzu:

Thinking ist an das Konto gebunden. Die Thinking-Blöcke von Sonnet 5.5 funktionieren nur in dem Konto, das sie erzeugt hat, oder in einem verknüpften. Eine Session, die unter dem API-Key eines anderen Nutzers fortgesetzt wird, gemeinsame Session-Speicher über Organisationen hinweg oder ein Kontowechsel mitten in einer Claude-Code-Session laufen alle in ein lautloses Verwerfen mit dem Grund organization_binding_mismatch.
Thinking ist an den Präfix der Konversation gebunden. Ein Thinking-Block bleibt nur gültig, solange der system-Prompt, die tools-Liste und alle früheren Nachrichten unverändert sind. Für Konten, die am oder nach dem 31. August 2026, 00:00 UTC, angelegt wurden, erzwingt die API das bei Sonnet 5.5, Opus 5.5 und Fable 5.1 standardmäßig und liefert bei einem bearbeiteten Verlauf einen 400. Ältere Konten erzwingen es nur auf Anfrage – Code, der mit Ihrem alten Key funktioniert, kann also bei einem Kunden mit neuem Konto scheitern.

So routen Sie, ohne den Faden zu verlieren

Routen Sie pro Konversation, nicht pro Turn. Entscheiden Sie zu Beginn, ob eine Aufgabe Sonnet- oder Opus-Arbeit ist.
Eskalieren Sie mit einem Neustart. Wenn Sonnet hängen bleibt, fassen Sie den Stand zusammen und eröffnen eine neue Konversation auf Opus. Die Dokumentation nennt das Simple Compaction und empfiehlt es; nichts Früheres wird erneut gesendet, also wird auch nichts verworfen.
Oder lassen Sie Sonnet führen und Opus beraten. Mit dem Advisor-Tool kann ein Sonnet-5.5-Executor einen Opus-5.5-Advisor konsultieren, ohne das Modell der Konversation zu wechseln. Beachten Sie, dass der Rat verschlüsselt als advisor_redacted_result-Block zurückkommt und in der Antwort nicht lesbar ist.
Machen Sie Verwerfungen sichtbar. Senden Sie den Beta-Header thinking-binding-controls-2026-08-01 und loggen Sie input_transformations bei jeder Antwort:


response = client.beta.messages.create(

    model="claude-sonnet-5-5",

    max_tokens=16000,

    thinking={

        "type": "adaptive",

        "block_binding": {"prefix_mismatch_behavior": "drop_block"},

    },

    messages=messages, # nur anhängen: frühere Turns nie bearbeiten

    betas=["thinking-binding-controls-2026-08-01"],

)

for t in response.input_transformations or []:

    # reason: model_binding_mismatch | organization_binding_mismatch | prefix_binding_mismatch

    log.warning("thinking dropped at %s: %s", t.path, t.reason)

Bei Sonnet 5.5 funktioniert block_binding nur mit adaptivem Thinking; zusammen mit between_tools gibt es einen 400-Fehler.

Fünf Breaking Changes beim Upgrade von Sonnet 5

Sonnet 5.5 kostet dasselbe wie Sonnet 5 und hat eine Modell-ID ohne Datumssuffix – die Versuchung ist groß, einfach den String zu tauschen und auszuliefern. Der Migrationsleitfaden nennt fünf Dinge, die brechen:

Was Sie heute senden	Bei Sonnet 5.5	Lösung
`thinking: {"type": "disabled"}`	400-Fehler	`{"type": "between_tools"}` – nur bei `low`, `medium` oder `high`
`tool_choice` vom Typ `any` oder `tool`	400-Fehler	`auto` plus `strict: true` am Tool, und im Prompt sagen, wann es aufzurufen ist
`computer_20251124` auf der Claude API oder Google Cloud	400-Fehler	`computer_toolset_20260801`
Advisor-Tool mit Sonnet 5, Opus 4.8 und einigen älteren Advisors	400-Fehler	Mit Opus 5, Opus 5.5, Sonnet 5.5, Fable oder Mythos kombinieren
Frühere Nachrichten, `system` oder `tools` mitten in der Session ändern	400 bei Konten ab dem 31.08.2026	Verlauf nur anhängen; System-Nachrichten mitten im Gespräch nutzen

Dazu drei Änderungen, die keine Anfrage scheitern lassen, Sie aber überraschen werden:

Text zwischen Tool-Aufrufen wandert in Thinking-Blöcke. Notizen, die länger als ein, zwei Sätze sind und die das Modell zwischen Tool-Aufrufen schreibt, kommen jetzt als Fortschritts-thinking-Blöcke zurück, die bei der Standardanzeige leer sind. Eine Oberfläche, die diese Notizen an Nutzer streamt, verstummt, bis Sie display auf "updates" (Beta) oder "summarized" setzen oder between_tools verwenden.
Die Effort-Stufen sind neu kalibriert. Eine Stufe erzeugt nicht mehr dieselbe Menge Thinking wie bei Sonnet 5. Anthropic empfiehlt medium als Start für klar umrissenes agentisches Coding und high für schwierigere Aufgaben – wiederholen Sie Ihren Effort-Sweep und messen Sie die Kosten neu.
Prompt Caching lohnt sich früher. Der minimale cachebare Prompt sinkt von 1.024 auf 512 Tokens.

Auf Amazon Bedrock gibt es eine zusätzliche Falle: Strict Tool Use ist dort für Sonnet 5.5 nicht verfügbar. Aus dem Ersatz auto plus strict für erzwungene Tool-Nutzung wird dort auto plus Ihre eigene Eingabevalidierung. Auf Google Cloud und der Claude API funktioniert strict.

Wer von Sonnet 4.6 oder älter kommt, hat zusätzlich die älteren Breaking Changes: Nicht-Standardwerte für temperature, top_p oder top_k liefern einen 400, budget_tokens ist zugunsten von Effort entfallen, derselbe Text ergibt rund 30 % mehr Tokens, und ein Bild mit 2000×1500 Pixeln kostet etwa 2,5-mal so viele Tokens. Ab Sonnet 4.5 oder älter liefern zusätzlich vorausgefüllte Assistant-Turns einen 400.

Am schnellsten kommen Sie in einer echten Codebasis mit dem mitgelieferten Claude-API-Skill in Claude Code durch all das:

/claude-api migrate this project to claude-sonnet-5-5

Eine minimale Anfrage, die mit Sonnet 5.5 so funktioniert:


response = client.messages.create(

    model="claude-sonnet-5-5",

    max_tokens=16000,

    thinking={"type": "between_tools"}, # ersetzt {"type": "disabled"}

    output_config={"effort": "medium"}, # explizit setzen; API-Standard ist high

    tools=[{**weather_tool, "strict": True}],

    tool_choice={"type": "auto"}, # "any" und "tool" liefern jetzt 400

    messages=messages,

)

for block in response.content: # nie blind content[0].text lesen

    if block.type == "text":

        print(block.text)

Für Security-Teams: der Cyber-Fallback

Laut Anthropic sind die Cyber-Fähigkeiten von Sonnet 5.5 ein großer Schritt gegenüber Sonnet 5, deshalb wird es mit Echtzeit-Schutzmaßnahmen ähnlich denen von Opus 5.5 ausgeliefert – als erstes Sonnet-Modell. In der Praxis liefert eine Ablehnung stop_reason: "refusal", und stop_details kann eine von fünf Kategorien nennen: cyber, bio, frontier_llm, reasoning_extraction oder general_harms.

Zwei Details sind für Engineering-Teams wichtig:

Riskantere Cyber-Arbeit fällt auf Sonnet 5 zurück. Mit aktiviertem serverseitigem Fallback (fallbacks: "default", Beta, nur Claude API) werden Ablehnungen der Kategorien cyber und frontier_llm auf Sonnet 5 wiederholt. Routinemäßiges Finden und Beheben von Bugs ist nicht betroffen. Verteidiger, die mehr brauchen, können sich für das Cyber Verification Program bewerben; einen erweiterten, gestuften Zugang für Sonnet 5.5 kündigt Anthropic für bald an. Und denken Sie an die Routing-Falle: Dieser Fallback läuft ohne das Reasoning von Sonnet 5.5.
Nach der Chain of Thought zu fragen ist jetzt eine Ablehnung. Sonnet 5.5 ist das erste Sonnet-Modell mit Klassifikatoren gegen Reasoning-Extraktion. Ein Prompt, der das Modell auffordert, sein internes Reasoning im Antworttext wiederzugeben, bekommt eine Ablehnung der Kategorie reasoning_extraction. Tools, die „das Denken des Modells zeigen“, indem sie danach fragen, müssen auf display: "summarized" umstellen.

Es gibt auch eine gute Nachricht für alle, die Agents in Containern betreiben. In Anthropics Containment-Evaluationen kam Sonnet 5.5 nah an Opus 5.5 heran, was die Seltenheit von Ausbruchsversuchen aus der Sandbox angeht, und war von allen Anthropic-Modellen am wenigsten geneigt, die Grenzen seiner Container auszutesten. Das ist eine nützliche Eigenschaft, keine Garantie – jüngste Vorfälle mit autonomen Agents zeigen, warum die Grenze in Ihre Infrastruktur gehört und nicht ins Modell.

Welches Modell sollten Sie nutzen?

Sonnet 5.5 auf medium – Ihr neuer Standard für agentisches Coding bei klar umrissenen Aufgaben, Bugfixes, Terminal-Arbeit, CI-Jobs, Computer Use sowie Dokumente und Folien. Hier ist der Benchmark-Abstand am kleinsten und der Kostenabstand am größten.
Sonnet 5.5 auf low oder mit between_tools – Chat und latenzkritische Arbeit. Für Klassifikation und Extraktion in großem Volumen sind ein kleines Entscheidungsmodell oder das angekündigte Haiku 5.5 noch günstiger.
Opus 5.5 – mehrdeutige, langlaufende oder offene Arbeit, Architekturentscheidungen, große Refactorings und alles, wo eine falsche Antwort mehr kostet als die Tokens. Sein Standard-Effort medium ist bereits ein vernünftiger Ausgangspunkt.
Sonnet 5.5 auf xhigh oder max – nur, wenn Ihre eigenen Evals es belegen. Die Kosten nähern sich Opus an, und FrontierCode zeigt, dass Max-Effort schlechter abschneiden kann als xhigh.
Beide – pro Konversation routen, über eine Zusammenfassung oder das Advisor-Tool eskalieren und input_transformations loggen, damit Sie jeden verworfenen Block sehen.

Wenn Sie diese Modelle über einen Coding-Agent statt direkt über die API nutzen, taucht dieselbe Wahl in /model und /effort auf. Die Agent-Seite dieser Abwägung beschreibe ich in wie KI-Coding-Agents wie Claude Code, Codex und opencode wirklich funktionieren, und was der Agent tun darf, sobald er ein Modell gewählt hat, in den Berechtigungsmodi von Claude Code im Vergleich.

Fazit

Sonnet 5.5 ist das seltene Release, bei dem das günstigere Modell die Standardantwort ist. Es liegt bei den meisten von Anthropic gemessenen Aufgaben nur ein, zwei Punkte hinter Opus 5.5, schlägt es bei terminalbasierter Agent-Arbeit und kostet den halben Listenpreis – mit einem realen Abstand pro Turn eher bei 1,65×, sobald man Cache Reads mitrechnet.

Die günstigste Architektur ist aber nicht „Sonnet für leichte Turns, Opus für schwere Turns“. Diese beiden Modelle teilen ihr Reasoning nicht, die API sagt Ihnen nicht, wann sie es verwirft, und bei neuen Konten ist ein bearbeiteter Verlauf ein harter Fehler. Wählen Sie das Modell pro Konversation, halten Sie diese Konversation append-only und lassen Sie Opus über einen Neustart oder das Advisor-Tool hinein – nicht mitten in einen Gedanken.

Ursprünglich veröffentlicht auf alekseialeinikov.com

Claude Sonnet 5.5 vs Opus 5.5: Half the Price, Nearly the Same Scores — and a Routing Trap

Aleksei Aleinikov — Tue, 29 Sep 2026 10:00:00 +0000

Anthropic released Claude Sonnet 5.5 on September 28, 2026, and one number from the launch post explains the attention it got: on Terminal-Bench 4.0, an agentic coding benchmark run in the command line, Sonnet 5.5 scores 70.6%. Opus 5.5, the flagship released a week earlier at twice the price, scores 66.4% at its best effort level.

So the obvious plan writes itself: send the routine work to Sonnet, escalate the hard parts to Opus, and pocket the difference. This guide compares the two models on the numbers Anthropic published, works out what the price gap really is per agent turn, and then shows the line in the documentation that makes that obvious router quietly worse than either model on its own.

Sonnet 5.5 vs Opus 5.5 at a Glance

The specs below come from the Sonnet 5.5 model page and the models overview.

	Claude Sonnet 5.5	Claude Opus 5.5
API model ID	`claude-sonnet-5-5`	`claude-opus-5-5`
Input / output per million tokens	$2 / $10	$4 / $20
Cache read per million tokens	$0.20	$0.20
5-minute cache write	$2.50	$5
Context window / max output	1M / 128K	1M / 128K
Thinking	Adaptive; can drop to `between_tools`	Adaptive, always on
Default effort on the Claude API	`high`	`medium`
Comparative latency	Fast	Moderate
Knowledge cutoff	June 2026	June 2026
Anthropic’s own description	“The best combination of speed and intelligence”	“For long-running agentic coding and knowledge work”

Two rows in that table matter more than they look:

Cache reads cost the same. Opus 5.5 reads its cache at 5% of its input price and Sonnet 5.5 at 10% of its, which lands both at $0.20. For agent loops that re-read a long cached prefix every turn, that is most of the input bill. I covered why this matters in the cache read rule for Fable and Mythos pricing.
The default effort differs. Sonnet 5.5 defaults to high on the API, Opus 5.5 to medium. If you A/B test them without setting output_config.effort, you are comparing Sonnet at high against Opus at medium. In Claude Code and the Claude apps, Sonnet 5.5 runs at medium by default.

Both models are available on the Claude API, Amazon Bedrock, Google Cloud, Microsoft Foundry and Claude Platform on AWS. A smaller Haiku 5.5 is announced “in the coming weeks”.

The Benchmarks: Where the Cheaper Model Wins

These are Anthropic’s published numbers from the launch post. The Opus 5.5 score on Terminal-Bench is its highest, measured at xhigh effort.

Benchmark	Sonnet 5.5	Opus 5.5	Sonnet 5	Sonnet vs Opus
Terminal-Bench 4.0 (agentic terminal coding)	70.6%	66.4%	10.3%	+4.2
FrontierCode 1.1 Main (mergeable changes)	52.1% at xhigh · 46.2% at max	54.4%	42.4%	−2.3
CursorBench 4.0 (real Cursor sessions)	55.5%	57.8%	34.1%	−2.3
GDPval-AA v2.1 (44 occupations, Elo)	1844	1846	1449	−2
AA-Briefcase v1.1 (knowledge work, Elo)	1811	1822	1359	−11
Humanity’s Last Exam, with tools	64.5%	67.7%	54.9%	−3.2
OSWorld 2.1 (computer use)	80.1%	81.8%	57.0%	−1.7
Chartography, no tools	61.6%	64.4%	15.6%	−2.8

Same row, two dots. The distance between them is what you pay 2× list price for.

Three things to read out of this table before you rewrite your routing config:

The Terminal-Bench win is real but narrow. It measures multi-step work in a command line — exactly what coding agents do all day. It is not a general claim that Sonnet 5.5 is the stronger model, and Anthropic doesn’t make one: the post says Opus 5.5 “remains clearly stronger at complex, open-ended work requiring sustained judgment”, and the safety section notes that Sonnet 5.5 “doesn’t advance the frontier of our models’ capabilities”.
More effort made one score worse. On FrontierCode, Sonnet 5.5 scored 52.1% at xhigh and only 46.2% at max. FrontierCode penalizes changes beyond the task’s scope; at max effort Sonnet more often ran Claude Code’s code-review skill, which fans out into many subagents, and in the cases Cognition examined that led to a timeout or extra edits. Max effort is not a free upgrade.
The jump from Sonnet 5 is the bigger story. GDPval-AA rose by about 400 Elo points and OSWorld by 23 points. If you are still on Sonnet 5, you are upgrading either way; the only question is where Opus still earns its price.

Two caveats on provenance: all of these are vendor-published results, and Artificial Analysis ran GDPval-AA and AA-Briefcase on a pre-release deployment with a structured-outputs bug that Anthropic says may have slightly understated Sonnet’s scores. Treat the table as a map of where to run your own evals, not as the evals.

The Price Gap Is Not 2×

List price says Opus 5.5 costs exactly twice as much. What an agent actually pays per turn depends on its token mix, and in a long agent loop that mix is dominated by cache reads — which, as the table above shows, cost the same on both models.

Take a typical coding-agent turn in the middle of a session: 60,000 tokens of cached context re-read, 3,000 new tokens written to the cache (the last tool result and the next instruction), and 1,500 output tokens including thinking. Thinking is billed as output on both models.

Per turn	Sonnet 5.5	Opus 5.5	Sonnet 5.5, twice the output
60K cache reads × $0.20/M	$0.0120	$0.0120	$0.0120
3K cache writes (5-min)	$0.0075	$0.0150	$0.0075
Output incl. thinking	$0.0150 (1.5K)	$0.0300 (1.5K)	$0.0300 (3K)
Total per turn	$0.0345	$0.0570	$0.0495
Opus premium	1.65×	—	1.15×

The cache-read bar is identical. Everything else is where the 2× list price goes — and where it can vanish.

The numbers are illustrative — your token mix will differ — but the shape holds for any cache-heavy agent. The premium shrinks from 2× to about 1.65×, and if Sonnet has to think longer to reach the same answer, it shrinks further.

That is exactly what Anthropic’s own cost-per-task charts show. At low or medium effort, Sonnet 5.5 beats Sonnet 5’s best score on several benchmarks for about a tenth of the cost per task, and on FrontierCode at high effort it scores ten points above Sonnet 5 at the same setting, at about one fifteenth of the cost per task. But the launch post is candid about the top end: Sonnet 5.5 “complements Opus 5.5 best when running at lower effort settings, where it costs less per task. At higher settings, it can perform comparably at a similar cost.”

In other words: the savings live at low and medium. Running Sonnet 5.5 at max to squeeze out the last points gets you roughly Opus prices without Opus judgment.

The Routing Trap: They Can’t Read Each Other’s Thinking

Here is the part that the benchmark threads miss. Since Claude Fable 5.1, Anthropic has been tightening how thinking blocks are preserved across turns, mainly to stop distillation. For Sonnet 5.5 the docs spell out which models can read whose reasoning:

Sonnet 5.5 reads thinking blocks from Sonnet 5, Opus 4.8, Haiku 4.5 and earlier models — but not from Opus 5, Opus 5.5, or any Fable or Mythos model.
No other model reads thinking blocks from Sonnet 5.5.

When a conversation moves to a model that can’t read a block, the API drops that block before the prompt reaches the model. The request still succeeds with a 200, and the dropped blocks aren’t billed. Without an opt-in beta header, the drop is silent.

Each arrow is a model switch. Each red cross is reasoning the next model never sees.

Now replay the router everyone is about to build:

Sonnet 5.5 works through the first turns and builds up reasoning about your codebase.
The router decides the next step is hard and sends it to Opus 5.5. Opus starts without Sonnet’s reasoning. It still sees the text and tool calls, just not the thinking behind them.
The router drops back to Sonnet 5.5 for the easy follow-up. Sonnet doesn’t see what Opus thought.
A cyber-related request triggers the server-side fallback to Sonnet 5. Sonnet 5 can’t read Sonnet 5.5’s reasoning either.

The same applies to any plan-on-Opus, execute-on-Sonnet setup once its Sonnet slot points at 5.5: the executor gets the plan, but not the reasoning that produced it. Dropped blocks cost nothing directly, but in the closely related prefix-check case the docs warn that Claude can sometimes think more to re-create the reasoning it lost, so a session’s token usage can still rise.

Two more bindings sit on top of the model check:

Thinking is bound to the account. Sonnet 5.5’s thinking blocks work only in the account that produced them or a linked one. Resuming a session under a different user’s API key, shared session stores across organizations, or switching accounts mid-session in Claude Code all hit a silent drop with the reason organization_binding_mismatch.
Thinking is bound to the conversation prefix. A thinking block stays valid only while the system prompt, the tools list and every earlier message are unchanged. For accounts created on or after August 31, 2026, 00:00 UTC, the API enforces this on Sonnet 5.5, Opus 5.5 and Fable 5.1 by default and returns a 400 on an edited history. Older accounts don’t enforce it unless asked — which means code that works on your old key can fail for a customer with a new one.

How to route without losing the plot

Route per conversation, not per turn. Decide at the start whether a task is Sonnet work or Opus work.
Escalate by starting fresh. When Sonnet gets stuck, summarize the task state and open a new conversation on Opus. The docs call this simple compaction and recommend it; nothing earlier is replayed, so nothing is dropped.
Or keep Sonnet in charge and consult Opus. The advisor tool lets a Sonnet 5.5 executor consult an Opus 5.5 advisor without switching the conversation’s model. Note that the advice comes back encrypted as an advisor_redacted_result block, so you can’t read it in the response.
Make drops visible. Send the thinking-binding-controls-2026-08-01 beta header and log input_transformations on every response:


response = client.beta.messages.create(

    model="claude-sonnet-5-5",

    max_tokens=16000,

    thinking={

        "type": "adaptive",

        "block_binding": {"prefix_mismatch_behavior": "drop_block"},

    },

    messages=messages, # append-only: never edit earlier turns

    betas=["thinking-binding-controls-2026-08-01"],

)

for t in response.input_transformations or []:

    # reason: model_binding_mismatch | organization_binding_mismatch | prefix_binding_mismatch

    log.warning("thinking dropped at %s: %s", t.path, t.reason)

On Sonnet 5.5, block_binding works only with adaptive thinking; sending it with between_tools returns a 400.

Five Breaking Changes If You Upgrade From Sonnet 5

Sonnet 5.5 has the same price as Sonnet 5 and a model ID with no date suffix, so it’s tempting to swap the string and ship. The migration guide lists five things that break:

What you send today	On Sonnet 5.5	Fix
`thinking: {"type": "disabled"}`	400 error	`{"type": "between_tools"}` — only at `low`, `medium` or `high` effort
`tool_choice` of type `any` or `tool`	400 error	`auto` plus `strict: true` on the tool, and say in the prompt when to call it
`computer_20251124` on the Claude API or Google Cloud	400 error	`computer_toolset_20260801`
Advisor tool with Sonnet 5, Opus 4.8 and some older advisors	400 error	Pair with Opus 5, Opus 5.5, Sonnet 5.5, Fable or Mythos
Editing earlier messages, `system` or `tools` mid-session	400 on accounts created on or after Aug 31, 2026	Append-only history; use mid-conversation system messages

And three changes that don’t fail any request but will surprise you:

Text between tool calls moves into thinking blocks. Notes longer than a sentence or two that the model writes between tool calls now come back as progress-update thinking blocks, which are empty at the default display setting. A UI that streams those notes to users goes quiet until you set display to "updates" (beta) or "summarized", or use between_tools.
Effort levels are recalibrated. A level no longer produces the same amount of thinking as on Sonnet 5. Anthropic recommends starting at medium for well-specified agentic coding and high for harder tasks — re-run your effort sweep and re-baseline cost.
Prompt caching gets cheaper to start. The minimum cacheable prompt drops from 1,024 to 512 tokens.

On Amazon Bedrock there is one extra trap: strict tool use isn’t available for Sonnet 5.5 there, so the auto plus strict replacement for forced tool use becomes auto plus your own input validation. On Google Cloud and the Claude API, strict works.

If you’re coming from Sonnet 4.6 or earlier, add the older breaking changes on top: non-default temperature, top_p or top_k return a 400, budget_tokens is gone in favour of effort, the same text produces about 30% more tokens, and a 2000×1500 image costs about 2.5 times as many tokens. From Sonnet 4.5 or earlier, prefilled assistant turns also return a 400.

The fastest way through all of it in a real codebase is the bundled Claude API skill in Claude Code:

/claude-api migrate this project to claude-sonnet-5-5

A minimal request that works on Sonnet 5.5 as written:


response = client.messages.create(

    model="claude-sonnet-5-5",

    max_tokens=16000,

    thinking={"type": "between_tools"}, # replaces {"type": "disabled"}

    output_config={"effort": "medium"}, # set it explicitly; API default is high

    tools=[{**weather_tool, "strict": True}],

    tool_choice={"type": "auto"}, # "any" and "tool" now return 400

    messages=messages,

)

for block in response.content: # never read content[0].text blindly

    if block.type == "text":

        print(block.text)

For Security Teams: The Cyber Fallback

Anthropic says Sonnet 5.5’s cyber capabilities are a large step up from Sonnet 5, so it ships with real-time safeguards similar to those on Opus 5.5 — the first Sonnet model to do so. In practice that means a decline returns stop_reason: "refusal", and stop_details can name one of five categories: cyber, bio, frontier_llm, reasoning_extraction or general_harms.

Two details matter for engineering teams:

Higher-risk cyber work falls back to Sonnet 5. With server-side fallback enabled (fallbacks: "default", beta, Claude API only), cyber and frontier_llm declines are retried on Sonnet 5. Routine bug finding and fixing isn’t affected. Defenders who need more can apply to the Cyber Verification Program; Anthropic says expanded tiered access for Sonnet 5.5 is coming soon. And remember the routing trap: that fallback runs without Sonnet 5.5’s reasoning.
Asking for the chain of thought is now a refusal. Sonnet 5.5 is the first Sonnet to launch with classifiers against reasoning extraction. A prompt that asks the model to reproduce its internal reasoning in the answer text gets a reasoning_extraction refusal. Tools that “show the model’s thinking” by prompting for it need to switch to display: "summarized".

There is also good news for anyone running agents in containers. On Anthropic’s containment evaluations, Sonnet 5.5 came close to Opus 5.5 in how rarely it tries to escape its sandbox and was the least likely of any of their models to probe the limits of its containers. That’s a useful property, not a guarantee — recent incidents with autonomous agents are why the boundary still belongs in your infrastructure, not in the model.

Which One Should You Use?

Sonnet 5.5 at medium — your new default for agentic coding on well-scoped tasks, bug fixes, terminal work, CI jobs, computer use, and documents or slides. This is where the benchmark gap is smallest and the cost gap largest.
Sonnet 5.5 at low or with between_tools — chat and latency-sensitive work. For high-volume classification and extraction, a small decision model or the announced Haiku 5.5 will be cheaper still.
Opus 5.5 — ambiguous, long-horizon or open-ended work, architecture decisions, large refactors, and anything where a wrong answer costs more than the tokens. Its default medium effort is already a reasonable starting point.
Sonnet 5.5 at xhigh or max — only when your own evals prove it. Cost converges on Opus, and FrontierCode shows max effort can score lower than xhigh.
Both — route per conversation, escalate through a summary or the advisor tool, and log input_transformations so you see every dropped block.

If you use these models through a coding agent rather than the API, the same choice shows up in /model and /effort. The agent side of that trade-off is in how AI coding agents like Claude Code, Codex and opencode actually work, and what the agent may do once it has picked a model is in Claude Code’s permission modes compared.

The Bottom Line

Sonnet 5.5 is the rare release where the cheaper model is the default answer. It matches Opus 5.5 within a couple of points on most of what Anthropic measured, beats it on terminal-based agent work, and costs half the list price — with a real per-turn gap closer to 1.65× once cache reads are counted.

But the cheapest architecture is not “Sonnet for easy turns, Opus for hard turns”. These two models don’t share their reasoning, the API won’t tell you when it drops it, and on new accounts an edited history is a hard error. Pick the model per conversation, keep that conversation append-only, and let Opus in through a fresh start or the advisor tool — not through the middle of a thought.

Originally published at alekseialeinikov.com