Anthropic testet heimlich reduzierte Effort-Level in Claude Code
Anthropic appears to be A/B testing reduced effort levels in Claude Code
Ein Nutzer berichtet, dass Anthropic offenbar A/B-Tests mit reduzierten Effort-Leveln in Claude Code durchführt. Seit Version 2.1.237 wird "high" als 10 von 100 interpretiert – der Wert, den früher "low" hatte. Das Changelog erwähnt nichts davon. Betroffen sind nur bestimmte Sessions, ältere Versionen und Opus 5 bleiben unverändert. Der Nutzer vermutet, dass es sich um einen serverseitigen Test handelt, der nicht für alle sichtbar ist.
Seit 2.1.237 liest das Modell "high" als 10 von 100 – exakt die Zahl, die früher "low" bedeutete, und das Changelog verliert kein Wort darüber.
- pizzafeelsright
Was auch immer Opus 5 tut, sollte nicht passieren.
Die Aufforderung war "Lies die Konfigurationsdatei und aktualisiere sie mit neuen Daten". Diese Arbeit dauert mit 4.6 weniger als 2 Minuten, um die Datei zu lesen, die neuen Daten zu parsen und zu patchen.
Opus 5 Ergebnis: 43 Minuten, in denen Container gezogen, Sandboxes ausgeführt und Test-Suiten erstellt wurden, einschließlich der Bewertung des gesamten Repos über den Rahmen der Konfigurationsdatei hinaus.
Beide: eine Dateiänderung
- trq_
Hallo zusammen, ich bin Thariq vom Claude Code Team. Ich habe das auf Twitter gepostet, aber ich poste es hier nochmal:
Wir testen manchmal API-Serving-Konfigurationen in Claude Code, bevor wir sie ausrollen, und eine laufende Konfiguration bildet den numerischen Effort-Wert anders ab.
Deshalb kann es sein, dass Claude einigen von euch sagt, dass es bei "hoch" auf "10" steht. Die Skala ist nicht 0-100, die Zahl ist für sich genommen nicht aussagekräftig, und der Effort, den ihr ausgewählt habt, ist der Effort, den ihr bekommt. Wir haben umfangreiche Evaluierungen durchgeführt, um zu bestätigen, dass dies die Modellleistung nicht beeinträchtigt.
Das sollte die gleiche Erfahrung sein, aber wenn ihr eine deutliche Regression seht, nutzt bitte /feedback und schickt mir die ID. Ich gebe Credits.
- boredumb
Nicht speziell Anthropic, aber warum erlauben wir, dass die Abrechnung in Tokens erfolgt, die nebulös sind und vollständig von den Betreibern kontrolliert werden, die keine gleichgerichteten Anreize haben?
Wenn ich eine Benutzereingabe habe und diese bereinige und in einen Prompt einfüge, um etwas zu tun, habe ich keine Ahnung, wie viel das kosten wird, und keine wirkliche Möglichkeit, das richtig zu messen. Ein paralleles Beispiel ist Digital Ocean oder AWS: Ich kann meine Rechenleistung, Dateisystem, Speicher, Startzeiten usw. messen und begrenzen, und obwohl es unmöglich sein kann, bis auf den letzten Flop an Geld genau zu sein, kann ich Dinge mit einem echten Budget und echten Einschränkungen ausführen, im Gegensatz zu einem LLM, wo ich ... einen bereinigten Benutzer-Prompt durch einen Tokenizer laufen lassen und dann ein LLM bitten muss, zu erraten, was es tun könnte und Token-Verbrauchsschätzungen zu geben, und dann in einer vernünftigen Weise für den Benutzer darauf zu reagieren?
Vielleicht übersehe ich etwas, um realistische und statische Leitplanken zu haben, aber ich sehe keinen ernsthaften Weg, das Token-Abrechnungsmodell im großen Maßstab zu verwenden, um Dinge zu handhaben, die freie Texteingaben von Benutzern erfordern, außer zu VC-Geld zu betteln, um Geld darauf zu werfen, bis jemand anderes es herausfindet.
*Um mein Geschwafel zu verdeutlichen...
Wir sollten auf der Grundlage des Ressourcenverbrauchs selbst abgerechnet werden und Kontrollen erhalten, nicht über ein undurchsichtiges Token-Konzept, zusätzlich dazu, dass wir keine Knöpfe drehen können, die den Ressourcenverbrauch steuern.
- hpone91
Update von Thariq auf Twitter. https://x.com/trq212/status/2091247114869432543
"Wir testen manchmal API-Serving-Konfigurationen in Claude Code, bevor wir sie ausrollen, und eine laufende Konfiguration bildet den numerischen Effort-Wert anders ab.
Deshalb kann es sein, dass Claude einigen von euch sagt, dass es bei 'hoch' auf '10' steht. Die Skala ist nicht 0-100, die Zahl ist für sich genommen nicht aussagekräftig, und der Effort, den ihr ausgewählt habt, ist der Effort, den ihr bekommt. Wir haben umfangreiche Evaluierungen durchgeführt, um zu bestätigen, dass dies die Modellleistung nicht beeinträchtigt.
Das sollte die gleiche Erfahrung sein, aber wenn ihr eine deutliche Regression seht, nutzt bitte /feedback und schickt mir die ID. Ich gebe Credits."
- monideas
Dieses Phänomen war mit Fable so schlimm und so auffällig, dass ich mein Max-Abo (200 $) auf Pro (20 $) herabgestuft habe. Es ist praktisch nutzlos. Codex 5.6 Sol ist tatsächlich sehr gut, ich werde einfach ein weiteres Konto erstellen, um mehr Nutzung zu bekommen.
- Insimwytim
LLM-Nutzer wollen keine Anstrengung investieren, also lagern sie Aufgaben an LLMs aus.
Das LLM scheint auch nicht besonders erpicht darauf zu sein, Anstrengung zu investieren!
Ist das AGI?
- N_Lens
Ich vermute, es ist nicht nur das, es gibt viele 'Optimierungen' rund um das Dehnen von Nutzungslimits sowie das Weiterleiten an ein anderes Modell im Backend. Die Anreize sind zu stark.
- ricardobeat
Ich nutze Opus 5 fast ausschließlich mit niedrigem Effort und erziele gute Ergebnisse. Besonders bei 'hoch' scheint es in völlig ungefragte Tangenten abzudriften. Das scheint auch für Sonnet 5 zu gelten. Ältere Modelle verhielten sich nicht so.
Der Stimmungswandel in nur sechs Monaten ist verrückt, im Februar dieses Jahres war Claude das mit Abstand beliebteste LLM.