Factory Droid 1.0 im Test: Schlankerer Harness, gleiche Limits

Factory hat Droid 1.0 am 29. Oktober 2026 veröffentlicht. Die wichtigste Neuerung ist mehr Effizienz: Allein der Script-Modus senkte die Kosten mit Claude Opus 5.5 um 15 Prozent; im besten direkten Vergleich lag Factorys Harness 24 Prozent unter einem Konkurrenz-Harness. Für die Kaufentscheidung ist allerdings etwas anderes ausschlaggebend: Die rollierenden Nutzungslimits bleiben bestehen – ebenso wie der zusätzliche Prüfaufwand, den ein schnellerer Harness erzeugen kann.

Was Factory Droid 1.0 tatsächlich liefert

Factory Droid 1.0 ist eine neue Harness-Version, kein neues Basismodell. Factory Droid bleibt ein modellunabhängiger Coding-Agent, der Drittanbieter- und Open-Source-Modelle mit eigenen Prompts, Tools, Ergebnisverarbeitung und einer Ausführungsschleife ergänzt. Version 1.0 verändert vor allem diese Schleife.

Droid 1.0 läuft auf dem Desktop, in der Terminal-CLI und über das SDK. Derselbe Agent ist außerdem im Web, in Slack, Microsoft Teams, Linear, Jira sowie über das für Skripte und CI gedachte, headless ausführbare droid exec verfügbar. Factory führt den Script-Modus – so nennt das Unternehmen programmatische Tool-Aufrufe – für GPT-6.1 Sol, GPT-6.1 Terra, GPT-6 Astra, GPT-6 Sol, GPT-5.6 Sol, Claude Fable 5.1, Claude Fable 5, Claude Opus 5.5, Claude Opus 5 und Kimi K3 als standardmäßig aktiviert.

Bei der Modellwahl bleibt man flexibel. Nutzer können ein Modell ausdrücklich auswählen, Factory Router die Auswahl überlassen oder per BYOK eigene Schlüssel und lokale Endpunkte wie Ollama, LM Studio und vLLM einbinden.

So funktionieren programmatische Tool-Aufrufe in der Praxis

Bei programmatischen Tool-Aufrufen schreibt das Modell ein JavaScript-Programm, statt die Tools nacheinander einzeln aufzurufen. Dieses Programm läuft in einer Sandbox ohne eigenen Datei-, Netzwerk- oder Systemzugriff, verwendet die Tools als Variablen, filtert Ergebnisse und arbeitet Schleifen deterministisch ab. An den Modellkontext wird anschließend nur die ausgewählte Ausgabe zurückgegeben.

In herkömmlichen Agent-Schleifen werden die unverarbeiteten Ergebnisse nach jedem einzelnen Aufruf wieder an den Kontext angehängt. Der Script-Modus filtert sie vorher im Code. Dadurch werden Anweisungen nur einmal übertragen, hunderte Tool-Aufrufe in einer Modellanfrage gebündelt und ausgegebene Datenmengen begrenzt.

Zwei Beispiele aus Factorys Forschungsbeitrag zum Frontier-Harness vom 29. Oktober 2026 zeigen das Prinzip:

Factory spielte außerdem die Behebung eines Unit-Tests mit GPT-6.1 Sol erneut durch: Direkte Aufrufe benötigten 10 Modellaufrufe und 56,8 Sekunden, der Script-Modus 5 Modellaufrufe und 41,6 Sekunden. Die reine Zeit für Modellaufrufe sank dabei von 42,3 auf 28,0 Sekunden. Programme warten bis zu 5 Minuten, bevor sie die bisherige Ausgabe zurückgeben, können im Hintergrund weiterlaufen und das Modell nach Abschluss aufwecken, statt den Status laufend abzufragen.

Terminal-Bench 4 im direkten Vergleich mit Codex, Claude Code, Cursor, Devin und OpenCode

Factorys Vergleiche in Terminal-Bench 4 verwenden dieselben Modelle in verschiedenen Harnesses und wurden zwischen dem 23. und 28. Oktober 2026 durchgeführt. Alle folgenden Werte stammen aus Factorys eigener Darstellung und sind nicht unabhängig überprüft. Absolute Scores und Dollarbeträge nennt Factory nicht, sondern nur Abweichungen.

