Wie ein Produktions-AI-Agent durch den Wechsel auf GPT-5.6 2,2-mal schneller und 27 % günstiger wurde

 (ploy.ai)
1 Punkte von GN⁺ 7 시간 전 | 1 Kommentare | Auf WhatsApp teilen
  • Ploy stellte seinen Agenten, der Produktions-Marketing-Websites plant, baut und validiert, von Claude Opus 4.8 auf GPT-5.6 Sol um und machte ihn zum Standardmodell für alle Workspaces
  • Nachdem modellspezifische Annahmen im Evaluierungs-Harness korrigiert wurden, sank die durchschnittliche Laufzeit beim Neuaufbau einer Homepage von 8 Minuten auf 3 Minuten 42 Sekunden, die Kosten fielen um 27 % von 3,06 $ auf 2,22 $, und der visuelle Score stieg auf 0,970
  • GPT-5.6 füllte alle 25 optionalen Parameter von Tool-Aufrufen mit beliebigen Werten, wodurch 52–64 % der Dateilesevorgänge leere Ergebnisse zurückgaben; nachdem optionale Felder zu required und nullable geändert wurden, sanken leere Lesevorgänge auf 0 %, und die Tool-Aufrufe gingen um etwa 30 % zurück
  • Wegen Unterschieden in Cache-Umfang und Durchsatzstruktur zwischen OpenAI und Anthropic wurde GPT-5.6 anfangs als rund 50 % teurer gemessen; mit Cache-Keys pro Workspace und Breakpoints pro Ebene stieg die Trefferquote beim ersten Aufruf von 0 % auf 83,7 %, und nicht gecachte Input-Tokens sanken um 28 %
  • Kosten und Leistung eines Modellwechsels hängen nicht nur vom Modell selbst ab, sondern auch von Evaluierungsbudgets, Tool-Schemas, Cache-Struktur und der Wiedergabe von Reasoning; für verlässliche Vergleiche und stabilen Betrieb müssen daher zuerst providerspezifische Annahmen gefunden und korrigiert werden, die auf das bisherige Modell zugeschnitten sind

GPT-5.6 Sol als Ersatz für Claude Opus

  • Der Ploy-Agent plant Seiten von Produktions-Marketing-Websites, liest die Codebase, erzeugt Komponenten und Bilder, überprüft die Ergebnisse per Screenshot und entscheidet anschließend, ob die Aufgabe abgeschlossen ist
  • Über mehrere Monate erfüllte kein Modell die Kriterien, um Claude Opus zu ersetzen; das Standardmodell blieb vier Monate lang nacheinander Opus 4.7 und 4.8
  • GPT-5.6 Sol übertraf Opus erstmals in einer direkten Evaluation mit denselben Aufgaben und wurde zum Standardmodell für alle Ploy-Workspaces
  • Schon in der ersten Evaluation lag die Laufzeit abgeschlossener Builds bei weniger als der Hälfte, die Kosten waren 27 % niedriger, und die Scores waren gleich hoch oder höher als beim bisherigen Modell – genug Grundlage für die Migration
  • Ploy nutzt das Vercel AI SDK, stellte beim Modellwechsel jedoch fest, dass im gesamten Stack providerspezifische Annahmen zu Tool-Argumenten, Prompt-Caching und der Wiedergabe von Reasoning zwischen Turns verblieben waren
  • Die Migration erfolgte schrittweise durch Anpassungen am Evaluierungs-Harness, an Tool-Schemas, am Prompt-Caching und an der Reasoning-Wiedergabe

