Wenn ein Modell sein Kontingent erreicht

Jedes Coding-Modell hat eine Obergrenze: ein Abo-Fenster, ein Monatskontingent, ein Guthaben, ein Premium-Request-Budget. Erreicht das gepinnte Modell einer Aufgabe diese Wand, scheitert der Lauf ohne eigenes Verschulden.

SupaCloud behandelt das in zwei Schritten — und genau diese Trennung ist der Kern:

• Gleiche Klasse → automatisch. Die Aufgabe läuft auf einem gleichwertigen Modell derselben Klasse weiter (zum Beispiel einem anderen Flagship-Modell, gern auch bei einem anderen Anbieter). Sie müssen nichts tun.
• Andere Klasse → Ihre Entscheidung. Ist auch die eigene Klasse erschöpft, wechselt SupaCloud nicht still auf etwas Schwächeres. Die Aufgabe wartet an einem Freigabe-Gate und fragt Sie.

Achtung

Ein Klassenwechsel passiert nie automatisch und läuft auch nie in einen hinein: Ein unbeantwortetes Gate wartet unbegrenzt; die Aufgabe bleibt blockiert statt still degradiert zu werden.

Die Modellklassen

Klasse	Bedeutung
flagship	Die stärksten Reasoning-Modelle.
balanced	Die Arbeitspferd-Klasse für den Alltag.
fast	Günstige Modelle mit niedriger Latenz.
independent_review	Ein bewusst anbieterfremder Reviewer. Eine Rolle, keine Stärkestufe — daher ohne schwächere Zielklasse.

Jede Klasse hält eine geordnete, anbieterübergreifende Kette von Modellen. Bei einer Kontingent-Wand geht SupaCloud diese Kette der Reihe nach durch und nimmt das erste Modell, das jetzt wirklich nutzbar ist: Ihr Workspace hat eine Zugangsdatei für dessen Anbieter, dieses Konto hat noch Kontingent-Spielraum, und der Circuit-Breaker des Anbieters ist geschlossen.

Was Sie dabei sehen

1. Eine Zeile im Live-Feed. „Kontingent auf claude-fable-5 erschöpft — weiter mit gpt-5.6-sol (gleiche Klasse flagship)“. Dieselbe Zeile erreicht Ihr verknüpftes Telegram bzw. Discord, während Sie der Aufgabe folgen.

2. Ein Audit-Eintrag. Jede Entscheidung — Wechsel, Gate, erschöpfte Klasse, ausgeschöpftes Limit — steht unter Berichte → Audit samt der beteiligten Modelle.

3. Ein Routing-Vermerk. Bei einer aus dem Backlog dispatchten Aufgabe landet der Wechsel zusätzlich im Routing-Entscheidungslog der Operations-Sicht.

Wann gefragt wird

Die Freigabe erscheint in Ihrem gewohnten Freigaben-Posteingang (Web, approvals im Web-Terminal, /approvals in Telegram oder Discord) als Gate vom Typ Modellklassen-Wechsel:

Model class ‘flagship’ is exhausted (claude-fable-5 hit its quota and every equivalent model of that class is out of quota or unavailable). Fall back to the weaker ‘balanced’ class for this task? Rejecting leaves the task blocked on its own class.

• Freigeben — die Aufgabe startet binnen etwa einer Minute auf dem ersten nutzbaren Modell der schwächeren Klasse neu.
• Ablehnen — es bleibt alles, wie es ist. Nichts wird degradiert.

Hinweis

Ein Koordinator-Agent kann dieses Gate nicht für Sie beantworten. Agenten dürfen nur offene Fragen beantworten; ein Klassenwechsel liegt bewusst in einer Klasse, über die sie nicht entscheiden dürfen.

Tipp

Um zwischen beidem zu entscheiden, will man meist wissen, wann die Wand fällt. Öffne Berichte → Nutzung: die erschöpfte Fenster-Zeile trägt ihren eigenen Reset-Countdown, sodass ablehnen und warten eine bepreisbare Entscheidung wird. Ein rollierendes 5-Stunden-Fenster, das um 14:00 vollgelaufen ist, ist um 19:00 wieder frei — der Countdown sagt das, statt es raten zu lassen, und die Karte nennt dazu, wie frisch die Messung ist.

Grenzen gegen ein Weglaufen

