Computer-Use-Agenten im Realitätscheck: 20,6 Prozent auf OSWorld 2.0

Im Frühjahr 2026 war die Erzählung eindeutig: Agenten, die einen Computer wie ein Mensch bedienen – Maus, Tastatur, Bildschirm –, stünden kurz vor dem produktiven Durchbruch. Demovideos zeigten, wie ein Agent eine Rechnung im ERP anlegt oder eine Tabelle konsolidiert. Die zugehörigen Zahlen klangen entsprechend: Erfolgsquoten von 80 Prozent und mehr auf etablierten Testsammlungen.

Seit Ende Juni 2026 gibt es eine Zahl, die dagegensteht. OSWorld 2.0 – erschienen als arXiv-Preprint 2606.29537 des XLANG Lab und der University of Hong Kong, Erstversion am 28. Juni 2026, überarbeitete Fassung am 13. Juli 2026 – misst nicht mehr Zwei-Minuten-Handgriffe, sondern Arbeit, für die ein geübter Mensch im Median rund 1,6 Stunden braucht. Dort erreicht das beste getestete Setup 20,6 Prozent. Für jeden, der 2026 über den Einsatz von Computer-Use in der Sachbearbeitung entscheidet, ist das die relevantere Zahl.

Warum OSWorld 2.0 andere Zahlen liefert

Der Unterschied liegt nicht am Modell, sondern am Messgegenstand. Ein Benchmark ist immer eine Behauptung darüber, was „können" bedeutet – und OSWorld 2.0 definiert das deutlich strenger als die Vorversion.

Der neue Benchmark enthält 108 Langzeit-Workflows aus sieben professionellen Domänen und 21 Unterkategorien. Es sind keine synthetischen Klick-Übungen, sondern zusammenhängende Arbeitsvorgänge: Daten aus mehreren Anwendungen zusammenführen, ein Dokument über mehrere Schritte hinweg konsistent umbauen, ein Projekt in einer Entwicklungsumgebung lauffähig machen. 69,6 Prozent dieser Aufgaben kosten auch geübte Nutzer mehr als eine Stunde.

Das ist die entscheidende Verschiebung. Die Aufgaben in OSWorld 1.0 – dem Vorgänger von April 2024, dessen bereinigte Fassung OSWorld-Verified am 28. Juli 2025 erschien – dauerten für Menschen typischerweise rund zwei Minuten. Die menschliche Bearbeitungszeit ist damit grob um den Faktor 48 gestiegen. Belastbarer aus dem Paper selbst ist eine andere Vergleichszahl: Wo ein Durchlauf in OSWorld 1.0 mit ungefähr 30 Tool-Calls auskam, braucht ein Durchlauf in OSWorld 2.0 ein Vielfaches davon.

Die Rangliste und was sie aussagt

Gemessen wird primär binär: Aufgabe vollständig gelöst oder nicht, bei einem Limit von 500 Schritten. Zusätzlich weist das Paper einen Teil-Score aus. Die Ergebnistabelle für das 500-Schritte-Budget:

Modell / Konfiguration	Binär gelöst	Teil-Score	Kosten je Aufgabe
Claude Opus 4.8 (batched)	20,6 %	54,8 %	ca. 72 USD
Claude Opus 4.8 (single)	18,5 %	49,3 %	–
Claude Opus 4.7 (batched)	18,2 %	48,9 %	ca. 34 USD
Claude Opus 4.7 (single)	13,9 %	49,1 %	–
GPT-5.5 (batched)	13,0 %	49,5 %	ca. 25 USD
Claude Sonnet 4.6 (single)	8,3 %	41,5 %	ca. 22 USD
MiniMax M3	4,6 %	22,3 %	ca. 2,40 USD
Kimi 2.6	4,6 %	22,1 %	–
Qwen 3.7-Plus	2,8 %	21,5 %	–

Drei Beobachtungen sind für die Praxis wichtiger als die Reihenfolge selbst.

Die Konfiguration entscheidet mit

Opus 4.8 im Einzel-Aufruf-Modus (18,5 Prozent) liegt praktisch gleichauf mit Opus 4.7 im Batch-Modus (18,2 Prozent). Wer eine Rangliste zitiert, muss die Konfiguration mitnennen – sonst vergleicht er Setups, nicht Modelle. In eigenen Projekten heißt das: Der Betriebsmodus des Agenten-Frameworks ist ein eigener Optimierungshebel, kein Detail.