Vor Vertrauen in Evaluierungszahlen erst das Harness korrigieren

  • Die Evaluierungssuite führt den Produktionsagenten in festen Test-Workspaces aus und deckt Hunderte Fälle ab – vom vollständigen Neuaufbau einer Homepage bis zur Einschätzung, ob eine Klon-Anfrage sicher ausgeführt werden kann
  • In Build-Fällen führt ein visueller Judge 10 binäre Prüfungen gegen ein Referenzdesign aus
    • Er prüft, ob der Hero-Bereich eine Fotoszene ist, die die gesamte Bildschirmbreite ausfüllt
    • Er prüft, ob die primäre CTA ein Rechteck mit abgerundeten Ecken ist und keine pillenförmige Schaltfläche
  • Zusätzlich werden Inhaltsprüfungen, Prüfungen von Tool-Ausführungspfaden und Datei-Assertions durchgeführt; bei Fehlschlägen wird der vollständige Ausführungstrace einschließlich Tool-Aufrufen und Modelltext geprüft

  • Aufrufbeschränkungen, die auf das bisherige Modell zugeschnitten waren

    • Das bisherige Budget für Tool-Aufrufe war auf die sequenzielle Aufrufweise von Opus ausgelegt, während GPT-5.6 parallele Aufrufe nutzt und selbst in korrekt gelösten Fällen das Budget überschritt
    • Der Evaluierungs-Runner unterstützte kein Batch-Lesen von Dateien, das Opus kaum nutzte, GPT-5.6 aber häufig einsetzt
    • Etwa ein Drittel der Rohfehler im ersten Lauf stammte nicht aus dem Modellverhalten, sondern aus Annahmen des Harness, und diese Fehler waren auch nicht gleichmäßig über Modelle verteilt
    • Wenn man die Ausführungstraces von Herausforderermodell und bisherigem Modell nicht zuerst klassifiziert, begünstigt die Evaluation ein neues Modell umso stärker, je mehr es sich wie das alte Modell verhält

  • Implizite Score-Schwellenwerte

    • Datensätze ohne minScore erbten ohne Warnung den Standardwert 1.0
    • Dadurch wurde GPT-5.6 trotz eines Hero-Scores von 0,98 als fehlgeschlagen gewertet, und auch Opus wurde in einem Fall als fehlgeschlagen bewertet, obwohl alle Einzelprüfungen bestanden waren
    • Beide Ergebnisse waren vertretbare Designs, scheiterten aber nicht am Modell, sondern an impliziten Schwellenwerten

Ergebnisse des korrigierten Benchmarks

  • Nach der Korrektur des Harness wurde die Evaluierungssuite erneut ausgeführt, die eine Marken-Homepage passend zum Referenzdesign neu aufbaut
Durchschnitt pro abgeschlossenem Build Claude Opus 4.8 (n=11) GPT-5.6 (n=10)
Kosten 3,06 $ 2,22 $
Laufzeit 8 Min. 00 Sek. 3 Min. 42 Sek.
Input-Tokens 2,6 Mio. 1,7 Mio.
Output-Tokens 33.000 17.100
Visueller Score 0,936 0,970
  • GPT-5.6 stellte die Seite 2,2-mal schneller fertig, kostete 27 % weniger und verwendete nur etwa die Hälfte der Output-Tokens
  • Auch die Menge des erzeugten Codes war geringer
    • In einem Vergleichspaar erzeugte Opus 174 CSS-Variablen und eine globals.css mit 17.957 Zeichen, einschließlich weitgehend ungenutzter Farbpaletten
    • GPT-5.6 nutzte 45 CSS-Variablen und 2.508 Zeichen und lieferte dennoch ein ähnliches oder besseres Rendering-Ergebnis

  • Designqualität und Konsistenz

    • GPT-5.6 ist stark bei sauberen, eng gerasterten Layouts, tendiert aber ohne deutliche Steuerung dazu, auf diesen Stil zu konvergieren
    • Im bestehenden, für Opus 4.8 entworfenen Harness erzeugte es häufig saubere, aber generische Ergebnisse, die das bestehende Designsystem ignorierten
    • Nachdem Design- und Engineering-Team die Modellsteuerung verbessert hatten, erfüllte es die für die Produktion nötigen Anforderungen an Brand-Compliance

Umgang mit optionalen Parametern in Tool-Aufrufen

  • Das code-Tool des Agenten hat 25 Top-Level-Parameter; nur action ist erforderlich, der Rest ist optional
  • Claude sendet nur die 2–3 genutzten Parameter, GPT-5.6 dagegen sendet bei jedem Aufruf alle 25 und füllt auch ungenutzte Felder mit plausiblen Werten wie offset: 0, timeout: 120000, siteId: "00000000-0000-0000-0000-000000000000"
  • Dasselbe Muster zeigte sich in über drei Tage gesammelten Produktions-Traces von code(read)