Bevor diese Werte als Kaufargument dienen, sind drei methodische Einschränkungen wichtig. Factory wertete einige Devin-Aufgaben als bestanden, wenn Codex sie bestanden hatte, weil Devin wegen Rückfragen abgebrochen hatte (durchschnittlich 4,7 Aufgaben pro Versuch; der Effekt betrifft nur die Genauigkeit). Bei zwei Durchläufen schätzte Factory Cursors fehlende Token-Nutzung anhand der Transkripte, nachdem die Verbindung während der Aufgabe erneut hergestellt worden war. Außerdem beruhen einige Vergleiche mit direkten Tool-Aufrufen auf Modellschätzungen und nicht auf tatsächlich beobachteten Durchläufen. Cursor wurde aus dem GPT-6.1-Sol-Vergleich ausgeschlossen, weil Cursor laut Factory zum Testzeitpunkt keinen Zugriff auf OpenAI-Modelle hatte.

Die in älterer Droid-Berichterstattung und in Harness-Benchmarks zitierten Terminal-Bench-Ergebnisse vom September 2025 basieren auf einem anderen Aufgabensatz und einer anderen Harness-Version. Sie bestätigen oder widerlegen die oben genannten 1.0-Abweichungen daher nicht.

Die Agent-Factory-Schleife und die unsichtbare Ingenieursarbeit

Factory beschreibt in seinem Beitrag zum Frontier-Harness die Agent-Factory-Schleife und die dahinterliegende Entwicklung: neue Modelle aufnehmen, alle Modelle mit denselben Aufgaben testen, Fehler analysieren, jede Änderung über die betroffenen Modelle hinweg prüfen und die Veröffentlichung erst nach dem Review durch Ingenieure für mehr als 20 Modelle freigeben.

Factory begründet diesen Aufwand mit der nötigen Anpassung pro Modell. Ein Beispiel: Zeilennummern bei jeder gelesenen Datei senkten die Opus-Kosten bei einer Aufgabe um 22 Prozent – bei ungefähr 2 Tokens pro Zeile. Bei GLM stiegen die Kosten jedoch um 8 Prozent, bei Kimi sogar um 32 Prozent. Deshalb ist die Zeilennummerierung nicht standardmäßig aktiv, sondern optional.

Die Änderungen abseits von PTC zielen auf Cache, Prompt-Größe, Wiederherstellung und Startzeiten:

• Prompt-Cache erhalten: Neu entdeckte Tools werden am Ende statt am Anfang der Anfragen ergänzt. Dadurch stieg die typische Wiederverwendung von Input aus dem Cache in den sieben Tagen bis zum 22. Oktober 2026 auf 98 Prozent; über 20,4 Millionen produktive CLI-Anfragen lag die tokengewichtete Wiederverwendung bei 91,5 Prozent.
• Basis-Prompt verkleinert: Die Eingabe der ersten Anfrage sank zwischen den Versionen 0.170.0 und 0.250.0 von 20.887 auf 13.055 Tokens (−37 %). Die Tool-Definitionen schrumpften von 15.798 auf 8.528 Tokens (−46 %); durch das Nachladen bei Bedarf sank die Zahl der vorab definierten Tools von 11 auf 2.
• Begrenzte Autonomie: Vier Minuten ohne Ausgabe in von Factory verwalteten Anthropic-Streams lösen einen erneuten Versuch aus, drei Durchläufe ohne sichtbare Ausgabe beenden die Schleife, drei identische Tool-Aufrufe führen zu einem Hinweis und sechs beenden sie. Die Größe von Kompaktzusammenfassungen wurde von 8.000 auf 16.000 Tokens verdoppelt.
• Start und Latenz: Die mediane Zeit bis zur ersten Darstellung sank von 1.839 auf 488 ms (~3,8x), die Zeit bis zur Prompt-Annahme von 1.876 auf 618 ms (~3,0x) und die Zeit bis zur ersten Modellanfrage von 1.741 auf 646 ms. Factory weist darauf hin, dass die Modellanfrage selbst etwa 97 Prozent der Wartezeit bis zum ersten Token ausmacht.

Preise und Limits: Hier verpufft der Effizienzgewinn

Die Preise von Factory Droid sind öffentlich, die nutzbare Kapazität dagegen nicht. Die Tarife sind beim Preis klar, bei der tatsächlichen Menge jedoch undurchsichtig. Genau dort können die Effizienzgewinne von Version 1.0 verschwinden.