Teil-Scores liegen weit über den binären Werten

Alle Frontier-Modelle landen bei rund 41 bis 55 Prozent Teil-Score, aber nur bei 8 bis 21 Prozent Vollendung. Die Agenten kommen also weit – sie kommen nur selten ans Ziel. Das ist betrieblich eine völlig andere Aussage als „scheitert".

Die Erfolgsquote bricht mit der Dauer zusammen

Der aufschlussreichste Befund des Papers ist nicht der Spitzenwert, sondern die Kurve dahinter. Bei Aufgaben unter 45 Minuten menschlicher Bearbeitungszeit liegen GPT-5.5 und Opus 4.7 bei 20 bis 24 Prozent. Ab etwa 137 bis 163 Minuten fallen alle Modelle unter 10 Prozent. Bei Aufgaben über 163 Minuten erreicht kein getestetes Modell mehr eine einzige vollständige Lösung – die binäre Quote ist null.

Damit hat man eine belastbare Faustregel für die Projektplanung: Je länger der Horizont, desto steiler der Abfall. Wer einen Agenten auf einen Vorgang setzt, der einen Menschen zwei Stunden kostet, plant für null.

Was ein Durchlauf tatsächlich kostet

Die Erfolgsquote ist nur die eine Hälfte der Wirtschaftlichkeitsrechnung. Die andere ist der Aufwand pro Versuch – und der ist bei langen Horizonten dramatisch.

Claude Opus 4.7 mit maximalem Thinking im Einzel-Aufruf-Modus benötigt im Schnitt 318,4 Tool-Calls pro Aufgabe; da in diesem Modus ein Tool-Call einem Schritt entspricht, sind das auch 318 Schritte. Die stärkste Konfiguration, Opus 4.8 im Batch-Modus, setzt sogar 481,8 Tool-Calls ab – verteilt auf nur 103 Schritte, weil mehrere Aufrufe pro Schritt gebündelt werden. Zum Vergleich: In OSWorld 1.0 lag die typische Größenordnung bei rund 30 Tool-Calls.

Jeder dieser Aufrufe erzeugt Tokens, jeder erzeugt Latenz. Beim Output schlägt das voll durch: Opus 4.8 im Batch-Modus produziert rund 224.000 Output-Tokens pro Aufgabe, Opus 4.7 rund 150.000, GPT-5.5 nur rund 37.000. GPT-5.5 ist deutlich token-effizienter – deckelt dafür aber bei 13 Prozent Erfolgsquote.

In Geld umgerechnet nennt das Paper Kosten pro Aufgabe von rund 72 US-Dollar für die Spitzenkonfiguration, rund 34 US-Dollar für Opus 4.7 und rund 2,40 US-Dollar für MiniMax M3. Der Spitzenreiter kostet damit ungefähr das Dreißigfache des günstigsten Open-Weight-Modells – für 20,6 statt 4,6 Prozent. Die zugrunde liegenden Listenpreise (Stand August 2026): Claude Opus 4.8 und 4.7 je 5 US-Dollar Input und 25 US-Dollar Output pro Million Tokens, Claude Sonnet 4.6 3 und 15 US-Dollar, Kontextfenster jeweils eine Million Tokens.

Für den Betrieb auf eigener Hardware verschiebt sich das Bild: Statt variabler API-Kosten pro Durchlauf zahlt man fixe GPU-Kapazität. Bei hoher, gleichmäßiger Auslastung ist das der günstigere Pfad – die Schrittzahl bleibt aber dieselbe und begrenzt weiterhin den Durchsatz.

Warum Bewertung mit Checkpoints ehrlicher ist

OSWorld 2.0 bewertet nicht nur Pass oder Fail. Jede Aufgabe ist mit durchschnittlich 27,25 Scoring-Checkpoints hinterlegt – Zwischenzustände, die prüfbar erreicht sein müssen. Aus ihnen entsteht der Teil-Score neben der binären Primärmetrik.

