> ## Documentation Index > Fetch the complete documentation index at: https://docs.flexinference.com/llms.txt > Use this file to discover all available pages before exploring further. # Deadline-Routing > Das Feld start_within, der Flex-Wettlauf und die automatische Eskalation zum Standard. `start_within` ist bei jeder FlexInference-Anfrage erforderlich. Es legt fest, wie lange der Router auf den Start der Anfrage warten darf. Verwenden Sie `default`, `priority` oder `auto`, wenn Sie direkt eine Provider-Stufe wünschen. Verwenden Sie eine Dauer, wenn FlexInference zuerst Flex bei einem Flex-fähigen Modell versuchen soll und dann auf Standard eskaliert, wenn Flex nicht rechtzeitig starten kann. Das Feld hat vier Formen. ## Die vier Formen ```json theme={null} { "start_within": "default" } ``` Leitet zur **Standard**-Echtzeitstufe des Providers zum Standardpreis weiter: `default` von OpenAI, `standard` von Gemini oder `standard_only` von Anthropic. Funktioniert mit jedem Modell. ```json theme={null} { "start_within": "priority" } ``` Leitet zur **Prioritäts**-Stufe von OpenAI für den schnellsten Start weiter. Verwenden Sie dies für interaktive, latenzkritische Pfade. Priority ist die teuerste Stufe. Funktioniert mit jedem Modell. Bei Anthropic ist dies **Best-Effort**, da Claude keine Prioritätsstufe hat; wir ordnen es Anthropic's `auto` zu. ```json theme={null} { "start_within": "auto" } ``` Lässt den Provider die Stufe wählen. Bei OpenAI ist dies `service_tier: auto`; bei Anthropic wird es auf Anthropic's `auto` abgebildet. Dies ist die Auto-Stufe des Providers, nicht das FlexInference Auto-Routing. Funktioniert auf **OpenAI und Anthropic**. Gemini hat keine Auto-Stufe, daher gibt `auto` bei einem Gemini-Modell `400 auto_unsupported_for_gemini` zurück. ```json theme={null} { "start_within": "00h-00m-30s" } ``` Fordert den **Flex-Wettlauf** (siehe unten) an jedem Endpunkt an, einschließlich `/v1/responses`, `/v1/chat/completions`, `/v1/interactions` und `/v1/messages`. FlexInference versucht zuerst die günstigere Flex-Stufe und wechselt nur dann zum Standard, wenn Flex nicht innerhalb des Zeitfensters starten kann. Die Dauer ist die maximale Wartezeit für den Start der Anfrage, geschrieben als `HHh-MMm-SSs` mit zwei Ziffern pro Feld. Sie muss zwischen **5 Sekunden und 10 Minuten** (`00h-00m-05s` bis `00h-10m-00s`) liegen. `default`, `priority` und `auto` leiten **jedes** Modell an seinen Provider (OpenAI, Gemini oder Anthropic) weiter. Nur eine Dauer fordert den Flex-Wettlauf an. Wenn das Modell Flex nicht verwenden kann, gibt eine Dauer `400` (`flex_unsupported_for_anthropic` oder `flex_model_not_capable`) zurück; verwenden Sie stattdessen einen Stufenwert. Der Flex-Wettlauf ist **nicht auf Claude verfügbar**, da Anthropic keine Flex-Stufe hat. Eine Dauer `start_within` bei einem `claude-*`-Modell gibt `400 flex_unsupported_for_anthropic` zurück. Anthropic funktioniert weiterhin mit `default`, `priority` und `auto` Stufen-Proxy-Anfragen. Eine Dauer `start_within` kann nicht mit nativen Chat Completions-Parametern wie `logprobs` oder `seed` kombiniert werden. Entfernen Sie diese Parameter oder verwenden Sie stattdessen `default`, `priority` oder `auto`. ## Der Flex-Wettlauf Mit einer Dauer versucht FlexInference zuerst die **Flex**-Stufe des Providers (OpenAI oder Gemini). Flex wird zum halben Standardtarif abgerechnet, aber die Kapazität ist Best-Effort. Der Router wartet, bis die Upstream-Anfrage innerhalb Ihres Fensters startet: FlexInference sendet Ihre Anfrage an die Flex-Stufe und wartet, bis der Provider bestätigt, dass sie ausgeführt wird, alles innerhalb der von Ihnen festgelegten Zeit. Wenn der Provider die Anfrage rechtzeitig startet, legt FlexInference sie fest. Ihre Antwort wird normal gestreamt und zu Flex-Tarifen abgerechnet. Die Antwort zeigt `"service_tier": "flex"`. Wenn Flex nicht rechtzeitig starten kann, bricht FlexInference ab und sendet die Anfrage an Standard. Dies ist eine Eskalation von der günstigeren Flex- zur Standard-Stufe, keine Herabstufung. Die Antwort zeigt `"service_tier": "default"` (OpenAI) oder `"standard"` (Gemini). Die Eskalation auf Standard erfolgt nur, bevor Flex startet, wenn Flex einen `429` (keine Kapazität), einen beliebigen `5xx`, einen Vor-Start-Fehler oder keinen Start vor der Frist zurückgibt. Der Wechsel von Flex zu Standard ist die **einzige** Stufenänderung, die FlexInference vornimmt. Ein Provider-Fallback, bei dem Sie ein optionales `provider`-Array festlegen und FlexInference die nächste Route versucht, nachdem eine Route vorübergehend fehlschlägt, ändert die Route, niemals die Stufe oder das Modell. Ein fehlender Schlüssel für eine von Ihnen benannte Route ist ein Konfigurationsfehler und keine vorübergehende Störung, daher wird ein `400` zurückgegeben, anstatt durchzufallen. Siehe [Provider-Routing](/de/models#every-route-you-name-needs-its-key). Wählen Sie die längste Dauer, die Ihre UX tolerieren kann. Längere Fenster geben Flex mehr Zeit zum Gewinnen, was den Anteil der Anfragen erhöht, die zum günstigeren Tarif bedient werden. ## Das Ergebnis lesen Erfolgreiche `200`-Antworten enthalten Flex-Ergebnis-Header an jedem Endpunkt, sowohl für Streaming- als auch für Nicht-Streaming-Aufrufe. Fehlerantworten verwenden stattdessen den Fehlerkörper. | Header | Bedeutung | | ---------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `x-flexinference-flex-requested` | `true`, wenn der Aufrufer eine Dauer `start_within` gesendet hat; `false`, wenn der Aufrufer `default`, `priority` oder `auto` gesendet hat. | | `x-flexinference-flex-applied` | `true` nur, wenn Flex die Antwort bedient hat. | | `x-flexinference-flex-reason` | Das maschinenlesbare Ergebnis. Siehe die Werte unten. | | `x-flexinference-provider-surface` | Die vom Planer ausgewählte Provider-Oberfläche. Die Werte sind `openai.responses`, `openai.chat`, `gemini.interactions` und `anthropic.messages`. Dies kann vom Aufrufer-Endpunkt abweichen. Ein `/v1/chat/completions`-Aufruf mit einem OpenAI-Modell meldet `openai.responses`, es sei denn, ein natives Chat-Passthrough ist erforderlich, in welchem Fall es `openai.chat` meldet. | Die Live-Werte von `x-flexinference-flex-reason` sind: | Grund | Bedeutung | | ---------------- | ----------------------------------------------------------------------------------------------------------------------------------------------- | | `not_requested` | Die Anfrage verwendete `default`, `priority` oder `auto`; es wurde kein Flex-Wettlauf angefordert. | | `flex_committed` | Der Flex-Wettlauf wurde festgelegt. Die Antwort zeigt `service_tier: "flex"` und `x-flexinference-flex-applied: true`. | | `flex_lost_race` | Die Anfrage verwendete eine Dauer bei einem Flex-fähigen Modell, aber Flex startete nicht rechtzeitig und die Anfrage fiel auf Standard zurück. | Eine Dauer, die keinen Flex-Wettlauf ausführen kann, gibt `400` zurück (`flex_unsupported_for_anthropic` bei einem `claude-*`-Modell, `flex_model_not_capable` bei einem nicht Flex-fähigen OpenAI/Gemini-Modell); die Header-Gründe beschreiben nur Anfragen, die Flex ausgeführt haben oder es nicht angefordert haben. ## Wenn der Flex-Pool nicht verfügbar ist Die Flex-Stufe verwendet eine gemeinsam genutzte, Best-Effort-Kapazität. Bevor eine Anfrage startet, kann Flex einen `429` zurückgeben, wenn keine Kapazität vorhanden ist, einen beliebigen `5xx` zurückgeben, vor dem Start fehlschlagen oder die Frist verpassen. FlexInference sendet die Anfrage dann an Standard. In seltenen Fällen schlägt Flex *nachdem* die Anfrage akzeptiert und mit dem Streaming begonnen hat, fehl. FlexInference legt diesen Fehler offen. Bei einer Streaming-Anfrage erhalten Sie ein terminales `response.failed`-Ereignis. Bei einer Nicht-Streaming-Anfrage erhalten Sie einen `502`. Es wird nach der Festlegung kein erneuter Versuch unternommen, da dies eine unvollständige Anfrage maskieren könnte. Wenn dies auftritt, **versuchen Sie es erneut**, oder verwenden Sie `default`, `priority` oder `auto`, um Flex zu überspringen. ## Transport-Wiederholung Der Flex-Wettlauf entscheidet, welche Stufe Ihre Anfrage bedient. Die Transport-Wiederholung entscheidet, was passiert, wenn diese Stufe nicht startet. Fügen Sie ein optionales `retry`-Objekt hinzu, und FlexInference wartet und versucht die festgelegte Stufe bei einem vorübergehenden Upstream-Fehler erneut, anstatt Ihnen den Fehler zurückzugeben. ```json theme={null} { "retry": { "count": 2 } } ``` | Feld | Erforderlich | Werte | Bedeutung | | --------- | ------------ | ------------------------------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------- | | `count` | ja | Ganzzahl, `1` bis `5` | Erneute Versuche der festgelegten Stufe, nachdem der erste Versuch fehlgeschlagen ist. | | `backoff` | nein | `"exponential"` (Standard) oder `"linear"` | Das Warteverhalten zwischen den Versuchen. Exponential beginnt bei 0,5s und verdoppelt sich bis zu 8s; linear fügt jedes Mal 0,5s hinzu, bis zu 8s. | | `jitter` | nein | Boolean (Standard `true`) | Verteilt die Wartezeit, um Bursts zu glätten. Jitter verkürzt eine Wartezeit immer nur, verlängert sie nie. | Ein ungültiges `retry` gibt `400` [`invalid_retry`](/de/errors#invalid_retry) zurück. FlexInference versucht nur einen echten Vor-Commit-Transportfehler von der festgelegten Stufe erneut: einen echten `429`, einen echten `5xx` oder eine Verbindung, die nie geöffnet wurde ([`upstream_unavailable`](/de/errors#upstream_unavailable)). Es versucht keinen Client `4xx`, einen Upstream-Authentifizierungsfehler ([`upstream_auth_failed`](/de/errors#upstream_auth_failed)), einen Upstream-Timeout ([`upstream_timeout`](/de/errors#upstream_timeout)) oder eine vom Client abgebrochene Anfrage erneut. Diese schlagen entweder beim erneuten Versuch auf die gleiche Weise fehl oder bedeuten, dass der Aufrufer bereits weg ist. Retry versucht die Stufe erneut, die Ihre Anfrage festgelegt hat, nicht den Flex-Abschnitt. Bei einer `default`-, `priority`- oder `auto`-Anfrage ist dies die von Ihnen benannte Stufe. Bei einer Daueranfrage, die den Flex-Wettlauf verliert, ist dies die Standardstufe, auf die Sie eskaliert haben. Der Flex-Versuch und die Eskalation sind die eigene Arbeit des Flex-Wettlaufs und zählen niemals gegen `count`. Das Eskalieren einer Stufe und das erneute Versuchen derselben Stufe sind separate Schritte, die sich verketten: Flex verliert gegen Standard, dann kann Standard sich selbst erneut versuchen. Wenn der Provider einen `Retry-After`-Header sendet, wartet FlexInference so lange anstelle des Backoff-Zeitplans, begrenzt auf 60 Sekunden, damit ein schlechter Wert Ihre Anfrage nicht blockieren kann. Retry ist nur vor dem Commit. Es stoppt in dem Moment, in dem eine Stufe festgelegt wird, was die `200`-Statuszeile sowohl für Streaming- als auch für Nicht-Streaming-Aufrufe ist. Sobald das erste Byte auf dem Weg zu Ihnen ist, versucht FlexInference niemals erneut, dieselbe Regel, die der Flex-Wettlauf nach dem Commit befolgt. Ein Fehler mitten im Stream oder ein Nicht-Streaming- `502` nach einem festgelegten `200` wird an Sie weitergeleitet. Server-seitiges `retry` ist getrennt von jeder Wiederholungsschleife in Ihrem Client, und die beiden stapeln sich. Die FlexInference SDKs versuchen nicht erneut, aber ein Standard-OpenAI- oder Anthropic-SDK versucht standardmäßig zweimal erneut. Ein Client, der zweimal zusätzlich zu einem Server-`count` von `3` erneut versucht, führt zu bis zu sechs Upstream-Versuchen, da jeder Client-Versuch ein volles Server-Budget ausführt. Wenn Sie `retry` festlegen, stempelt FlexInference `x-flexinference-retries` auf die Antwort mit der Anzahl der durchgeführten erneuten Versuche, sodass Sie die `max_retries` Ihres Clients reduzieren können. ## Abrechnung Mit BYOK verwendet FlexInference Ihren gespeicherten verschlüsselten Provider-Schlüssel serverseitig; Sie senden keine Provider-Schlüssel pro Anfrage. Ihr Provider rechnet Ihr Konto mit dem Tarif der Stufe ab, die die Anfrage bedient hat. Sie zahlen Flex-Tarife, wenn Flex festgelegt wird, und Standardtarife nach der Eskalation. Ein Flex-Versuch kann einige Token verbrauchen, bevor er fehlschlägt. Ihr Provider rechnet diese Nutzung genauso ab, wie er es tun würde, wenn Sie Flex direkt aufrufen würden, und FlexInference schließt sie in die Nutzung ein. FlexInference fügt Ihren Token keinen Aufschlag hinzu. Es berechnet 20 % des Geldes, das es Ihnen spart, und berechnet nichts, wenn es keine Einsparungen gibt. ## Was FlexInference ändert FlexInference kann die Stufe ändern. Es ändert nicht die Bedeutung Ihrer Anfrage oder das Ergebnis des Providers. Es schreibt niemals den Status oder die Nachricht eines Providers um. Es normalisiert nur den Fehler-Envelope: Ein Fehler wird in der Form des von Ihnen aufgerufenen Endpunkts zurückgegeben (OpenAI bei Antworten und Chat, Anthropic bei Nachrichten, Google bei Interaktionen), der den Status und die Nachricht des Providers enthält, damit Ihr SDK ihn parsen kann. Siehe [Fehler](/de/errors). `start_within` ist **erforderlich**. Ohne es gibt die Anfrage `400 missing_start_within` zurück, auch bei einem einfachen OpenAI SDK, das auf unsere Basis-URL zeigt. Wenn Sie einen Wert senden, den FlexInference nicht lesen kann, erhalten Sie `invalid_start_within`. Gültige Werte sind `"default"`, `"priority"`, `"auto"` oder eine Dauer wie `"00h-00m-30s"`. Das bloße Wort `standard` war früher erlaubt und ist es nicht mehr, senden Sie stattdessen `default`. Eine vollständige Liste finden Sie unter [Fehler](/de/errors).