Die Nutzung läuft über rollierende Zeitfenster von 5 Stunden, 7 Tagen und 30 Tagen, ergänzt durch Modellmultiplikatoren. CodeToolPilots Test vom Oktober 2026 weist außerdem darauf hin, dass sich Dokumentation und Preisseite widersprechen, welcher Tarif Droid Computers enthält. Vor dem Kauf sollte man das bestätigen. Wenn Standard Usage aufgebraucht ist, wechselt die Arbeit auf den kostenlosen Droid-Core-Pool mit Open Weights oder auf vorausbezahlte Extra Usage (mindestens $10, nicht verfallend). Für Missions muss Extra Usage aktiviert sein. BYOK-Schlüssel werden in den lokalen Einstellungen gespeichert und funktionieren in CLI und Desktop, nicht aber im gehosteten Web- oder Mobilangebot. Bis zum Tarifkontingent sind sie kostenlos, danach gilt die Abrechnung des jeweiligen Tarifs.

Der praktische Haken: Ein Multiplikator von „5x“ bedeutet nicht automatisch fünfmal so viel erledigte Arbeit. Der Durchsatz hängt von Modellwahl, Cache-Verhalten, Kontextlänge, Tool-Schleifen, Computernutzung und fehlgeschlagenen Durchläufen ab. Intensive Nutzer auf Reddit berichten, dass sie das Max-Kontingent bei cache-ungünstigen Aufgaben innerhalb weniger Stunden aufbrauchten. Der Script-Modus mildert das Problem, beseitigt es aber nicht.

Was echte Nutzer derzeit kritisieren

Die Stimmung am Starttag ist auf X positiv, aber wenig belastbar. Die längere Diskussion in r/FactoryAi auf Reddit nennt dagegen drei wiederkehrende Kritikpunkte, die man in einen Test einpreisen sollte: unklare Quoten, langsame Ausführung und hohe CPU-Last sowie der Prüfaufwand für autonome Ergebnisse.

„Wenn du die Nutzung vergleichst, wird Droids Tarif höchstwahrscheinlich nicht mit den subventionierten Tarifen von Anthropic und OpenAI mithalten können ... Als Harness fand ich ihn persönlich Claude Code überlegen. Bei meiner Nutzung funktioniert er einfach (vielleicht wegen des besseren System-Prompts), der Spec-Modus ist großartig und alle wichtigen UX-Elemente sind vorhanden.“ — u/FahimAdib11, r/FactoryAi

Andere Berichte in denselben Diskussionen nennen:

• Ein aufgebrauchtes Max-Kontingent nach etwa 4 Stunden bei cache-ungünstigen Durchläufen („Die Cache-Leistung ist wirklich schlecht“) — Quota-Diskussion
• Eine Leerlauf-CPU-Auslastung von etwa 101 Prozent gegenüber ungefähr 6 Prozent bei Claude Code; als mögliche Ursache wird MCP vermutet — Performance-Diskussion
• Neustarts von Sitzungen, die den Kontext verlieren und eine zeitaufwendige Wiederherstellung erzwingen

Frühe Erfahrungsberichte auf X zeigen ein ähnliches Bild: Ein Nutzer, der eine t3code-ähnliche Claude-Code-Integration portiert, berichtet von einer gesunden Nutzung im Mission-Modus und bezeichnet den Harness als „nächstes Level“ (@Davidwuuu92). Gleichzeitig räumt er ein, dass Devins Cloud-Umgebung und die Unterstützung mehrerer Plattformen weiterhin überlegen sind.

Die Lehre aus Continuums Factory-Test gilt auch für 1.0: Gemessen werden sollten akzeptierte Änderungen, Minuten für Reviews, unentdeckte Fehler, notwendige Eingriffe, erreichte Limits und die Gesamtkosten – nicht gestartete Sitzungen oder eröffnete Pull Requests. Autonomer Durchsatz erzeugt sonst schnell einen Prüfungsrückstand.

Wechseln oder bleiben? Entscheidungshilfe und 2-Wochen-Test

Droid 1.0 stärkt das Argument für einen effizienten Harness, löst aber nicht das Problem der schwer planbaren Quoten. Am meisten profitieren Teams, die eine Laufzeit über Modelle, Oberflächen und CI hinweg vereinheitlichen wollen und genügend Kapazität für die Reviews haben.

Vor einer Standardisierung empfiehlt sich ein zweiwöchiger Test mit demselben Repository:

