> ## 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.

# Enrutamiento por plazo

> El campo start_within, la carrera flex y la escalada automática a estándar.

`start_within` es obligatorio en cada solicitud de FlexInference. Establece cuánto tiempo puede esperar el enrutador a que la solicitud comience. Utilice `default`, `priority` o `auto` cuando desee un nivel de proveedor directamente. Utilice una duración cuando desee que FlexInference intente primero `flex` en un modelo compatible con `flex`, y luego escale a `standard` si `flex` no puede comenzar a tiempo.

El campo tiene cuatro formas.

## Las cuatro formas

<Tabs>
  <Tab title="default">
    ```json theme={null}
    { "start_within": "default" }
    ```

    Enruta al nivel en tiempo real **estándar** del proveedor con precios estándar: `default` de OpenAI, `standard` de Gemini o `standard_only` de Anthropic. Funciona con cualquier modelo.
  </Tab>

  <Tab title="priority">
    ```json theme={null}
    { "start_within": "priority" }
    ```

    Enruta al nivel **priority** de OpenAI para el inicio más rápido. Úselo para rutas interactivas y críticas en cuanto a latencia. `priority` es el nivel más caro. Funciona con cualquier modelo. En Anthropic, esto es de **mejor esfuerzo** porque Claude no tiene un nivel `priority`; lo mapeamos al `auto` de Anthropic.
  </Tab>

  <Tab title="auto">
    ```json theme={null}
    { "start_within": "auto" }
    ```

    Permite que el proveedor elija el nivel. En OpenAI, esto es `service_tier: auto`; en Anthropic, se mapea al `auto` de Anthropic. Este es el nivel `auto` del proveedor, no el enrutamiento automático de FlexInference. Funciona en **OpenAI y Anthropic**. Gemini no tiene un nivel `auto`, por lo que `auto` en un modelo Gemini devuelve `400 auto_unsupported_for_gemini`.
  </Tab>

  <Tab title="una duración">
    ```json theme={null}
    { "start_within": "00h-00m-30s" }
    ```

    Solicita la **carrera flex** (abajo) en cada endpoint, incluyendo `/v1/responses`, `/v1/chat/completions`, `/v1/interactions` y `/v1/messages`. FlexInference intenta primero el nivel `flex` más económico y solo pasa a `standard` cuando `flex` no puede comenzar dentro del plazo. La duración es el tiempo máximo de espera para que la solicitud comience, escrita como `HHh-MMm-SSs` con dos dígitos por campo. Debe estar entre **5 segundos y 10 minutos** (`00h-00m-05s` a `00h-10m-00s`).
  </Tab>
</Tabs>

`default`, `priority` y `auto` proxy **cualquier** modelo a su proveedor (OpenAI, Gemini o Anthropic). Solo una duración solicita la carrera `flex`. Si el modelo no puede usar `flex`, una duración devuelve `400` (`flex_unsupported_for_anthropic` o `flex_model_not_capable`); use un valor de nivel en su lugar.

<Note>
  La carrera `flex` **no está disponible en Claude** porque Anthropic no tiene un
  nivel `flex`. Una duración `start_within` en un modelo `claude-*` devuelve `400
      flex_unsupported_for_anthropic`. Anthropic sigue funcionando con solicitudes de
  proxy de nivel `default`, `priority` y `auto`.
</Note>

<Note>
  Una duración `start_within` no se puede combinar con parámetros de Chat
  Completions solo nativos como `logprobs` o `seed`. Elimine esos parámetros o
  use `default`, `priority` o `auto` en su lugar.
</Note>

## La carrera flex

Con una duración, FlexInference intenta primero el nivel **flex** del proveedor (OpenAI o Gemini). `flex` se factura a la mitad de la tarifa estándar, pero la capacidad es de mejor esfuerzo. El enrutador espera a que la solicitud *upstream* comience dentro de su plazo:

<Steps>
  <Step title="Iniciar flex">
    FlexInference envía su solicitud al nivel `flex` y espera a que el proveedor
    confirme que se está procesando, todo dentro del tiempo que usted estableció.
  </Step>

  <Step title="Confirmar flex">
    Si el proveedor inicia la solicitud a tiempo, FlexInference la confirma. Su
    respuesta se transmite de vuelta normalmente, facturada a tarifas `flex`. La
    respuesta muestra `"service_tier": "flex"`.
  </Step>

  <Step title="Escalar a estándar">
    Si `flex` no puede comenzar a tiempo, FlexInference la cancela y envía la
    solicitud a `standard`. Esto es una escalada del `flex` más económico a
    `standard`, no una degradación. La respuesta muestra `"service_tier":
            "default"` (OpenAI) o `"standard"` (Gemini).
  </Step>
</Steps>