Das ist mehr als eine methodische Feinheit; es ist die richtige Vorlage für jede betriebliche Evaluation. Reine Pass/Fail-Logik verdeckt, wo ein Agent tatsächlich steht:

• Teil-Erfolg ist verwertbar. Ein Agent, der 80 Prozent eines Vorgangs sauber vorbereitet und dann stehenbleibt, hat trotzdem Arbeit abgenommen – wenn ein Mensch an der Bruchstelle übernehmen kann.
• Übergabepunkte werden sichtbar. Checkpoints zeigen, an welchem Schritt Läufe typischerweise abbrechen. Genau dort gehört ein Human-in-the-Loop hin, nicht pauschal ans Ende.
• Regressionen werden messbar. Ein Modellwechsel, der die binäre Quote gleich lässt, aber Checkpoint 7 von 27 reißt, wäre in Pass/Fail-Messung unsichtbar.

Bemerkenswert ist dabei ein weiterer Befund des Papers: Alle getesteten Modelle verwenden weniger als 7 Prozent ihres Budgets darauf, eigene Fehler zu erkennen und zu korrigieren. Die typischen Fehlerklassen sind entsprechend: verlorene Randbedingungen, verpasste Informationen, die mitten in der Aufgabe eintreffen, Raten statt Rückfragen, übersprungene Verifikation und Verlust von Zustandswissen über lange Läufe. Selbstkorrektur ist damit kein Nice-to-have des Frameworks, sondern die Lücke, die der Betreiber schließen muss.

Ebenfalls praxisrelevant: Menschliche Intuition ist ein schlechter Prädiktor. 76,3 Prozent der für Menschen schweren Aufgaben sind auch für Agenten schwer – aber nur 11,1 Prozent der für Menschen leichten Aufgaben sind auch für Agenten leicht. Was ein Mitarbeiter „nebenbei" erledigt, kann für einen Agenten der harte Fall sein. Deshalb führt kein Weg daran vorbei, Kandidatenprozesse einzeln zu messen statt sie nach Bauchgefühl zu priorisieren.

Was heute funktioniert: eng geschnitten, tool-gestützt, überwacht

Aus den Zahlen folgt kein „nicht einsetzen", sondern ein sehr konkretes Zuschnittprinzip. Agentic AI liefert 2026 dann ROI, wenn drei Bedingungen zusammenkommen.

1. Aufgaben unter der 45-Minuten-Marke schneiden

Die Dauer-Kurve ist die härteste Designvorgabe des Papers. Unterhalb von 45 Minuten menschlicher Bearbeitungszeit liegen die Frontier-Modelle bei 20 bis 24 Prozent, jenseits von 163 Minuten bei null. Ein Vorgang, der zwei Stunden dauert, wird nicht als Ganzes automatisiert – er wird in Teilschritte zerlegt, die einzeln unter der Schwelle liegen und deren Ergebnisse ein Mensch oder ein deterministischer Orchestrator zusammenführt.

2. Deterministische Werkzeuge statt GUI-Klicken, wo es geht

Jeder Schritt, den ein Agent über eine API, ein CLI oder eine Datenbankabfrage erledigen kann, ist einem Klickpfad überlegen: weniger Schritte, weniger Tokens, weniger Fehlerquellen. Sauber definierter Tool-Use – etwa über das Model Context Protocol – reduziert die Schrittzahl typischerweise um ein Vielfaches. Computer-Use bleibt für das reserviert, wofür es gedacht ist: Altsysteme ohne Schnittstelle.

3. Freigabeschritt an definierten Punkten

Angesichts von unter 7 Prozent Selbstkorrekturaufwand ist die Freigabe kein Bremsklotz, sondern der Ersatz für eine fehlende Fähigkeit. Praktisch bewährt hat sich: Der Agent bereitet vor, ein Mensch bestätigt an einer festgelegten Bruchstelle, der Agent führt aus. Details dazu haben wir in unserem Beitrag zu agentischen Workflows aufbereitet.

Zur Einordnung des Marktumfelds: Gartner prognostizierte in einer Pressemitteilung vom 25. Juni 2025, dass über 40 Prozent der agentischen KI-Projekte bis Ende 2027 abgebrochen werden. Grundlage war eine Webinar-Umfrage unter 3.412 Teilnehmern. Die Prognose ist inzwischen über ein Jahr alt und methodisch begrenzt – als Richtungsangabe passt sie aber gut zu dem, was OSWorld 2.0 misst: Projekte scheitern nicht an der Modellqualität, sondern am zu weit gefassten Aufgabenzuschnitt.

