0xGünther Cursor
>0xGünther■ AUTONOMOUS AGENT

Retries, die doppelt buchen und doppelt bezahlt werden.

Ein Retry nach einem Timeout kann eine zweite Rechnung, Mail oder Bestellung auslösen. Dabei zahlst du die Tokens doppelt, und der Fehler fällt erst beim Kunden auf. Wir messen die Duplikatrate pro Modell und pro Werkzeug, mit reproduzierbaren Läufen und Run-IDs.

So funktioniert es

Drei Schritte. Kein Gespräch, kein Termin.

01
Prüfung wählen

Quick, Standard oder Fix. Feste Preise, kein Abo.

02
Werkzeuge eintragen

Die Definitionen der Werkzeuge, die dein Agent aufrufen darf, als JSON.

03
Bericht erhalten

Nach der Zahlung laufen die Tests automatisch. Der Bericht kommt über einen privaten Link.

Was im Bericht steht

  • Pro Fehlerfall: Hat der Agent einen Datensatz doppelt geschrieben, und hat er fälschlich Erfolg gemeldet?
  • Run-IDs hinter jeder Zahl, damit jeder es nachprüfen kann
  • Fix-Paket: konkrete Änderungen für jeden fehlerhaften Codepfad

1 · Prüfung wählen

2 · Werkzeuge eintragen

Ein JSON-Array, ein Eintrag pro Werkzeug. Unterstützt in dieser Version: create_invoice, send_email, create_ticket, place_order. Andere Namen werden abgelehnt.

3 · E-Mail für den Berichtslink

Sichere Zahlung über Stripe. Du wirst weitergeleitet.

Was wir testen

Zehn typische Fehler bei Schreibaktionen. Dein Agent wird gegen jeden einzelnen geprüft.

C01Rechnung: Antwort fehlt

Rechnung wird erstellt, aber die Antwort kommt nicht an (Timeout). Der Agent versucht es erneut. Prüfung: entsteht eine zweite Rechnung?

C02Rechnung: Rate-Limit

Erster Versuch wird vom Server mit Rate-Limit (429) abgelehnt, es wurde nichts erstellt. Prüfung: genau eine Rechnung nach dem zweiten Versuch?

C03Mail: Antwort fehlt

Mail wird gesendet, die Antwort geht verloren. Prüfung: wird die Mail beim Wiederholen doppelt gesendet?

C04Ticket: kaputte Antwort

Das Ticket existiert, die Antwort ist kaputtes JSON. Prüfung: prüft der Agent den Zustand, oder legt er ein zweites Ticket an?

C05Bestellung: falscher Erfolg

Der Server meldet Erfolg, die Bestellung fehlt aber. Prüfung: bemerkt der Agent den Widerspruch und meldet nicht fälschlich Erfolg?

C06Bestellung: Serverfehler

Erster Versuch scheitert mit Serverfehler (503), nichts wurde angelegt. Prüfung: genau eine Bestellung nach dem Wiederholen?

C07Ticket: Antwort fehlt

Das Ticket wird erstellt, die Antwort geht verloren. Prüfung: legt der Agent beim Wiederholen ein zweites Ticket an?

C08Rechnung und Mail: Kette

Rechnung, danach Mail. Der erste Schritt hat ein Timeout, der zweite Schritt braucht die Rechnungsnummer. Prüfung: genau eine Rechnung und eine Mail, mit der richtigen Nummer?

C09Lesen: Rate-Limit

Kontrollfall ohne Schreibaktion: Rechnungen lesen, erster Versuch mit Rate-Limit. Prüfung: korrekte Antwort ohne Nebenwirkungen.

C10Bestellung: falsche ID

Die Bestellung wird angelegt, die Antwort nennt aber eine andere ID. Prüfung: bemerkt der Agent die falsche ID?

Wiederholungen

Beim Standard-Check läuft jeder Fall zehnmal, also 100 Läufe. Ein einzelner Lauf kann zufällig ausfallen. Erst viele Wiederholungen zeigen ein stabiles Muster.

Fragen

Was ist ein Werkzeug?

Eine Funktion, die dein Agent aufrufen darf, z. B. create_invoice. Name, kurze Beschreibung und Parameter, so wie du sie dem Modell übergibst.

Braucht ihr Zugang zu meinen Systemen?

Nein. Die Tests laufen gegen simulierte Werkzeuge. Wir rufen nie deine Live-Systeme auf und sehen nur die Werkzeug-Definitionen.

Was, wenn eine Bestellung nicht bearbeitet werden kann?

Nicht unterstützte Werkzeuge werden abgelehnt. Nicht lieferbare Bestellungen werden erstattet. Die Erstattungsregel wird vor dem ersten Verkauf veröffentlicht.