La escalada a `standard` ocurre solo antes de que `flex` comience, cuando `flex` devuelve un `429` (sin capacidad), cualquier `5xx`, un fallo previo al inicio, o no inicia antes del plazo. El cambio de `flex` a `standard` es el **único** cambio de nivel que realiza FlexInference. Un *fallback* de proveedor, donde usted establece un array `provider` opcional y FlexInference intenta la siguiente ruta después de que una ruta falla transitoriamente, cambia la ruta, nunca el nivel o el modelo. Una clave faltante para cualquier ruta que haya nombrado es un error de configuración en lugar de una falla transitoria, por lo que devuelve un `400` en lugar de continuar. Consulte [enrutamiento de proveedores](/es/models).

<Info>
  Elija la duración más larga que su UX pueda tolerar. Plazos más largos le dan a
  `flex` más tiempo para ganar, aumentando la proporción de solicitudes atendidas
  a la tarifa más económica.
</Info>

## Lectura del resultado

Las respuestas `200` exitosas incluyen encabezados de resultado de `flex` en cada endpoint, tanto para llamadas *streaming* como no *streaming*. Las respuestas de error utilizan el cuerpo del error en su lugar.

| Encabezado                         | Significado                                                                                                                                                                                                                                                                                                                                                                                  |
| ---------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `x-flexinference-flex-requested`   | `true` cuando el emisor envió una duración `start_within`; `false` cuando el emisor envió `default`, `priority` o `auto`.                                                                                                                                                                                                                                                                    |
| `x-flexinference-flex-applied`     | `true` solo cuando `flex` atendió la respuesta.                                                                                                                                                                                                                                                                                                                                              |
| `x-flexinference-flex-reason`      | El resultado legible por máquina. Consulte los valores a continuación.                                                                                                                                                                                                                                                                                                                       |
| `x-flexinference-provider-surface` | La superficie del proveedor seleccionada por el planificador. Los valores son `openai.responses`, `openai.chat`, `gemini.interactions` y `anthropic.messages`. Esto puede diferir del endpoint del emisor. Una llamada a `/v1/chat/completions` con un modelo OpenAI reporta `openai.responses` a menos que se requiera el *passthrough* nativo de Chat, en cuyo caso reporta `openai.chat`. |

Los valores en vivo de `x-flexinference-flex-reason` son:

| Razón            | Significado                                                                                                                                 |
| ---------------- | ------------------------------------------------------------------------------------------------------------------------------------------- |
| `not_requested`  | La solicitud utilizó `default`, `priority` o `auto`; no se solicitó una carrera `flex`.                                                     |
| `flex_committed` | La carrera `flex` se confirmó. La respuesta muestra `service_tier: "flex"` y `x-flexinference-flex-applied: true`.                          |
| `flex_lost_race` | La solicitud utilizó una duración en un modelo compatible con `flex`, pero `flex` no comenzó a tiempo y la solicitud recurrió a `standard`. |

<Note>
  Una duración que no puede ejecutar una carrera `flex` devuelve `400`
  (`flex_unsupported_for_anthropic` en un modelo `claude-*`,
  `flex_model_not_capable` en un modelo OpenAI/Gemini no compatible con `flex`);
  las razones del encabezado describen solo las solicitudes que ejecutaron `flex`
  o no lo solicitaron.
</Note>

## Cuando el pool flex no está disponible

El nivel `flex` utiliza capacidad compartida y de mejor esfuerzo. Antes de que una solicitud comience, `flex` puede devolver un `429` cuando no hay capacidad, devolver cualquier `5xx`, fallar antes del inicio o no cumplir el plazo. FlexInference luego envía la solicitud a `standard`.

En casos raros, `flex` falla *después* de que la solicitud ha sido aceptada y ha comenzado a transmitirse. FlexInference expone esa falla. En una solicitud *streaming*, usted recibe un evento `response.failed` terminal. En una solicitud no *streaming*, usted recibe un `502`. No reintenta después de la confirmación porque eso podría enmascarar una solicitud incompleta. Si esto ocurre, **reintente**, o use `default`, `priority` o `auto` para omitir `flex`.

## Reintento de transporte

La carrera `flex` decide qué nivel atiende su solicitud. El reintento de transporte decide qué sucede cuando ese nivel no puede iniciar. Agregue un objeto `retry` opcional y FlexInference esperará y volverá a intentar el nivel establecido en caso de una falla *upstream* transitoria, en lugar de devolverle el error.

```json theme={null}
{ "retry": { "count": 2 } }
```

