0154c0f5757bd212a2402b221f478f9efc95de48
Am 01.08.2026 lieferte Bedrock waehrend eines Laufs ServiceUnavailableException. Botocore versuchte es dreimal in fuenf Sekunden und gab auf, die Web-Source-Selektion fiel ersatzlos aus. Im Bericht war davon nichts zu sehen, der Lauf galt als vollstaendig. Gemessen sind es zwei betroffene Aufrufe bei rund 340, also 0,6 Prozent, aber jeder Vorfall kostet einen ganzen Pipeline-Schritt. Der Fehler ist auch keiner unserer Quote. ServiceUnavailableException ist ein 503, AWS hat also gerade keine Kapazitaet fuer das Modell. Unsere Meldung sagte trotzdem "Rate-Limit", weil der Code beide Faelle in einen Topf warf. Aendert sich damit: 1. Geduldiges Wiederholen. Kapazitaets- (503), Kontingent- (429) und Verbindungsfehler werden nach 5, 15 und 30 Sekunden erneut versucht. Diese Dellen dauern typischerweise unter einer Minute, unsere bisherigen fuenf Sekunden lagen genau im ungeguenstigsten Fenster. Stufen ueber BEDROCK_RETRY_WAITS einstellbar. 2. Zwei Bremsen gegen lange Laeufe. Gewartet wird nur, wenn die Wartezeit ins Zeitbudget des Aufrufs passt (die Wartezeit zaehlt gegen dasselbe asyncio-Budget, und die Haiku-Planungsaufrufe haben nur 120 Sekunden), und nur solange das Wartebudget des Refreshs reicht (BEDROCK_RETRY_BUDGET_S, Vorgabe 120 Sekunden). Ein Lauf kann sich dadurch um hoechstens zwei Minuten verlaengern. 3. Ursachen werden getrennt benannt. Im Log steht jetzt "hat keine freie Kapazitaet" oder "meldet ausgeschoepftes Kontingent" statt pauschal "Rate-Limit". Nach aussen bleibt beides die Kategorie rate_limit, damit die Retry-Steuerung des Orchestrators unveraendert greift. 4. Stoerungen werden sichtbar. Waehrend einer Wartezeit meldet die Oberflaeche "KI-Dienst hat keine freie Kapazitaet, neuer Versuch in 15 Sekunden", sonst sieht die stehende Anzeige wie ein Haenger aus. Nach dem Lauf steht eine Zusammenfassung im Refresh-Protokoll, auch wenn der Lauf sonst glatt durchlief. 5. botocore laeuft im Modus 'adaptive' statt 'standard'. Es bremst sich bei Drosselung selbst ein und deckt die Sekunden ab, unsere Schleife die Zehnersekunden. Zeitliche Wirkung, gemessen am EU-Lauf der Ceuta-Lage (252 Sekunden, 15 Bedrock-Aufrufe): im stoerungsfreien Fall null, im betroffenen Lauf rund eine Minute mehr. Bei 0,6 Prozent Fehlerrate je Aufruf trifft das etwa jeden elften Lauf, im Mittel ueber alle Laeufe rund zwei Prozent. Gegenprobe mit einem echten Bedrock-Aufruf ueber den geaenderten Pfad: Antwort, Verbrauch und Kosten unveraendert, keine Stoerung protokolliert. Neu sind 23 Pruefungen, insgesamt laufen 179 ohne Netzzugriff und ohne Kosten. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Beschreibung
OSINT-Monitoringsystem
Sprachen
Python
50.3%
JavaScript
32.3%
CSS
10.2%
HTML
7.2%