• Höchstens zwei automatische Wechsel innerhalb der Klasse pro Aufgabe. Danach erscheint statt eines dritten Wechsels dasselbe Freigabe-Gate.
• Kein Hin und Her. Ein Modell, auf dem die Aufgabe schon lief, wird nie erneut vorgeschlagen.
• Eine Entscheidung pro Lauf. Ein nach einem Absturz wiederhergestellter Lauf kann dieselbe Aufgabe nicht zweimal umschalten.
• Unbekanntes Modell → kein Raten. Steht das gepinnte Modell in keiner Klassenkette, trifft SupaCloud keine Annahme über seine Klasse und weicht nicht aus; die Aufgabe scheitert wie bisher. Tragen Sie das Modell in die Kette Ihres Workspace ein, um den Fallback zu aktivieren.

Ketten für den Workspace anpassen

Die eingebauten Ketten sind eine sinnvolle Vorgabe, keine Policy. Ein Owner oder Admin des Workspace kann die Kette jeder Klasse ersetzen — etwa um die eigene Anbieterreihenfolge zu bevorzugen oder ein Modell zu ergänzen, das die Vorgabe nicht kennt.

In der Anwendung

1. Einstellungen → Modelle öffnen und zu Modell-Fallback-Ketten scrollen. Die Karte zeigt die Ketten, die dieser Workspace aktuell tatsächlich auflöst — Ihre Überschreibung dort, wo Sie eine gesetzt haben, sonst die eingebaute Kette.

2. Eine Klasse aufklappen (Flagship, Balanced, Fast, Unabhängige Zweitmeinung — die Klasse independent_review aus der Tabelle oben), um ihre geordneten Kandidaten zu sehen. Die Reihenfolge ist die Präferenz: Der erste nutzbare Eintrag gewinnt.

3. Je Zeile das Harness wählen, die anbieter-native Modell-ID eintragen und optional einen Effort festlegen (Effort der Aufgabe beibehalten lässt die Einstellung der Aufgabe unberührt). Mit den Pfeilen umsortieren, mit ✕ entfernen.

4. Speichern. Geschrieben werden nur die Klassen, die Sie wirklich angefasst haben — eine nicht geöffnete Klasse behält, was sie heute auflöst, inklusive künftiger Aktualisierungen der eingebauten Ketten. Auf Standard zurücksetzen löscht die gesamte Workspace-Überschreibung in einem Schritt.

Ein Mitglied sieht dieselbe Karte schreibgeschützt.

Hinweis

Alle Zeilen einer Klasse zu entfernen und zu speichern ist eine bewusste Aussage: Der automatische Fallback ist für diese Klasse dann aus, eine Kontingent-Wand geht dort direkt an das Freigabe-Gate.

Träger-Reihenfolge

Direkt unter den Ketten liegt die Karte Träger-Reihenfolge. Sie entscheidet, wie die Kalibrierung (siehe Die Reihenfolge aus Belegen vorschlagen lassen unten) die Kette einer Klasse über die Träger anordnet:

• Abos zuerst, API-Keys als letzte Reserve (die Vorgabe): Jedes Modell, das Ihr Workspace über ein verbundenes Abo mit gemessenem Spielraum erreicht (ein Google-, OpenAI- oder Anthropic-Abo), steht vor jedem Modell, das er nur über einen API-Key wie OpenRouter erreicht. Innerhalb der Gruppe entscheidet die Bewertung. Ein Abo ist ohnehin bezahlt, ein Lauf darauf kostet nichts extra, ein API-Key-Aufruf wird jedes Mal berechnet.
• Nur nach Bewertung, Träger egal: Allein die Bewertung ordnet die Kette; ein bezahltes Modell kann vor einem Abo-Modell stehen.

Die Wahl wird sofort gespeichert, der nächste Kalibrierlauf wendet sie an. Sie ändert nicht, über welche Route ein einzelnes Modell gestartet wird: Eine Abo-Route mit Spielraum gewinnt diese Wahl ohnehin.

Über die API

Dieselbe Überschreibung ist ein Feld auf PATCH /api/workspaces/{id}/settings:

{
  "model_fallback_chains": {
    "flagship": [
      { "agent": "codex", "model": "gpt-5.6-sol" },
      { "agent": "claude", "model": "claude-fable-5" }
    ]
  }
}