1. 20 echte Tickets mit festen Akzeptanztests auswählen.
2. Droid CLI zunächst lokal ausführen und den Specification Mode bei komplexen Aufgaben aktivieren.
3. Claude Code oder Codex als Kontrolle mit identischen Aufgaben einsetzen.
4. Remote-Ausführung ergänzen und anschließend eine kleine Mission mit deterministischen Validatoren testen.
5. Jedes erreichte Limit, jeden Fallback auf Droid Core, jede Nutzung von Extra Usage, die Review-Minuten und die Kosten pro akzeptiertem Meilenstein protokollieren. Eine abgeschlossene Aufgabe außerdem auf einem sauberen Rechner wiederholen, um Abweichungen durch die Umgebung zu erkennen.

Der grundsätzliche Zielkonflikt bleibt bei Version 1.0 bestehen: Factory setzt darauf, dass der Harness wichtiger ist als das Modell, und stimmt das Verhalten über die Agent Factory für jedes Modell einzeln ab, ohne die Modellunabhängigkeit aufzugeben. Wenn sich Preise oder Ratenstrukturen der Frontier-Modelle verändern, kann der heutige Harness-Vorteil von 12–24 Prozent schneller schrumpfen, als der Script-Modus ihn durch Batching ausgleichen kann. Deshalb verdienen die Vertragsbedingungen zu Limits, Datenaufbewahrung und Routing genauso viel Aufmerksamkeit wie die Benchmark-Tabelle.

Factory Droid 1.0 FAQ

Lohnt sich Factory Droid 1.0 für $20 im Pro-Tarif?

Für Entwickler, die regelmäßig genug Terminal-Agent-Aufgaben ausführen, um Token- und Latenzkosten zu spüren, sind die $20 gut angelegt – besonders bei Aufgaben über mehrere Dateien oder Tickets hinweg, bei denen der Script-Modus Tool-Aufrufe bündelt. Wer nur wenig oder mit einem einzigen Modell arbeitet, kommt mit einem bereits enthaltenen Agenten möglicherweise günstiger weg.

Gibt es für Factory Droid eine kostenlose Testphase oder einen Gratis-Tarif?

Factory nennt keinen klassischen Gratis-Tarif. Aktuelle Tests weisen außerdem darauf hin, dass bei der Anmeldung eine Zahlungsmethode verlangt wird. Wenn ein bezahlter Tarif ausgeschöpft ist, wechselt die Nutzung auf den kostenlosen Droid-Core-Pool mit Open Weights. Ein bezahlter Tarif bleibt dennoch erforderlich.

Ist Factory Droid 1.0 besser als Claude Code?

Laut Factorys Terminal-Bench-4-Angaben erzielt Droid 1.0 mit Claude Opus 5.5 gegenüber Claude Code 3,0–7,6 Punkte mehr, kostet bis zu 24 Prozent weniger und benötigt pro erfolgreicher Aufgabe 26 Prozent weniger Zeit. Das sind von Factory selbst gemeldete Werte. Erfahrungsberichte auf Reddit sind geteilt: Einige bevorzugen Droids Harness, andere die geringere Reibung und die Preise von Claude Code.

Welche Modelle unterstützen den Script-Modus standardmäßig?

Factory nennt GPT-6.1 Sol, GPT-6.1 Terra, GPT-6 Astra, GPT-6 Sol, GPT-5.6 Sol, Claude Fable 5.1, Claude Fable 5, Claude Opus 5.5, Claude Opus 5 und Kimi K3. Andere Modelle verwenden direkte Aufrufe oder eine modellabhängige Abstimmung.

Was sind Factory Missions und was kosten sie?

Factory Missions zerlegen große Ziele für Projekte mit mehreren Funktionen in Meilensteine und setzen dafür Worker- und Validator-Agenten ein. Für Missions muss Extra Usage aktiviert sein; zusätzlich zur rollierenden Standard Usage fällt vorausbezahlte variable Nutzung an.

Kann Factory Droid in CI laufen und eigene Schlüssel verwenden?

Factory Droid lässt sich über droid exec ohne Benutzeroberfläche mit JSON-Ausgabe für Skripte und CI ausführen. BYOK unterstützt Anthropic, OpenAI, kompatible Endpunkte, Bedrock sowie lokale Installationen von Ollama, LM Studio und vLLM in CLI und Desktop. Benutzerdefinierte Modelle funktionieren nicht in den gehosteten Web- oder Mobil-Apps.

Weiterführend: Codex usage limits explained zum Vergleich von Quoten und Microsoft Copilot harness explained als weiteres Beispiel für Harness-Design.