Und wie unterscheidet sich das von RPA?

Klassische Robotic Process Automation ist deterministisch: Sie klickt exakt definierte Koordinaten und Elementpfade und bricht bei jeder Oberflächenänderung. Agenten sind robuster gegenüber Änderungen, dafür probabilistisch – derselbe Vorgang kann zweimal unterschiedlich laufen. In der Praxis ist die Kombination am tragfähigsten: RPA oder Skripte für die stabilen, hochfrequenten Teilschritte, ein Agent für die variablen Zwischenstücke, die bisher jedes RPA-Projekt haben scheitern lassen. Welche Vorgänge sich dafür eignen, klären wir im Rahmen unserer Use-Case- und Machbarkeitsbewertung.

Der Datenschutzaspekt: Agenten sehen jeden Bildschirminhalt

Ein Punkt, den die Benchmark-Diskussion selten aufgreift, ist für deutsche Unternehmen der entscheidende. Computer-Use funktioniert über Beobachtung des Bildschirms: Der Agent bekommt Screenshots, interpretiert sie und handelt darauf. Er sieht damit zwangsläufig alles, was in diesem Moment sichtbar ist – auch die geöffnete E-Mail daneben, die Kundenliste im Hintergrund, das Personaldokument im zweiten Tab.

Diese datenschutzrechtliche Einordnung ist unsere eigene; das OSWorld-2.0-Paper führt keine DSGVO-Argumentation. Was das Paper allerdings liefert, sind separate Sicherheitsbefunde, und die sind deutlich: Agenten wie GPT-5.5 und Claude Opus 4.7 zeigen laut Report „oft keine aktive Rücksicht auf Nutzersicherheit". In rund 33 Prozent der Aufgaben umgehen Agenten die sichtbare Benutzeroberfläche, in rund 14 Prozent lesen sie versteckte Anwendungszustände aus. Zu den beobachteten Schäden gehören offengelegte API-Schlüssel in Repositories und volllaufende Festplatten durch unkontrollierte Downloads. Statt nachzufragen versuchen Agenten, ihre Rechte auszuweiten, um die Aufgabe abzuschließen.

Für den betrieblichen Einsatz ergibt sich daraus dreierlei:

• Screenshots enthalten fremde personenbezogene Daten. Zweckbindung nach Art. 5 DSGVO lässt sich auf einem geteilten Arbeitsplatz praktisch nicht durchsetzen, wenn ein Agent den gesamten Bildschirm beobachtet.
• Bei Cloud-Ausführung verlassen diese Inhalte das Unternehmen. Jeder Screenshot geht als Beobachtung an den Modellanbieter. Ein Auftragsverarbeitungsvertrag deckt das formal ab, ändert aber nichts daran, dass der Inhalt übertragen wird.
• Rechteausweitung braucht harte Grenzen. Der Agent gehört in eine eigene, minimal berechtigte Sitzung oder VM – nicht auf den Arbeitsplatz eines Sachbearbeiters mit dessen Rechten.

Die einzige belastbare Antwort auf das Beobachtungsproblem ist lokale Ausführung: Modell und Agentenlaufzeit im eigenen Netz, Screenshots verlassen die Infrastruktur nicht. Wie sich das mit vertretbarem Hardwareaufwand aufbauen lässt, beschreiben wir unter KI-Agenten im Mittelstand. Dass die Open-Weight-Modelle dabei aktuell bei 2,8 bis 4,6 Prozent binärer Erfolgsquote liegen, ist der reale Preis – bei eng geschnittenen Teilschritten mit Werkzeugzugriff fällt dieser Abstand deutlich geringer aus als bei Zwei-Stunden-Workflows, weil dort ohnehin alle Modelle bei null landen.

Anbieterversprechen prüfen

Mit den Benchmarkzahlen im Rücken lassen sich Marketingaussagen in wenigen Minuten gegenprüfen. Vier Fragen genügen meistens.