| Campo     | Obligatorio | Valores                                       | Significado                                                                                                                   |
| --------- | ----------- | --------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------- |
| `count`   | sí          | entero, de `1` a `5`                          | Reintentos del nivel establecido después de que falla el primer intento.                                                      |
| `backoff` | no          | `"exponential"` (predeterminado) o `"linear"` | El patrón de espera entre intentos. Exponencial comienza en 0.5s y se duplica hasta 8s; lineal añade 0.5s cada vez, hasta 8s. |
| `jitter`  | no          | booleano (predeterminado `true`)              | Distribuye la espera para suavizar las ráfagas. El *jitter* solo acorta una espera, nunca la alarga.                          |

Un `retry` inválido devuelve `400` [`invalid_retry`](/es/errors#invalid_retry).

FlexInference solo reintenta una falla de transporte genuina previa a la confirmación del nivel establecido: un `429` real, un `5xx` real o una conexión que nunca se abrió ([`upstream_unavailable`](/es/errors#upstream_unavailable)). No reintenta un `4xx` del cliente, una falla de autenticación *upstream* ([`upstream_auth_failed`](/es/errors#upstream_auth_failed)), un *timeout* *upstream* ([`upstream_timeout`](/es/errors#upstream_timeout)) o una solicitud que el cliente canceló. Esos fallan de la misma manera en un reintento o significan que el emisor ya no está.

El reintento vuelve a intentar el nivel que estableció su solicitud, no la rama `flex`. En una solicitud `default`, `priority` o `auto`, ese es el nivel que usted nombró. En una solicitud de duración que pierde la carrera `flex`, es el nivel `standard` al que escaló. El intento `flex` y la escalada son trabajo propio de la carrera `flex` y nunca cuentan contra `count`. Escalar un nivel y reintentar el mismo nivel son pasos separados que se encadenan: `flex` pierde contra `standard`, luego `standard` puede reintentarse a sí mismo.

Cuando el proveedor envía un encabezado `Retry-After`, FlexInference espera ese tiempo en lugar del cronograma de *backoff*, limitado a 60 segundos para que un valor incorrecto no pueda estacionar su solicitud.

<Note>
  El reintento es solo previo a la confirmación. Se detiene en el momento en que
  un nivel se confirma, que es la línea de estado `200` tanto para llamadas
  *streaming* como no *streaming*. Una vez que el primer byte está en camino
  hacia usted, FlexInference nunca reintenta, la misma regla que sigue la
  carrera `flex` después de la confirmación. Una falla a mitad de la
  transmisión, o un `502` no *streaming* después de un `200` confirmado, se le
  pasa a usted.
</Note>

El `retry` del lado del servidor es independiente de cualquier bucle de reintento en su cliente, y ambos se apilan. Los SDK de FlexInference no reintenta, pero un SDK estándar de OpenAI o Anthropic reintenta dos veces por defecto. Un cliente que reintenta dos veces además de un `count` de `3` en el servidor genera hasta seis intentos *upstream*, porque cada intento del cliente ejecuta un presupuesto completo del servidor. Cuando usted establece `retry`, FlexInference marca la respuesta con `x-flexinference-retries` con el número de reintentos que ejecutó, para que pueda reducir el `max_retries` de su propio cliente.

## Facturación

Con BYOK, FlexInference utiliza su clave de proveedor cifrada almacenada en el lado del servidor; usted no envía claves de proveedor por solicitud. Su proveedor factura su cuenta a la tarifa del nivel que atendió la solicitud. Usted paga tarifas `flex` cuando `flex` se confirma y tarifas `standard` después de la escalada. Un intento `flex` puede consumir algunos tokens antes de fallar. Su proveedor factura ese uso de la misma manera que lo haría si usted llamara a `flex` directamente, y FlexInference lo incluye en el uso. FlexInference no añade ningún recargo a sus tokens. Cobra el 20% del dinero que le ahorra, y no cobra nada cuando no hay ahorros.

## Qué cambia FlexInference

FlexInference puede cambiar el nivel. No cambia el significado de su solicitud ni el resultado del proveedor. Nunca reescribe el estado o el mensaje de un proveedor. Solo normaliza el *envelope* de error: un error se devuelve con la forma del endpoint que usted llamó (OpenAI en *responses* y *chat*, Anthropic en *messages*, Google en *interactions*), llevando el estado y el mensaje del proveedor, para que su SDK pueda analizarlo. Consulte [Errores](/es/errors).

<Note>
  `start_within` es **obligatorio**. Sin él, la solicitud devuelve `400
      missing_start_within`, incluso con un SDK de OpenAI simple apuntando a nuestra
  URL base. Si envía un valor que FlexInference no puede leer, obtendrá
  `invalid_start_within`. Los valores válidos son `"default"`, `"priority"`,
  `"auto"` o una duración como `"00h-00m-30s"`. La palabra `standard` solía
  estar permitida y ya no lo está, así que envíe `default` en su lugar. Consulte
  [Errores](/es/errors) para ver la lista completa.
</Note>