Eine nicht genannte Klasse behält ihre eingebaute Kette; ein leeres Array schaltet den automatischen Fallback für diese Klasse ab; "model_fallback_chains": null löscht die Überschreibung vollständig. Fehlerhafte Eingaben werden mit 400 abgewiesen — es wird nichts halb gespeichert. Die Lese-Seite desselben Endpunkts liefert sowohl Ihre rohe Überschreibung (model_fallback_chains) als auch das aufgelöste Ergebnis, mit dem die Laufzeit arbeitet (model_fallback_chains_effective).

Enger gefasst: ein einzelnes Agenten-Profil

Ein Agenten-Profil kann eigene Ketten unter retry_policy.model_fallback.chains tragen (gleiche Struktur), die für Aufgaben auf diesem Profil über den Workspace-Ketten liegen. Bearbeitbar unter Einstellungen → Agenten-Profile → Raw.

Weiterführend

• Agenten-Aktionen freigeben
• Nutzung und Budget verfolgen
• Autonomie-Level setzen

Die Reihenfolge aus Belegen vorschlagen lassen

Die Reihenfolge von Hand zu entscheiden heisst, ein Benchmark-Brett, eine Preisliste und die eigene Lauf-Historie gleichzeitig im Kopf zu haben. SupaCloud kann dieses Lesen übernehmen und eine Reihenfolge vorschlagen — als Vorschlag, nie als Änderung.

Einen Vorschlag anfordern

1. Unter Einstellungen → Modelle → Modell-Fallback-Ketten auf Aus Belegen kalibrieren. SupaCloud liest den Modellkatalog (Preise, Lebenszyklus), die öffentlichen Benchmark-Bretter und die eigene Telemetrie dieses Workspaces und berechnet eine vorgeschlagene Reihenfolge. Die externen Quellen werden nicht live abgerufen: eine Hintergrund-Aktualisierung holt sie einige Male am Tag in einen Snapshot, und die Vorschau zeigt das Alter jedes Snapshots. Jetzt aktualisieren (Admins, ratenbegrenzt) holt sie auf Wunsch — eine neue Reihung braucht danach trotzdem einen neuen Kalibrierlauf.

2. Die Vorschau spielt die Umordnung ab: die Liste öffnet in deiner aktuellen Reihenfolge und setzt sich in die vorgeschlagene, damit du siehst, was sich bewegt, statt zwei Listen zu vergleichen. Nochmal abspielen zeigt es erneut.

3. Jede Bewegung nennt ihren Grund und die Zahlen dahinter, jede mit Quelle und dem Datum dieser Messung — nicht dem des Laufs. Eine Bewegung, die sich auf eine Messung beruft und nichts belegt, wird auf ihrer Zeile markiert und im Kopf gezählt; das sind die Zeilen, die am genauesten zu lesen sind.

4. In die Ketten übernehmen schreibt den Vorschlag. Verwerfen verbucht dein Nein und ändert nichts.

Hinweis

Erneutes Öffnen der Vorschau zeigt den Lauf, den du bereits gelesen hast, nie einen frischen. Beim Öffnen neu zu rechnen hiesse, über ein Diff zu entscheiden, das du nie gesehen hast.

Achtung

Bearbeitest du die Ketten zwischen Anfordern und Übernehmen von Hand, wird das Übernehmen verweigert und die Ketten bleiben, wie du sie gelassen hast — der Vorschlag argumentiert über einen Zustand, den es nicht mehr gibt. Fordere einen frischen an.

Von welcher Route ein Preis stammt — und wann eine günstigere gewinnt

Dasselbe Modell wird oft zweimal verkauft: direkt vom Hersteller und weiterverkauft über einen Router wie OpenRouter, jeweils zum eigenen Satz. SupaCloud reiht und dispatcht auf dem Preis der Route, die dein Workspace tatsächlich benutzen würde — der günstigsten, für die du eine Zugangsdatei hast, Wiederverkäufer-Aufschlag eingerechnet — und nicht auf dem Listenpreis des Herstellers. Die Vorschlagszeile nennt die Route, aus der die Zahl stammt; eine Zahl, die auf der Preisseite des Herstellers falsch aussieht, ist es deshalb meist nicht.

Eine günstigere Route bekommt das Modell nicht automatisch. Sie muss um mindestens 15 % günstiger sein, bevor sie die Route verdrängt, die deine Kette schon benutzt. Das ist dieselbe Schwelle, die entscheidet, ob ein Modell einen Wechsel wert ist — es gibt also eine Regel zu merken statt zweier:

• Gemini 3.7 Flash mit 3,75 direkt gegen 1,875 weiterverkauft spart 50 % — die Route wechselt.
• Eine Route, die 5 % günstiger ist, bewegt nichts.
• Genau 15 % wechselt.
• Die Regel gilt in beide Richtungen: eine Kette, die schon über einen Router läuft, wird von einem 5-%-Vorteil auch nicht zum Hersteller zurückgezogen.

Das ist keine Rabatt-Erkennung

Die Schwelle weiß nicht, ob ein Preis eine Aktion ist. Kein Anbieter veröffentlicht, wann ein Preis endet, und SupaCloud rät nicht — es behauptet nie, ein Preis sei befristet.

Was die Schwelle tut: sie macht es billig, falsch zu liegen. Ein kleiner, kurzlebiger Vorteil bewegt erst gar keine Kette, also gibt es nichts zurückzubewegen, wenn er verschwindet. Ein großer Vorteil wechselt weiterhin — und wechselt zurück, wenn er endet. Wenn du eine Route unabhängig vom Preis festnageln willst, setze die Kette von Hand; die Kalibrierung schlägt immer nur vor.

Wenn die Belege für eine Reihung nicht reichen

Der Preis allein reiht keine Modelle. Findet ein Lauf gar keine Qualitäts- und keine Geschwindigkeitsmessung — alle Benchmark-Quellen ausgefallen oder unkonfiguriert, keine brauchbare Telemetrie —, sagt die Vorschau das, statt eine preissortierte Liste vorzuschlagen: die aktuellen Ketten bleiben bestehen; entfernt wird nur, was unerreichbar, nicht konform, ohne Tool-Aufrufe oder vom Anbieter zurückgezogen ist. Erst die in der Vorschau genannten Quellen reparieren, aktualisieren und neu kalibrieren. Eine Bewegung, die nur ihr Preis trägt, ist auf ihrer Zeile mit nur preis-belegt markiert.

Eine Qualitätsuntergrenze urteilt nur auf ihrer eigenen Skala

Die Klasse fast trägt eine Qualitätsuntergrenze: ein Modell, dessen Intelligenz-Messwert darunter liegt oder das gar keinen hat, bekommt dort keinen Platz, was immer es kostet. Ein Benchmark-Index wird von seinem Herausgeber versioniert, und eine neue Version verschiebt die Zahl jedes Modells auf einmal — deshalb nennt die Untergrenze die Skala, auf der sie gesetzt wurde, und ein Messwert auf einer anderen Skala (oder ohne jede Skalenangabe) wird nicht beurteilt: die Klasse behält ihre aktuelle Kette, und die Vorschau nennt beide Skalen. Setze Wert und Skala der Untergrenze zusammen, um sie wieder scharf zu stellen. Ein Modell, das wegen der Untergrenze eine Kette verlässt, zeigt seinen Messwert und die Untergrenze auf seiner Zeile — es wird nie als neu bewertet gemeldet. Ein Modell, das ein anderes bei Preis und Qualität schlägt, verdrängt es nur aus den Klassen, die das andere selbst betreten kann; wo die Untergrenze das billigere abweist, behält das teurere seinen Platz.

Manche Zahlen bleiben in deiner Instanz

Eine Zahl mit der Marke nur intern stammt aus einer Quelle, deren Lizenz die interne Nutzung erlaubt, die Weitergabe aber nicht. Du darfst sie lesen; gib sie nicht ausserhalb deiner Instanz weiter.

Von selbst übernehmen lassen

Ein Workspace auf Autonomie Autonom oder höher lässt einen täglichen Lauf einen Vorschlag ohne Rückfrage übernehmen — aber nur eine reine Umordnung, und nur wenn nichts widerspricht:

• ein Modell aufzunehmen, das die Kette nie hielt, oder eines zu entfernen, wartet immer auf dich;
• eine Bewegung ohne Beleg stoppt den Lauf;
• eine Quelle, die an dem Tag nicht geantwortet hat, stoppt den Lauf, weil die Rangfolge dann auf weniger stand, als sie sollte;
• der globale Dispatch-Schalter des Betreibers stoppt ihn, wie alles, was allein handelt.

Jeder unbeaufsichtigte Ausgang wird ins Audit-Log geschrieben — auch die Läufe, die nichts geändert haben, mit dem Grund. Unter Autonom läuft die Kalibrierung weiterhin auf Knopfdruck; nur das automatische Übernehmen ist aus.