Modell Aufrufe Aufrufe mit allen 25 Eigenschaften
gpt-5.6 6.635 6.635, 100 %
claude-opus-4.8 2.898 4, 0,1 %
claude-sonnet-5 1.933 0

  • Ursache für leere Dateilesevorgänge

    • Das Problem war nicht einfach, dass die Argumente ausführlich waren, sondern dass die Implementierung des Dateilesens nicht zwischen vom Modell frei erfundenen Werten und vom Nutzer beabsichtigten Werten unterscheiden konnte
    • Die Implementierung behandelte offset: 0 als echtes Argument, und 52–64 % der Dateilesevorgänge von GPT-5.6 gaben leere Ergebnisse zurück
    • Das Tool gab sowohl für gültige Lesevorgänge als auch für leere Lesevorgänge success: true zurück, sodass das Modell nicht erkennen konnte, dass es leere Dateien las
    • Um die leeren Ergebnisse auszugleichen, führte es mehr Aufrufe aus, was zusätzlich die Ergebnisqualität verschlechterte

  • Durch Prompts und Strict Mode nicht gelöst

    • Selbst Hinweise in der Tool-Beschreibung, ungenutzte Parameter wegzulassen, führten weiterhin zur Erzeugung aller 25 Parameter
    • Auch OPTIONAL, omit if unused an jeder Eigenschaft änderte das Verhalten nicht
    • Der strict-Modus von OpenAI lieferte dasselbe Ergebnis; seine Einführung hätte erfordert, in allen Schemas pattern, format und Prüfungen der Array-Größe zu entfernen
    • Da dieses Verhalten daraus entsteht, wie das Modell Function Calling erzeugt, wurde statt des Prompts das Schema geändert

  • Schema-Transformation an der Provider-Grenze

    • Für OpenAI-Modelle werden alle optionalen Eigenschaften als required und nullable in der Form anyOf: [T, null] umgeschrieben
    • Das Modell füllt ungenutzte Parameter mit explizitem null, und an der Grenze des gemeinsam genutzten Tool-Aufrufs wird null vor der Validierung entfernt
    • Die Tool-Implementierung bleibt unverändert; nur das modellseitige Schema kann nun ungenutzte Werte ausdrücken
    // Vor der Änderung: alle 25 Keys werden mit beliebigen Werten gefüllt
{ "action": "read", "file_paths": ["..."], "offset": 0, "timeout": 120000 }

// Nach der Änderung: 4 echte Werte und 21 null-Werte werden gesendet; vor der Tool-Ausführung wird null entfernt
{ "action": "read", "file_paths": ["..."], "offset": null, "timeout": null }
    • Nach der Änderung fielen leere Dateilesevorgänge von 52 % auf 0 %
    • Auch die Zahl der für dieselbe Aufgabe nötigen Tool-Aufrufe sank um etwa 30 %, weil wiederholtes Lesen leerer Ergebnisse verschwand

