Die Auswahl im Router wirkt zunächst eindeutig: zuerst die bevorzugte Stufe, bei einem Fehler die nächste.
Das Problem: Neue Stufe, gleicher Aufruf
Ein Router kann mehrere Modellstufen anbieten. Sind zwei Stufen auf denselben Anbieter, dasselbe Modell und dieselbe Abrechnungsart festgelegt, ist der Wechsel nur nominell. Nach einem ausgeschöpften Aufruf entsteht dadurch ein weiterer Versuch auf derselben Kombination.
Die Korrektur: Tatsächliche Kombination vergleichen
Die dokumentierte Änderung verhindert erneute Aufrufe derselben Anbieter-Modell-Abrechnungskombination unter einer anderen Stufe. Tatsächlich andere Modelle oder Anbieter bleiben möglich, soweit die Regeln für die Datenklasse dies erlauben. Ein fehlgeschlagener Abonnementaufruf löst keinen automatischen Wechsel auf eine kostenpflichtige API aus.
Fehlerdiagnose ohne Vermutungen
Die Diagnose unterscheidet Parsing, Modell, native Werkzeuge, Providerstatus und abgelehnte Aktionsvorschläge. Private Antworttexte werden nicht als Diagnoseprosa protokolliert. Die Notiz nennt einen UNAVAILABLE-Status; daraus wurde ausdrücklich keine nachgewiesene Quotenerschöpfung abgeleitet. Die Lehre: Ausweichrouten müssen technisch verschieden sein, und ein Fehlercode ist noch keine belegte Ursache. Eine Erfolgsquote nach dem Patch ist nicht dokumentiert.
Warum eine Stufenbezeichnung nicht genügt
Die Auswahl im Router wirkt zunächst eindeutig: zuerst die bevorzugte Stufe, bei einem Fehler die nächste. Die Konfiguration kann aber mehrere Stufen auf dasselbe festgelegte Modell abbilden. Dann ändert sich nur die Bezeichnung, nicht der entfernte Aufruf. Ein zweiter Versuch verbraucht erneut Zeit und möglicherweise Kontingent, ohne eine neue Ausweichmöglichkeit zu nutzen. Besonders tückisch ist das bei abonnementgebundenen Modellen: Ein Wechsel der logischen Qualitätsstufe ist noch kein Wechsel des gebuchten Zugangs. Die Identität der Route muss deshalb aus den tatsächlich verwendeten Werten entstehen.
Anbieter, Modell und Abrechnung gemeinsam vergleichen
Die korrigierte Auswahl betrachtet die Kombination aus Provider, Modell und Billing-Modus. Das Codefenster zeigt einen verkürzten Selector: Bereits versuchte Kombinationen werden in einer Menge gesammelt und später übersprungen. Ein abweichender Provider oder ein anderes Modell ist ein echter neuer Kandidat. Trotzdem muss vor dem Aufruf erneut geprüft werden, ob die Datenklasse dort verarbeitet werden darf und ob diese Abrechnungsart freigegeben ist. Der Selector allein entscheidet nicht über Datenschutz oder Kosten. Er verhindert nur, dass dieselbe Verbindung unter einem anderen Namen nochmals als Fallback ausgegeben wird.
from dataclasses import dataclass
@dataclass(frozen=True)
class RouteKey:
provider: str
model: str
billing: str
def distinct_candidates(routes, attempted):
for route in routes:
key = RouteKey(route.provider, route.model, route.billing)
if key in attempted:
continue
attempted.add(key)
yield route
# Vor jedem tatsächlichen Aufruf zusätzlich:
# Datenklasse, Werkzeugrechte und Billing-Freigabe prüfen.Nicht jede Störung ist eine Quote
Bei der Fehlersuche wurden Quoteninformationen und Fehlerkategorien getrennt gelesen. Ein UNAVAILABLE-Status belegt keine erschöpfte Quote. Auch ein langer Aufruf kann aus Providerwartezeit, nativen Wiederholungen oder Transportproblemen entstehen. Deshalb protokolliert die Anwendung feste Kategorien für Parsing, Modell, Werkzeug und Providerstatus, statt private Fehlerprosa ungefiltert zu speichern. Ein Fehlertyp darf nicht stillschweigend zu einer anderen Abrechnungsart führen. Der gewählte Abonnementzugang bleibt eine Grenze, auch wenn ein kostenpflichtiger API-Schlüssel technisch vorhanden wäre.
Technische Referenz: Python: Unveränderliche Routenschlüssel.
Was wir am Routing prüfen
Ein sinnvoller Test konfiguriert zwei Stufen auf dieselbe Kombination und eine dritte auf ein wirklich anderes Ziel. Nach dem ersten Fehlschlag darf die zweite Stufe keinen weiteren identischen Request starten. Die dritte wird nur unter den bestehenden Regeln angeboten. Danach werden ein fehlender alternativer Anbieter, eine unzulässige Datenklasse und ein ausdrücklich nicht freigegebener Billing-Modus geprüft. Der relevante Nachweis ist die Anzahl und Identität der tatsächlich gestarteten Aufrufe. Eine hübschere Routermeldung ohne diese Prüfung würde das Problem lediglich verdecken. Für begrenzte externe APIs ergänzt der frühere Beitrag zu Rate-Limits diese Perspektive.
Weiterlesen: Architektur-Log: API-Rate-Limits bei parallelen Requests.