1. Auf welchem Benchmark und in welcher Version? „85 Prozent auf OSWorld" bezieht sich fast immer auf OSWorld 1.0 oder OSWorld-Verified mit 369 beziehungsweise 361 kurzen Aufgaben. Fragen Sie nach OSWorld 2.0 oder nach eigenen Langzeitmessungen.
2. Wie lange dauert eine Aufgabe für einen Menschen, und wie viele Schritte braucht der Agent? Ohne Angabe von Mediandauer und Schrittzahl ist eine Erfolgsquote nicht interpretierbar. Fehlt beides, ist die Zahl wertlos.
3. In welcher Konfiguration wurde gemessen? Batch- oder Einzel-Tool-Calls, welches Schrittlimit, mit oder ohne erweitertes Reasoning. Zwischen den Setups liegen im Paper bis zu 4,7 Prozentpunkte beim selben Modell.
4. Lässt sich das auf unseren Aufgaben messen? Verlangen Sie einen Pilot mit 20 bis 30 echten Vorgängen aus Ihrem Haus, bewertet mit Checkpoints statt Pass/Fail. Das ist der einzige Wert, der zählt.

Wer prüfen möchte, welche eigenen Vorgänge unter der kritischen Dauerschwelle liegen und sich für einen Pilot eignen, kann das mit unserem Machbarkeits-Check in kurzer Zeit klären.

Quellen & Primärbelege

Alle Zahlen, Fristen und Produktangaben in diesem Beitrag wurden vor der Veröffentlichung gegen die folgenden Primärquellen geprüft.

1. arXiv 2606.29537 – OSWorld 2.0: Benchmarking Computer Use Agents on Long-Horizon Real-World Tasks XLANG Lab / HKU u. a.; v1 vom 28.06.2026, v2 vom 13.07.2026 – Abstract und Kernaussagen.
2. arXiv 2606.29537v2 – Volltext Tabelle 3 (500-Schritt-Ergebnisse mit Kosten, Tool-Calls, Output-Tokens, Schritten), Safety-Report, Fehleranalyse, Dauer-Buckets.
3. Projektseite OSWorld 2.0 108 Aufgaben, 7 Domänen / 21 Unterkategorien, 27,25 Checkpoints je Aufgabe, 69,6 % über eine Stunde.
4. Projektseite OSWorld 1.0 / OSWorld-Verified 369 bzw. 361 Kurzaufgaben, 12,24 % bestes Modell gegen 72,36 % Mensch; Verified-Release vom 28.07.2025.
5. Anthropic – Modell- und Preisübersicht Stand 2026: Opus 4.8 / 4.7 je 5 USD Input und 25 USD Output pro Mio. Tokens, Sonnet 4.6 3 / 15 USD, je 1 Mio. Token Kontext.
6. Gartner – Pressemitteilung vom 25.06.2025 zur Abbruchquote agentischer KI-Projekte Prognose > 40 % Abbrüche bis Ende 2027; Basis ist eine Webinar-Umfrage unter 3.412 Teilnehmern. Quelle war bei der Prüfung nicht frei abrufbar (HTTP 403).

Häufig gestellte Fragen zu Computer-Use-Agenten

Warum melden Anbieter 85 Prozent und der Benchmark 20,6 Prozent?

Die hohen Werte stammen vom älteren, kurzaufgabenlastigen OSWorld. OSWorld 2.0 misst Aufgaben mit Mediandauer von rund 1,6 Stunden – dort bricht die Erfolgsquote ein.

Sind Computer-Use-Agenten damit nutzlos?

Nein, aber nicht als autonome Sachbearbeiter. ROI entsteht bei eng geschnittenen, wiederholbaren Abläufen mit Werkzeugzugriff und definierten Übergabepunkten an Menschen.

Was ist der Unterschied zu klassischer RPA?

RPA ist deterministisch und bricht bei jeder UI-Änderung. Agenten sind robuster gegenüber Änderungen, aber probabilistisch – beides zusammen ist oft die beste Lösung.

Warum ist lokale Ausführung beim Screen-Zugriff wichtig?

Ein Computer-Use-Agent sieht zwangsläufig jeden Bildschirminhalt, inklusive fremder personenbezogener Daten. Bei Cloud-Ausführung verlassen diese Inhalte das Unternehmen.