Prompt-Caching nach OpenAI-Art

  • Beide Provider bieten Prompt-Caching an, unterscheiden sich aber in der Implementierung
  • Bevor dieser Unterschied berücksichtigt wurde, wirkte GPT-5.6 rund 50 % teurer als Opus; Ursache war jedoch nicht der Modellpreis, sondern die Cache-Konfiguration

  • Organisationsweiter Cache bei Anthropic

    • Der Agenten-Prompt beginnt mit einem etwa 29.000 Tokens langen statischen Präfix aus Tool-Schema und zentralem System-Prompt, der in allen Gesprächen identisch ist
    • Bei Claude werden Cache-Breakpoints mit cache_control markiert, und das Präfix wird organisationsweit geteilt
    • Ein Gespräch aus beliebigen Workspaces kann denselben geteilten Eintrag nutzen, und es gibt kein Durchsatzlimit pro Key
    • Die Cache-Trefferquote liegt bei 92–96 %

  • Geändertes Cache-Verhalten bei GPT-5.6

    • Frühere GPT-Modelle cached implizit teilweise Präfix-Übereinstimmungen, GPT-5.6 hat teilweises Präfix-Matching entfernt
    • Der implizite Cache erstellt vollständige Prompt-Einträge auf Basis der neuesten Nachricht; daher haben neue Gespräche, die dasselbe statische Präfix von 29.000 Tokens teilen, beim ersten Aufruf trotzdem eine Cache-Trefferquote von 0 %
    • Dadurch wird der gesamte Präfix für jedes Gespräch erneut zum nicht gecachten Tarif abgerechnet
    • Unabhängig davon, ob die Anwendung Caching nutzt, erhebt GPT-5.6 auf alle nicht gecachten Prompts einen 1,25-fachen Cache-Write-Aufschlag

  • Einschränkungen expliziter Cache-Keys

    • Explizites Caching erfordert prompt_cache_breakpoint und den obligatorischen prompt_cache_key
    • Der Key gehört ebenfalls zur Cache-Identität; derselbe Prompt trifft also nicht, wenn der Key anders ist
    • Jeder Key wird auf einen Cache-Knoten abgebildet, der etwa 15 Requests pro Minute verarbeitet; darüber hinaus verteilt OpenAI Traffic auf andere Knoten mit eigenständigen kalten Caches
    • Deshalb ist die Wahl der Einheit für Keys eine zentrale Designentscheidung
    • Key pro Gespräch: Neue Gespräche trafen den gemeinsamen Präfix nicht, die Trefferquote beim ersten Aufruf lag bei 0 %
    • Ein globaler Key: Alle Requests werden auf einen Knoten gehasht, und wenn Produktions-Traffic 15 rpm überschreitet, läuft er auf kalte Knoten über
    • Key pro Workspace: Alle Gespräche eines Kunden-Workspaces teilen Einträge, während der Traffic pro Key niedrig bleibt

  • Hierarchischer Cache pro Workspace

    • Die tatsächliche Konfiguration nutzt einen workspaceweiten Key der Form ws:{workspaceId} und teilt den System-Prompt in Breakpoint-Ebenen
    • Eintrag A enthält Tools und statischen Präfix und senkt die Kosten des ersten Aufrufs einer Session
    • Eintrag B ergänzt den statischen Präfix um den Workspace-Kontext
    • Eintrag C ist die vollständige sessionspezifische Prompt-Kette vom ersten Turn bis zur neuesten Nachricht
    • Wenn sich der Workspace-Speicher ändert, verfehlt Eintrag B, aber Eintrag A trifft weiter; neu geschrieben wird nur die Größe des geänderten Kontexts, nicht der gesamte Präfix von 29.000 Tokens
    • Eintrag C nutzt innerhalb der Session die implizite vollständige Prompt-Kette von OpenAI, da der Prompt eine streng append-only Struktur hat
    • Wegen OpenAIs Key-Partitionierung kann der statische Präfix nicht zwischen Workspaces geteilt werden
    • Anthropic hingegen nutzt einen organisationsweiten Cache ohne Key-Partitionierung und kann den Präfix teilen
    • Bei GPT-5.6 schreibt jeder Workspace pro Leerlauf-Zeitfenster einmal die 29.000 Tokens kalt; die Kosten betragen etwa 0,18 $
    • Diese Kosten sind begrenzt und vorhersehbar

  • Ergebnis der Cache-Korrekturen

    • Die Trefferquote beim ersten Aufruf stieg von etwa 0 % auf 83,7 %
    • Die gesamten nicht gecachten Input-Tokens sanken um 28 %
    • Die Kosten von GPT-5.6 pro Evaluierungssuite lagen nun unter denen von Opus; die gesamte anfängliche Kostendifferenz stammte aus falscher Cache-Konfiguration
    • Kostenvergleiche zwischen Modellen sind nicht valide, wenn nur ein Modell mit kaltem Cache startet

