API y Console: 3 palancas de coste

“Paga por imprimir una página una vez y fotocópiala por una décima parte del coste, o vuelve a teclearla desde cero cada vez. El caching es la fotocopiadora.”

16. Breakpoints de cache_control: dónde ponerlos

Dónde: el campo cache_control de un bloque de contenido en la petición a la API. Qué hace: marca un prefijo de tu prompt como cacheable; las peticiones posteriores con el mismo prefijo se cobran a una fracción de la tarifa de entrada. Por qué importa: es la mayor palanca de coste de la API, y la mayoría coloca el breakpoint mal y obtiene un ahorro parcial. El artículo cuenta una factura de 340 $/mes que bajó a 87 $ tras corregir el breakpoint.

El breakpoint va en la frontera entre contenido estático y dinámico: todo lo anterior se cachea, todo lo posterior se recalcula. Ponlo después de tu system prompt estable / tools / contexto largo, antes de la entrada de usuario de cada petición.

messages = [
    {
        "role": "user",
        "content": [
            {
                "type": "text",
                "text": LONG_STABLE_CONTEXT,
                "cache_control": {"type": "ephemeral"},  # cache the prefix
            },
            {"type": "text", "text": per_request_question},  # recomputed
        ],
    }
]

Suelen estar disponibles dos TTL: un valor efímero corto por defecto y uno más largo para system prompts que no cambian entre sesiones. Como regla general, el artículo da esta: un prefijo cacheado compensa en cuanto lo lees dos o más veces dentro de la ventana del TTL. (Confirma los multiplicadores actuales de escritura/lectura de caché y los TTL en la documentación de la API.)

17. inference_geo y el impuesto de residencia de datos

Dónde: el artículo describe un parámetro de petición que enruta la inferencia a una región concreta (solo EE. UU., solo UE, etc.). Por qué importa: reporta que la residencia regional añade un sobrecoste que no aparece en la tarjeta de precios estándar; lo ves en la factura.

18. Rate limits por workspace y por feature

Dónde: Console → Settings → Workspaces → tu workspace → rate limits. Qué hace: fija un rate limit por workspace (y, señala el artículo, por feature dentro de un workspace), separado de tus límites a nivel de cuenta. Por qué importa: un límite de cuenta evita que te arruines; un límite de workspace evita que un batch job desbocado se coma el margen que necesita tu chat de cara al cliente y devuelva 429.

• Crea un workspace por superficie: chat interactivo, procesamiento batch, herramientas internas, experimental.
• Fija el límite de cada workspace en ~60 a 70% de tu tier de cuenta, dejando margen para el que necesite un pico.
• Fija topes por feature dentro de un workspace para todo lo que haga trabajo batch; el artículo señala un tope a nivel de feature que viene ilimitado por defecto y es fácil pasar por alto.