Factory bringt Droid 1.0 heraus: Sein Coding-Agent schreibt Programme für Hunderte verkettete Tool-Aufrufe
Factory hat Droid 1.0 vorgestellt, die neue Version des „Harness“ seines Entwicklungsagenten. Die wichtigste Neuerung: Das Modell schreibt ein kurzes JavaScript-Programm, das die Tools selbstständig aufruft, was die Anzahl der Anfragen und den Kontextverbrauch senkt. Factory beansprucht auf Terminal-Bench 4 bessere Ergebnisse als Codex, Claude Code oder Cursor bei geringeren Kosten – Messungen, die das Unternehmen selbst durchgeführt hat.
Das Start-up Factory hat am Donnerstag, den 29. Oktober, um 23:31 Uhr Pariser Zeit, Droid 1.0 vorgestellt – das bislang größte Update für die Engine seines Entwicklungsagenten. Factory entwickelt keine eigenen Modelle: Das Produkt ist ein sogenannter „Harness“, also die gesamte Infrastruktur rund um das Modell (Anweisungen, Tools, Rückgabeformate von Ergebnissen, Ausführungsschleife). Das Unternehmen bewirbt das System als präziser, sparsamer und schneller als die Agenten, die von den Modellherstellern selbst entwickelt wurden.
Das Modell schreibt ein Programm, anstatt Tools einzeln aufzurufen
Das Kernstück von Droid 1.0 sind programmatische Tool-Aufrufe, die nun standardmäßig aktiviert sind. In einer klassischen Agentenschleife ruft das Modell ein Tool auf (etwa das Lesen einer Datei oder Ausführen eines Befehls), erhält das Ergebnis in seinem Kontext und entscheidet dann über den nächsten Schritt: Jeder Zwischenschritt erfordert eine neue Anfrage, bei der stets Anweisungen und Verlauf erneut übertragen werden.
Mit dem Tool Script schreibt das Modell stattdessen ein kurzes JavaScript-Programm, das die Aufrufe eigenständig aneinanderreiht. Dieses Programm läuft in einer Sandbox ohne direkten Zugriff auf Dateien, Netzwerk oder das Betriebssystem; es kann ausschließlich über die Droid-Tools interagieren. Rohdaten wie Dateien, Logs oder Suchergebnisse verbleiben in Variablen des Programms, und das Modell liest nur das, was das Programm ausgibt. Factory führt drei Hauptargumente an: einen schlankeren Kontext, weniger Anfragen und deterministisch ausgeführte Prüfungen ohne das Risiko, dass das Modell unterwegs Sonderfälle „vergisst“.
Das Unternehmen nennt zwei Beispiele aus eigenen Sitzungen. Das Aufräumen von Linear-Tickets (151 verschobene und anschließend überprüfte Tickets, 312 Tool-Aufrufe) benötigte 2 Anfragen und rund 61 000 Tokens, verglichen mit geschätzten 36 Anfragen und 3,1 Millionen Tokens bei direkten Aufrufen. Eine Überprüfung von 5 384 Continuous-Integration-Aufgaben kam ebenfalls mit 2 Anfragen aus, wobei das Modell lediglich eine Zusammenfassung aus fünf Zahlen zu sehen bekam. Der Script-Modus ist standardmäßig für die führenden Modelle von OpenAI und Anthropic (darunter GPT-6.1 Sol und Claude Opus 5.5) sowie für Kimi K3 aktiviert.
Factory hat zudem die erste Anfrage jeder Sitzung verschlankt: Sie sank von 20 887 auf 13 055 Tokens (−37 Prozent), vor allem weil Droid zu Beginn nur noch 2 Tool-Definitionen statt 11 sendet und weitere bei Bedarf nachlädt. Schließlich beschreibt das Unternehmen Schutzmechanismen gegen Endlosschleifen (beispielsweise ein Abbruch nach sechs identischen Tool-Aufrufen) sowie eine spürbar kürzere Startzeit der Anwendung.
Von Factory gemessene Ergebnisse
Auf Terminal-Bench 4 vergleicht Factory Droid mit anderen Harnesses unter Verwendung desselben Modells. Mit GPT-6.1 Sol erziele Droid 3,5 Punkte mehr als Codex bei um 12 Prozent geringeren Kosten, benötige jedoch 10 Prozent mehr Zeit. Mit Claude Opus 5.5 liege das System 3,0 bis 7,6 Punkte vor Cursor, OpenCode, Devin und Claude Code, bei um bis zu 24 Prozent geringeren Kosten. Cursor taucht im Vergleich zu GPT-6.1 Sol nicht auf, da die Plattform laut Factory keinen Zugriff auf OpenAI-Modelle habe.
Diese Zahlen stammen von Factory und wurden nicht unabhängig verifiziert. Die am Ende des Blogbeitrags dargelegte Methodik ist dabei aufschlussreich: Kosten und Ausführungszeit berücksichtigen nur Aufgaben, die beide Harnesses bei allen drei Testläufen erfolgreich meisterten. Aufgaben, die von Anthropics Moderationsfiltern blockiert wurden, wurden auf Claude Opus 5 neu gestartet. Zudem wurde eine Aufgabe, bei der Devin anhielt, um dem Nutzer eine Frage zu stellen, als Erfolg gewertet, sofern Codex sie erfolgreich abschloss.
Wo man es ausprobieren kann
Droid 1.0 ist ab sofort als Desktop-Anwendung für macOS und Windows sowie als Terminal-Schnittstelle verfügbar. Für Entwickler, die eigene Werkzeuge auf Basis derselben Engine erstellen möchten, stellt Factory ein TypeScript-SDK bereit (@factory/droid-sdk). Damit lässt sich Droid über Node ausführen, mehrstufige Sitzungen verwalten und benutzerdefinierte Tools über MCP einbinden.
Unsere Einschätzung
Droid 1.0 verdeutlicht einen grundlegenden Trend bei Coding-Agenten: Leistungssteigerungen entstehen nicht mehr allein durch das Modell, sondern durch dessen Orchestrierung. Dass ein Modell Programme schreibt, um Tools zu steuern, ist nicht neu (Factory verweist selbst auf Arbeiten wie CodeAct sowie Entwicklungen von Cloudflare, Anthropic und Codex). Diesen Ansatz jedoch zum Standardmodus eines kommerziellen, modellübergreifenden Agenten zu machen, ist eine klare Wette auf die Planungsfähigkeiten aktueller Spitzenmodelle. Das wirtschaftliche Argument überzeugt am meisten: Bei langen Aufgaben senken weniger Anfragen und ein schlankerer Kontext die Kosten unmittelbar. Die Vergleiche mit Codex oder Claude Code bleiben dennoch interne Messungen mit diskussionswürdigen methodischen Entscheidungen; unabhängige Benchmarks stehen noch aus.
Quellen
- Factory (X) — Ankündigung von Droid 1.0 Primärquelle
- Factory — Droid 1.0: Building a Frontier Harness Primärquelle
- Factory — Dokumentation des TypeScript-SDKs von Droid Primärquelle
Eine Primärquelle stammt direkt von dem betreffenden Unternehmen, Labor oder der Organisation. Eine Sekundärquelle gibt die Information wieder, ohne ihr Urheber zu sein: Wir kennzeichnen sie als solche. Einen Fehler entdeckt? Lesen Sie unsere Korrekturrichtlinie.
