Vor Jahren habe ich unseren Laravel-Scheduler so eingestellt, dass jeder Cleanup-Job aus der Queue einmal pro Minute läuft, weil CPU billig war und ich keine Lust hatte, mir zu überlegen, wie oft jeder davon wirklich gebraucht wird. Es hat acht Monate und eine sehr verwirrende Hosting-Rechnung gedauert, bis jemand fragte, warum ein Job, der abgelaufene Passwort-Reset-Tokens löscht, 1.440 Mal am Tag aufwacht. An diese Cron-Zeile muss ich ständig denken, während ich über Beam lese, das neue Open-Weight-Modell von Reflection. Denn das Feature, das mir aufgefallen ist, hat nichts damit zu tun, wie gründlich es nachdenken kann. Aufgefallen ist mir, dass du ihm sagen kannst, weniger nachzudenken.

Die Eckdaten sind beeindruckend, und sie haben ihren Auftritt verdient. Beam hat 501 Milliarden Parameter in einer Sparse-Mixture-of-Experts-Architektur, davon 23 Milliarden aktiv pro Token, 52 Layer und ein Kontextfenster, das im Midtraining auf 1 Million Tokens erweitert wurde. Reflection meldet 80,9 % auf SWE-Bench Verified, 80,1 % auf Terminal-Bench v2.1 und 78,7 % auf MCP Atlas und kündigt an, Weights, technische Berichte und Entwickler-Artefakte unter Apache 2.0 zu veröffentlichen. Für ein offenes Modell sind das ernstzunehmende Ergebnisse. Sie beschreiben allerdings eine Obergrenze, und die meisten von uns verbringen ihre Nachmittage nicht in der Nähe dieser Obergrenze.

Sei ehrlich: Was gibst du einem Coding-Agent an einem ganz normalen Dienstag? Eine Service-Klasse umbenennen und vierzig Aufrufstellen anpassen. Eine nullable Spalte hinzufügen und die Migration schreiben. Einen Legacy-Controller von PHPStan Level 5 auf Level 6 bringen, ohne das Verhalten zu ändern. Ein Blade-Partial in eine Komponente umbauen. Nichts davon erfordert, dass ein Modell zwölftausend Tokens lang abwägt, bevor es eine Datei anfasst, und trotzdem rechnet jeder Agent, den ich bisher laufen hatte, so ab, als würde er gerade seine Doktorarbeit verteidigen. Beam wurde mit einer steuerbaren Längenstrafe trainiert, und Reflection bietet einen Parameter für den Reasoning-Aufwand an, den du für Routinearbeit herunter- und für die kniffligen Sachen hochdrehen kannst. Laut Firma erreicht es bei anspruchsvollen Reasoning-Benchmarks das Niveau von GLM-5.2 und braucht dabei drei- bis viermal weniger Inferenz-Rechenleistung. Wenn das auch am unteren Ende der Skala stimmt, ändert sich, was die Erzeugung eines Pull Requests kostet.

Den stärksten Einwand teile ich selbst. Ein Regler nützt nur, wenn die unterste Stellung noch kompetent ist, und jede Zahl in der Ankündigung ist eine Schaufensterzahl. Ich habe noch niemanden gesehen, der veröffentlicht, was Beam auf SWE-Bench schafft, wenn der Aufwand ganz heruntergedreht ist, und solange das niemand tut, ist „knapp bei Routineaufgaben“ ein Versprechen ohne Zahl dahinter. Dazu kommt ein zweiter Einwand: 501 Milliarden Parameter selbst zu betreiben ist kein Wochenendprojekt, für die meisten PHP-Shops heißt „Open Weights“ also in Wahrheit „ein Hosting-Anbieter deiner Wahl“. Dein Laptop steht nicht auf der Liste. Beide Punkte sind berechtigt, und ich würde sie geklärt sehen wollen, bevor irgendwer seine CI rund um dieses Modell umbaut.

Trotzdem schlage ich mich auf die Seite des Reglers, und der Grund liegt darin, wie Reflection das Ding gebaut hat. Sie berichten von einem Pretraining-Lauf auf 6.144 NVIDIA GB300 NVL72 GPUs mit 92,3 % Goodput und nur neun halbautomatischen Rewinds, außerdem von einer RL-Phase auf 10,5K GB300s, die über 1,3 Milliarden Anfragen zur Sandbox-Erstellung in 170K parallelen Umgebungen angestoßen hat. Da ist ein Team am Werk, das im eigenen Haus ganz offensichtlich besessen von verschwendeten Zyklen ist. Ein Modell auszuliefern, dem man ebenfalls sagen kann, keine Zyklen zu verschwenden, passt zum selben Instinkt. Und genau diesen Instinkt musste unsere Ecke der Branche schon immer haben, weil wir diejenigen sind, die zehntausend kleine Requests auf bescheidenen Kisten laufen lassen, jede Stunde, über Jahre.

Für alle, die Tooling rund um PHP-Projekte bauen, hat das eine ganz praktische Folge. Wenn der Aufwand ein Parameter ist, gehört er in deine Config neben den Modellnamen, und er sollte je nach Aufgabentyp variieren. Ein mechanisches Refactoring im Rector-Stil und die Jagd nach einer Race Condition in einem Queue-Worker sollten sich keine Einstellung teilen, genauso wenig wie dein Cleanup-Job und dein nächtlicher Report sich einen Cron-Zeitplan teilen sollten. Reflection sagt außerdem, Beam habe sich Tool-Nutzung angeeignet, auf die es nicht explizit trainiert wurde, etwa das Durchsuchen von Dokumentation und Aufrufe von OCR-APIs. Das ist beeindruckend, heißt aber auch, dass ein großzügig konfigurierter Agent fröhlich losläuft und herumsurft, obwohl du ihn nur gebeten hast, einen Import zu reparieren. Eine niedrige Aufwandsstufe kann also nicht nur als Rabatt funktionieren, sondern auch als Leine.

Die Apache-2.0-Lizenz ist dabei wichtiger, als es vielleicht scheint. Mit einer permissiven Lizenz kann ein Hoster Beam zu einem Preis anbieten, der sich nach der angefragten Aufwandsstufe richtet, und eine Agentur, die ihren Kunden pro Projekt abrechnet, kann irgendwann über KI-Kosten so nachdenken wie über Serverkosten: in Requests und Minuten, mit einer Zeile in einer Tabelle. Das ist ein gesünderes Verhältnis, als für jeden trivialen Diff einen pauschalen Aufpreis für maximales Nachdenken zu zahlen und zu hoffen, dass die Rechnung höflich bleibt.

Deshalb würde mich deine Erfahrung wirklich interessieren. Wenn du schon Coding-Agents auf eine echte PHP-Codebasis loslässt: Wie viel dieser Arbeit braucht ehrlich gesagt tiefes Reasoning, und würdest du einem Modell auf der niedrigsten Aufwandsstufe zutrauen, eine Migration oder ein mechanisches Refactoring durchzubringen, ohne dass ein Mensch jede Zeile noch einmal liest? Wo würdest du die Grenze ziehen?