Sol verbrannte Limits durch unnötige Tool-Aufrufe

Was genau in Sol kaputtging

Die Kernfakten sind einfach: Sol verbrauchte Limits nicht wegen der Aufgabenkomplexität, sondern wegen unnötiger Tool-Aufrufe. Am 30. Juli 2026 wurde in einer Nutzerdiskussion eine Nachricht von Tibo zusammengefasst: Der Agent führte ineffiziente Aktionen aus, rief wiederholt Tools auf, verbrannte Limits schnell; nach dem Fix wurde ein Reset durchgeführt.

Das ist klassischer Tool-Spam. Das Modell denkt nicht einfach länger, es löst externe Aktionen aus, die Limits, Zeit und manchmal Geld kosten. Wenn ein Aufruf keine neue Information bringt, wird er zu Rauschen, aber der Zähler läuft weiter.

In dieser Geschichte kommt es mir nicht auf den Reset selbst an. Resets behandeln die Symptome. Die eigentliche Ursache liegt fast immer tiefer: Man hat dem Agenten erlaubt, zu frei auf Tools zuzugreifen, ohne ihn zu zwingen, den Nutzen jedes Aufrufs zu belegen, und ohne den Kreislauf zu stoppen, wenn kein Fortschritt mehr erzielt wurde.

Eine gute agenten-basierte Laufzeitumgebung sollte langweilig und strikt sein. Deduplizierung identischer Tool+Args-Aufrufe, Iterationslimits, individuelle Obergrenzen pro Tool, eine einheitliche Wiederholungsrichtlinie, verständliche strukturierte Fehler statt blinder Wiederholungen. Das sind keine kosmetischen Verschönerungen um einen Prompt herum, sondern die Bremsen an einem Fahrzeug, das sonst fröhlich im Kreis fahren würde.

Warum das für Nutzer von KI-Agenten wichtig ist

Dieser Bug trifft direkt die Nutzererfahrung: Limits verschwinden zu früh, die Latenz steigt und die Antwortqualität verbessert sich möglicherweise überhaupt nicht. Von außen sieht es nach normaler Aktivität eines intelligenten Agenten aus: Er ruft auf, prüft, verfeinert. In Wirklichkeit dreht er sich vielleicht nur im Kreis.

In einem ähnlichen Vorfall würde ich als Erstes nicht den Text des System-Prompts lesen, sondern die Ausführungsspuren untersuchen. Wie viele wiederholte Aufrufe gab es, änderten sich die Ergebnisse nach jedem Schritt, gab es identische Argumente, wo griffen Wiederholungen. Wenn ein großer Teil der Aufrufe den nächsten Denkschritt nicht verändert, ist der Agent nicht autonom, sondern gefräßig.

Für Sol ist es ein gutes Zeichen, dass das Problem als ineffiziente Aktionen anerkannt und behoben wurde, anstatt es auf die Nutzer zu schieben. Aber ohne Details zum Fix bleibt die zentrale technische Frage: War es ein einmaliger Patch für ein bestimmtes Szenario, oder wurden harte Barrieren in die Ausführungsschicht eingebaut?

In Agentenprodukten wird nicht der gewinnen, der am lautesten Autonomie verspricht, sondern der, der dem Modell rechtzeitig sagen kann: Hör auf, das Tool aufzurufen, du hast bereits alles, was du brauchst. Genau dort versteckt sich die Zuverlässigkeit des Agenten, nicht in einem schönen System-Prompt.

Wir haben bereits analysiert, wie Homoglyphen-Angriffe die Sicherheit von Tool-Aufrufen bei KI-Agenten bedrohen. Bei der Optimierung solcher Aufrufe ist es wichtig, auch diesen Risikovektor zu berücksichtigen.