Reasoning-Wiedergabe auf selbstständig vollständige Form umstellen

  • Die GPT-5.6 Responses API gibt das Reasoning früherer Turns standardmäßig über serverseitige Item-Referenzen wieder; in Produktionsgesprächen trat sporadisch der Fehler Item 'rs_...' not found auf
  • Mit store: false fordert das SDK verschlüsselte Reasoning-Inhalte an und spielt statt eines Zeigers auf Serverzustand einen selbstständig vollständigen Blob wieder
  • Selbst wenn die von der Anwendung gesendeten Bytes eine append-only Struktur haben, kann serverseitiger Reasoning-Zustand den effektiven Prompt verändern
  • GPT-5.6 Sol läuft nach Korrekturen an Evaluierungs-Harness, Tool-Schemas, Prompt-Cache und Reasoning-Wiedergabe als Produktions-Standardmodell von Ploy

Verwandte Beiträge

1 Kommentare

 
GN⁺ 7 시간 전
Meinungen auf Hacker News

  • Formulierungen wie „Bei solchen Zahlen lohnt es sich, das Modell tatsächlich zu migrieren“ sind einfach lächerlich. Es wäre schön gewesen, wenn die Person, die den Text schreiben ließ, wenigstens den typischen LLM-Stil geglättet hätte.
    Auch diese Art, kurze Satzteile mit Doppelpunkten, Kommas und Punkten aneinanderzureihen, ist miserabel und ermüdend. Es gibt gute Einsichten, etwa dass der Cache für partielle Präfix-Übereinstimmungen in GPT-5.6 verschwunden ist, aber angenehm zu lesen ist der Text nicht.

    • Deshalb liegt neben AGENTS.md oder CLAUDE.md bei mir immer eine WRITING.md. Die meisten sagen dem Modell nur, was es bauen soll, aber kaum, wie es schreiben soll; dabei folgen LLMs expliziten Stilvorgaben erstaunlich gut.
      Ich schreibe Regeln auf, um unnötige Doppelpunkte, lange Gedankenstriche, als Betonung getarnte Satzfragmente und Grammatikfehler zu vermeiden, die mir häufig passieren. Außerdem nenne ich Brian Kernighan und Rob Pike als Referenz für technische Texte, die klar, dialogisch und frei von Gehabe sind. Dokumentation sollte nicht nur leicht zu lesen sein, sondern so geschrieben sein, dass man sie lesen möchte.
      Wenn man häufig Dokumentation erzeugt, lohnt es sich sehr, den Agenten auf WRITING.md verweisen zu lassen. Die Lesbarkeit verbessert sich oft viel stärker als durch den Wechsel auf ein neueres Modell, und auch bei einem Modellwechsel bleibt der Stil konsistent.
    • Gerade bei einer AI-Firma wirkt das besonders schlecht. Es kann nur bedeuten, dass sie Modelle nicht genug nutzen, um den typischen Stil zu kennen, oder nicht begreifen, dass das wichtig ist, oder die Gesamtsituation nicht verstehen, oder ihre Leser nicht respektieren. Keine dieser Möglichkeiten ist gut.
    • Du liest falsch. Lass ein LLM den Text nach deinen Stilvorlieben lesen und zusammenfassen. Noch besser: Lies überhaupt nichts selbst, sondern lass es von einem Agenten in eine Skill-Datei umwandeln, auf die er später zurückgreifen kann.
    • Wenn ich vermute, dass ein Text von einem LLM geschrieben wurde, höre ich sofort auf zu lesen und lasse ihn von meinem LLM-Tool zusammenfassen oder umschreiben. Dann habe ich zumindest den Ausgabestil einigermaßen unter Kontrolle.
    • In meiner aktuellen claude.md habe ich den Ausdruck „load-bearing“ verboten, und Claude hasst das wirklich. Manchmal macht es sich in Kommentaren mit Dingen wie „load-be…most specific“ darüber lustig, so sehr liebt es diesen Ausdruck.

  • Ich habe verschiedene kleine und einfache Workflows, die früher auf 5.4-nano und mini liefen, auf 5.6 umgestellt. Insgesamt lagen die Verbesserungen in dem Bereich, den der Artikel beschreibt, und bei einigen Klassifizierungsaufgaben wurde auch die Qualität besser.
    In vielen Unternehmen ist so ein Modell-Upgrade tatsächlich eine Ein-Zeilen-Änderung im Code. Für zentrale Workflows verwenden wir eine hervorragende Model-Router-Architektur, aber für einfache Aufgaben lohnt sich dieser Aufbau nicht; außerdem muss man Stabilitätsfragen berücksichtigen.

    • Der Kern dieses Artikels ist, dass das Modell-Upgrade keine Ein-Zeilen-Änderung war.
    • Welches SDK nutzt ihr? Oder ist das eine Eigenentwicklung?
    • Der ursprüngliche Zweck von Sol war, 5.6 in unseren Workflows zu evaluieren. Zuvor war die Qualität der einfachen Modelle nicht ausreichend, deshalb haben wir für alles 5.5 genutzt. Jetzt analysieren wir Text und Bilder gemeinsam, um aus chaotischen Quelldaten explizite und implizite strukturierte Daten zu extrahieren.
      Im Großen und Ganzen funktioniert es wie beworben. Indem wir den Großteil unserer aktuellen Arbeit an terra schicken, haben sich die Kosten halbiert und die Antwortzeiten um 50 % verbessert. luna verwenden wir als Ergänzung zu OpenCV-Erkennungsergebnissen; der Funktionsumfang ist sehr begrenzt, aber es ist schnell und praktisch fast kostenlos. Sol war bei unseren Aufgaben nur ein wenig besser als terra.
      Sol ultra hat auch die Evaluation selbst hervorragend erledigt. Es erzeugte umfangreiches Material mit sinnvollen Empfehlungen sowie Listen von Ausgaben, die man manuell prüfen und vergleichen sollte, Roh- und verarbeiteten Daten und CPM pro Query. Abgesehen vom Pro-Abo haben wir nichts zusätzlich ausgegeben, und nach ein paar Stunden Laufzeit lagen die Kosten-Benchmarks 50 % niedriger und der Durchsatz 100 % höher.

  • Meine Erfahrung ist ähnlich. Dienste, die wie OpenRouter mit Failover werben, sind außerhalb von Sandbox-Tests fast nutzlos. Produktionsmodelle sind in der Praxis nicht wirklich austauschbar, und Laufzeitumgebungen, die ernsthafte Agentenarbeit ausführen, hängen von viel mehr modellspezifischen Eigenheiten ab, als man erwartet.
    Selbst wenn ein anderes Modell fehlerfrei funktioniert, sind Leistung und Effizienz eine andere Sache. Bei manchen Modellen, etwa aus der Claude-Familie, muss man System-Prompts an Ausdrucksweisen anpassen, die ihnen aus dem Training vertraut sind; andere Modelle funktionieren mit anderen Trennzeichen besser. Wenn optimale Leistung wichtig ist, muss man Laufzeitumgebung, Prompt und Modell als ein System betrachten und darf nicht glauben, man könne die Teile beliebig austauschen.

    • Als Teil von LLMOps sollte man einen Failover-Plan aufbauen, der Tool-Ausführungspfade und Ähnliches sauber prüft. Dann kann man ausreichend gute Modelle in der Reihenfolge von günstig nach teuer anordnen und das gewünschte Failover umsetzen.
      Ich habe auch schon Zuordnungstabellen der Form model -> {{prompts}, {tools descriptions}, ...} gesehen, aber das ist zu extrem. Ab einem gewissen Punkt muss sich das Modell an unsere Prompts anpassen; Modelle, die das nicht können, sollte man aus den Failover-Kandidaten streichen und ihnen keine API-Requests schicken.
    • OpenRouter macht kein Failover auf ein anderes Modell, sondern wechselt zu einem anderen Anbieter, der dasselbe Modell bereitstellt.

  • Es ist ironisch, dass unter einem Artikel voller tiefgehender Infrastruktur-Einsichten die Hälfte der Kommentare nur den gekünstelten Stil kritisiert. Selbst wenn Claude beim Glätten der Sätze geholfen hat: Wenn der Text einen sofort nutzbaren Bauplan enthält, um 30 % des API-Budgets einzusparen und leere Datei-Lesevorgänge zu beheben, ist das nicht wichtiger?

    • Es gibt sicher Leute, die alles mit AI-Bezug hassen und deshalb nach Haaren in der Suppe suchen, aber andere können diesen Stil vielleicht wirklich nicht ertragen und fixieren sich deshalb darauf.
      Persönlich finde ich es albern, über den Stil zu meckern. Vielleicht liegt es daran, dass ich schwach in Grammatik und Rechtschreibung bin, aber ich konzentriere mich eher auf den Kerninhalt wie Konzepte, Fakten und Argumente als auf die Darreichungsform. Grammatik und Rechtschreibung sind nur die Bäume; der Wald ist das Entscheidende.
      Dass meine Texte nicht voller Fehler sind, verdanke ich Diktat und selbstgebauten Shortcuts. Markierten Text lasse ich von einem lokalen LLM korrigieren und dann ersetzen; nichts hat meine Lebensqualität und die Qualität meines Schreibens so sehr verbessert wie diese beiden Tools.

  • „Ab heute verwendet der Ploy-Agent GPT-5.6 Sol, das heute Morgen veröffentlicht wurde“ – wurde also nach gerade einmal einem halben Tag Tests umgestellt? Wird das Unternehmen von Teenagern geführt?

    • Tatsächlich ähnelt die Mitarbeiterstruktur eher Staff- und Senior-Staff-Leveln. Über YC-Beziehungen wurde das Preview-Modell GPT-5.6 etwa eine Woche lang getestet und Feedback gegeben
      Die Evaluationsaufgaben laufen in GitHub CI, und ein Evaluationsset mit über 115 Webdesign- und Marketing-Aufgaben, auf die ploy.ai spezialisiert ist, lässt sich in etwa 15 Minuten vollständig ausführen. Nachdem das Modell per PostHog-Feature-Flag aktiviert wurde, wurden Fehlschläge aktiv überwacht
      Man versucht, möglichst viel Wissen aus dem Betrieb von Webflow, das mehr als 1 % des Internets unterstützt, in Ploy zu übertragen, um einen größeren Teil des Internets zu unterstützen
    • Es ist gut möglich, dass sie in gewissem Umfang Vorabzugang erhalten haben, um Evaluierungen durchführen zu können, die einen solchen Beitrag ermöglichen
    • Inzwischen ist es ziemlich einfach, Evaluierungen und Benchmarks zu erstellen und sie auf den neuesten Modellen laufen zu lassen. LLMs lassen sich leicht austauschen, daher ist ein gutes Evaluationsset sehr nützlich, und manchmal ist die Verbesserung so eindeutig, dass nicht einmal eine Evaluierung nötig ist
    • Ich würde erwarten, dass sie über einen produktionsbasierten Datensatz verfügen, mit dem sie neue Modelle vergleichen können

  • Der Ploy-Agent erstellt und bearbeitet zwar echte Marketing-Websites, übernimmt Planung, liest Codebases, schreibt Komponenten, generiert Bilder, macht Screenshots seiner eigenen Ergebnisse und entscheidet, ob er fertig ist; dennoch würde ich selbst ohne strenge Tests erwarten, dass Fable bei der Erstellung von Marketing-Sites deutlich besser ist als Opus. Beim Erstellen von Präsentationsmaterial ist es definitiv deutlich besser

    • Beim Design ist GPT-5.6 deutlich besser als Fable
    • 4.7 neigt dazu, Anweisungen übermäßig wörtlich zu befolgen, daher ist das Ergebnis im Original durchaus plausibel

  • Die Lösung, nur bei OpenAI-Modellen alle optionalen Eigenschaften verpflichtend zu machen und zugleich mit anyOf: [T, null] null zu erlauben, riecht irgendwie falsch. Ich habe zwar nur eine abgewandelte Form von MCP verwendet, aber es ist nicht klar, warum TypeScript-Typdefinitionen das JSON Schema beeinflussen sollten, das vom Agenten an das Inferenz-Backend gesendet wird
    In der MCP-Spezifikation gibt es explizit ein Feld zur Darstellung optionaler Parameter, daher scheint irgendwo zwischen der TypeScript-Schicht und der tatsächlich übertragenen Tool-Beschreibung ein Bug zu liegen. Es könnte sein, dass sich das Inferenz-Backend von „eine gültige Tool-Antwort erzeugen“ zu „eine gültige Antwort gemäß einem JSON Schema ohne optionale Parameter erzeugen“ geändert hat, aber ohne die tatsächliche Anfrage zu sehen, lässt sich das nicht beurteilen

    • Das ist kein Bug in der Schema-Generierung oder in TypeScript, sondern internes Verhalten von OpenAI Function Calling. Die für Tool-Nutzung feinabgestimmten Gewichte versuchen, möglichst vollständige Datenstrukturen auszugeben. Wenn das Modell im Kontext des System-Prompts Parameternamen sieht, versucht es, Werte dafür zu füllen, auch wenn sie nicht im required-Array stehen
    • Aktuelle Frontier-Modelle, darunter Fable, Opus und 5.6, sind bei Tool Calls ziemlich locker und halten sich oft nicht exakt an das Schema. Ein Beispiel, in dem Claude-Modelle bei Pis Edit-/Replace-Tool-Calls nicht existierende Eigenschaften erfinden, findet sich unter https://lucumr.pocoo.org/about/
      Ein Teil der Ursache scheint damit zusammenzuhängen, dass Constrained Decoding die Intelligenz verringert. Die Schema-Gültigkeit wird zwar garantiert, aber die Fähigkeiten fallen stark ab; für Klassifikation, Zusammenfassung und Prompt-Verbesserung ist das in Ordnung, bei iterativen Agentenläufen sollte man jedoch vorsichtig sein
      Laufzeitumgebungen wie Claude Code machen viel Preprocessing, Recovery und Cleanup, aber das wird normalerweise nicht sichtbar. Anstatt perfekte Genauigkeit anzunehmen und zu erzwingen, ist es in der Praxis einfacher und besser, die Laufzeitumgebung lockerer zu gestalten und an die Eigenheiten der jeweiligen Modelle anzupassen. Die Modelle ändern sich ohnehin alle ein bis zwei Monate. Das ist angewandte KI, die nach Gefühl gebaut wird

  • Ich würde gern die grobe Größenordnung der tatsächlichen Kosten wissen, wenn man mit Opus beziehungsweise Sol eine Website erstellt

  • Nachdem wir den Workflow auf Reasonix umgestellt und bei DeepSeek Cache-Hits genutzt haben, sind die Anfragekosten selbst bei einem nicht subventionierten US-Anbieter praktisch fast kostenlos geworden

    • Welche Konfiguration verwendest du, und wie ist sie im Vergleich zu Pi?

  • Statt GPT-5.6 Sol standardmäßig für alle Ploy-Workspaces zu verwenden, könnte man für einige Aufgaben, die tatsächliche Tools bedienen, Luna in Betracht ziehen. Es ist erstaunlich fähig und schnell
    Sol ist hervorragend darin, mit Menschen zu sprechen und Agentenaufrufe zu koordinieren, aber es ist zu teuer, um es für alles zu verwenden. Für den Preis eines Sol-Laufs kann man Luna fünfmal ausführen, und statistisch ist der Unterschied zwischen einer und fünf Stichproben erheblich

    • Wenn jeder Schritt eines Luna-Laufs mit 90 % Wahrscheinlichkeit richtig ist, beträgt die Wahrscheinlichkeit, dass alle fünf Schritte richtig sind, 0.9^5 = 0.59, also 59 %. Die Genauigkeit eines einzelnen Sol-Laufs könnte etwa 95 % betragen. Die tatsächlichen Werte werden variieren, aber am Ende mit Sol zu verifizieren, könnte günstiger sein
    • Bei Sub-Agenten gibt es immer das Problem, dass sie voneinander isoliert sind. Das hat den Vorteil, dass der Kontext klein bleibt und sie fokussiert arbeiten, aber um ihre Aufgabe weiterzuführen, müssen sie jeweils erneut recherchieren und verbrauchen dabei oft nicht gecachte Tokens
      Je nachdem, wie viele Agenten man für welche Aufgabe einsetzt, können die Kosten steigen, während die Ergebnisse sogar schlechter werden