Almacenamiento de prompts en caché

Cambiar una solicitud no necesariamente descarta una entrada de caché existente. Lo que importa es si una solicitud posterior tiene el mismo prefijo y puede encontrar un punto de corte válido que coincida. Las principales opciones de configuración que debes revisar son:

En GPT-5.6 y versiones posteriores, las escrituras en caché cuestan 1,25× la tarifa estándar de tokens de entrada sin caché. Vale la pena pagar este cargo cuando sabes que se reutilizará un prefijo, porque las lecturas posteriores cuestan solo 0,1× esa tarifa. Escribir un prefijo una vez y reutilizarlo por completo una vez cuesta 1,35× su costo de entrada habitual, frente a 2× por procesarlo dos veces sin caché. El ahorro aumenta con cada lectura adicional de caché: en diez solicitudes, una escritura y nueve lecturas completas cuestan 2,15×, frente a 10× sin caché.

Se admite el almacenamiento en caché tanto implícito como explícito. El explícito te da más control sobre qué contexto se escribe en caché.

Modo explícito: tú eliges dónde colocar los puntos de corte de caché según cómo gestiones el contexto.

• Establece prompt_cache_options.mode en explicit para usar solo los puntos de corte seleccionados por el desarrollador y marca cada punto de corte deseado agregando prompt_cache_breakpoint: { "mode": "explicit" } a un bloque de contenido compatible dentro de un mensaje de entrada.
• Si no se colocan puntos de corte explícitos, la solicitud no usa el almacenamiento de prompts en caché ni realiza escrituras en caché.
• El modo exclusivamente explícito te permite elegir dónde terminan las escrituras en caché. El contenido posterior al último punto de corte seleccionado se procesa a la tarifa de tokens de entrada sin caché y sin cargo por escritura en caché. Así puedes evitar escribir contenido cambiante que probablemente no se reutilice.
• Varios puntos de corte explícitos pueden conservar prefijos que cambian con distinta frecuencia. Cada solicitud puede realizar hasta cuatro escrituras en caché.
• Los elementos de entrada additional_tools actualmente no aceptan prompt_cache_breakpoint.

Modo implícito: OpenAI elige de forma predeterminada ubicaciones para los puntos de corte que funcionan bien en la mayoría de los casos de uso.

• Cuando prompt_cache_options.mode es implicit, OpenAI coloca un punto de corte al final del mensaje más reciente que cumple los requisitos. Los mensajes que cumplen los requisitos son:
  • los mensajes del usuario
  • la última respuesta de herramienta de un grupo de respuestas de herramientas consecutivas
  • el último mensaje del desarrollador del grupo inicial de mensajes del desarrollador consecutivos.
• Puedes agregar puntos de corte explícitos sin desactivar el punto de corte implícito; este utiliza uno de los cuatro espacios de escritura en caché y deja tres disponibles para escrituras explícitas en caché.

Solo se admite el almacenamiento implícito en caché. OpenAI coloca puntos de corte implícitos a intervalos que dependen del modelo, contados desde el inicio del mensaje de sistema oculto de OpenAI. Solo son válidos los puntos de corte que alcanzan o superan la longitud mínima para almacenar en caché (contada desde el final del contexto oculto).

El valor informado de cached_tokens se calcula restando los tokens de sistema ocultos de la posición del último punto de corte coincidente y luego redondeando hacia abajo al múltiplo de 128 más cercano.

Usa prompt_cache_options.ttl para controlar el tiempo de vida mínimo de la caché. El único valor admitido, 30m, también es el predeterminado. Un prefijo almacenado en caché se puede reutilizar durante 30 minutos después de su escritura o reutilización más reciente, aunque OpenAI puede conservarlo por más tiempo.

Usa prompt_cache_retention, cuyos valores admitidos dependen del modelo:

• in_memory: las entradas suelen permanecer activas durante unos 5 a 10 minutos de inactividad, hasta un máximo de una hora.
• 24h: la retención extendida suele mantener las entradas disponibles durante unos 30 minutos y puede conservarlas hasta por 24 horas.

Valores predeterminados de retención y retención cero de datos

El almacenamiento de prompts en caché puede guardar tensores cifrados de clave/valor en el almacenamiento local de la GPU como estado de la aplicación. En los modelos que admiten tanto in_memory como 24h, el valor predeterminado depende de la política de retención de datos de tu organización:

• Las organizaciones sin retención cero de datos habilitada usan 24h de forma predeterminada.
• Las organizaciones con retención cero de datos habilitada usan in_memory de forma predeterminada.

Verifica las políticas de retención disponibles para tu modelo y organización antes de seleccionar un valor.

En los modelos anteriores a GPT-5.6, usa una clave prompt_cache_key estable para las solicitudes que comparten un prefijo reutilizable, a fin de ayudar a dirigir las solicitudes relacionadas a la misma caché. Para los grupos con mucho tráfico, procura mantener un total de unas 15 solicitudes por minuto entre todos los prefijos que usan cada clave. Distribuye el tráfico de mayor volumen entre varias claves mediante una asignación estable y determinista. Mantén las solicitudes relacionadas en la misma prompt_cache_key para que puedan reutilizar su caché. Las claves influyen en el enrutamiento; no fijan las solicitudes a una máquina ni garantizan un acierto de caché.

En GPT-5.6 y modelos posteriores, OpenAI gestiona el enrutamiento de caché automáticamente; la clave no es necesaria para optimizar el almacenamiento en caché. Puedes usar claves distintas para contabilizar por separado el uso de la caché de los clientes o usuarios de tu aplicación.

Usar claves distintas puede facilitar la explicación del uso de tokens en caché y la facturación de cada cliente o usuario. Por ejemplo, las claves distintas ayudan a prevenir el sondeo de aciertos de caché entre usuarios: enviar prompts de prueba y observar los aciertos de caché para averiguar si antes se almacenó contenido coincidente en caché. Consulta Contabilizar por separado el uso de la caché con claves.

En aplicaciones de varios turnos, reutilizar el historial de conversación a medida que crece puede ahorrar más tokens de entrada que almacenar en caché solo las instrucciones iniciales. Conserva los mensajes anteriores y los resultados de las herramientas para que los turnos posteriores puedan reutilizar todo el prefijo compartido.

• Mantén el prefijo estable. Coloca primero las instrucciones del desarrollador y el material de referencia compartido que no cambian. Si contienen marcas de tiempo, contenido específico del usuario u otro contenido dinámico, coloca esos elementos al final en lugar de al principio, o muévelos a mensajes posteriores de la conversación.
• Conserva el historial de conversación. Agrega nuevos mensajes al final en lugar de reescribir los turnos anteriores. Los resúmenes, la compactación o el truncamiento del contexto pueden cambiar el prefijo y hacer que la reutilización de la caché tenga que comenzar de nuevo.
• Cambia el esfuerzo de razonamiento sin reescribir el prefijo. En GPT-6 Astra, agrega un elemento de entrada configuration_update al final para cambiar el esfuerzo de razonamiento entre respuestas sin modificar reasoning.effort a nivel de la solicitud. Esto conserva el prefijo original para reutilizar la caché. Consulta Cambiar el razonamiento durante una conversación para ver ejemplos y límites de compatibilidad.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26{
  "model": "gpt-5.6",
  "reasoning": { "effort": "low", "context": "all_turns" },
  "text": { "verbosity": "medium" },
  "prompt_cache_options": { "mode": "explicit" },
  "input": [
    {
      "role": "developer",
      "content": [
        {
          "type": "input_text",
          "text": "Stable instructions and shared reference material...",
          "prompt_cache_breakpoint": { "mode": "explicit" }
        }
      ]
    },
    {
      "role": "developer",
      "content": "Dynamic developer instructions, such as user-specific content and timestamps..."
    },
    {
      "role": "user",
      "content": "The user's current question..."
    }
  ]
}

En los modelos compatibles de GPT-6 y posteriores, agrega un elemento de entrada configuration_update al final para cambiar el esfuerzo de razonamiento durante una conversación y conservar el prefijo anterior almacenado en caché. Mantén el valor original de reasoning.effort de nivel superior, ya que cambiar esa configuración puede reescribir parte de las instrucciones ocultas del sistema.

La actualización de configuración más reciente controla el esfuerzo de razonamiento de las respuestas posteriores. Por ejemplo, agrega este elemento al final del arreglo input existente para usar el nivel de razonamiento high en las solicitudes posteriores:

1
2
3
4{
  "type": "configuration_update",
  "reasoning": { "effort": "high" }
}

Cuando las herramientas que necesita tu aplicación varíen entre solicitudes, cambia cuáles se pueden llamar y mantén sus definiciones estables para conservar los prefijos reutilizables.

• Mantén las herramientas sin cambios. Conserva sus definiciones, orden y esquemas.
• Desactiva el uso de herramientas para una solicitud. Establece tool_choice en "none" en lugar de eliminar las definiciones de las herramientas.
• Habilita solo las herramientas seleccionadas. Usa allowed_tools para restringir qué herramientas se pueden llamar sin modificar la lista tools proporcionada.
• Carga las herramientas cuando sean necesarias. Usa la búsqueda de herramientas con defer_loading: true para reducir los tokens de entrada destinados a las definiciones de herramientas en las primeras solicitudes de hilos de varios turnos. Las herramientas descubiertas se agregan al final del contexto, lo que conserva el contenido reutilizable anterior.
• Conserva el historial de carga de herramientas. Usa un elemento de entrada additional_tools con rol de desarrollador para agregar herramientas durante un hilo según la lógica de tu aplicación.

En GPT-5.6 y posteriores, dos controles determinan dónde se colocan los puntos de corte de caché: prompt_cache_options.mode selecciona el almacenamiento en caché implícito o exclusivamente explícito, y prompt_cache_breakpoint marca un límite que tú eliges.

• Coloca los puntos de corte automáticamente. Usa el almacenamiento en caché implícito para colocar un punto de corte al final del último mensaje que cumpla los requisitos. Esto resulta práctico para los hilos de varios turnos que agregan contenido al final del contexto existente.
• Elige los puntos de corte con cuidado. Coloca marcadores explícitos al final del contenido estable. Usa el modo exclusivamente explícito para evitar escrituras en caché innecesarias de sufijos variables.

En GPT-5.6 y modelos posteriores, usa prompt_cache_key cuando quieras contabilizar por separado el uso de la caché de los clientes, usuarios o espacios de trabajo de tu aplicación. Esto puede facilitar la explicación del uso de tokens en caché y la facturación dentro de cada grupo. La clave es opcional y no es necesaria para optimizar el almacenamiento en caché en estos modelos.

• Elige cómo contabilizar por separado el uso de la caché. Asigna una clave distinta a cada cliente o usuario cuyo uso de la caché deba contabilizarse por separado. Por ejemplo, support:customer_123 y support:customer_456 permiten contabilizar por separado el uso de la caché de dos clientes, incluso cuando sus solicitudes contienen el mismo prefijo.
• Mantén estables las claves dentro de cada grupo. Reutiliza la misma clave para las solicitudes relacionadas de un cliente. Genera una clave distinta para una sesión o un hilo solo cuando su uso de la caché deba contabilizarse por separado.
• Aplica las claves de forma coherente. Usa la clave del cliente en todas sus solicitudes para seguir contabilizando su uso de la caché por separado. Esto también ayuda a prevenir el sondeo de aciertos de caché entre clientes.

En los modelos anteriores a GPT-5.6, prompt_cache_key es importante para optimizar las tasas de aciertos de caché. Usa una clave estable para las solicitudes que comparten un prefijo reutilizable, a fin de ayudar a dirigirlas a la misma caché. Para los grupos con mucho tráfico, sigue las recomendaciones para distribuir el tráfico entre más claves.

En los modelos anteriores, es preferible establecer prompt_cache_retention en "24h" para obtener una retención extendida cuando el modelo y tus requisitos de retención de datos lo permitan. Consulta Tiempo de vida de la caché para conocer las opciones compatibles y los valores predeterminados.

Si muchas solicitudes reutilizan las mismas instrucciones del desarrollador y definiciones de herramientas, pero ese prefijo compartido no alcanza la longitud mínima para almacenar en caché del modelo, considera acortarlo o ampliarlo con instrucciones, ejemplos o material de referencia útiles y estables. Mide si la reutilización de la caché compensa los tokens de entrada adicionales y los cargos por escritura en caché, y asegúrate de que las evaluaciones y el comportamiento se mantengan estables.

El gráfico destaca la trampa de costos de la longitud mínima para almacenar en caché: los prefijos cortos sin caché pueden costar más que ampliarlos hasta alcanzar la cantidad mínima de tokens necesaria para almacenarlos en caché.

• Mide el rendimiento real de la caché. Monitorea usage.input_tokens_details.cached_tokens, usage.input_tokens_details.cache_write_tokens, la cantidad de tokens de entrada, la latencia y el costo efectivo. Calcula la tasa de aciertos de caché por token dividiendo el total de tokens en caché entre el total de tokens de entrada y sumando ambos recuentos por usuario, espacio de trabajo, día u otra agrupación útil.
• Calcula el costo de entrada. Usa los recuentos de tokens de response.usage y los precios por millón de tokens del modelo.
• Usa el panel de almacenamiento de prompts en caché. Monitorea las tasas de aciertos de caché en el panel de almacenamiento de prompts en caché.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18function calculateInputCost(
  usage,
  inputPricePerMillion,
  cacheInputMultiplier = 0.1,
  cacheWriteMultiplier = 1.25
) {
  const inputTokens = usage.input_tokens;
  const cachedTokens = usage.input_tokens_details.cached_tokens;
  const cacheWriteTokens = usage.input_tokens_details.cache_write_tokens;
  const ordinaryInputTokens = inputTokens - cachedTokens - cacheWriteTokens;

  const weightedInputTokens =
    ordinaryInputTokens +
    cachedTokens * cacheInputMultiplier +
    cacheWriteTokens * cacheWriteMultiplier;
  const inputCost = (weightedInputTokens * inputPricePerMillion) / 1_000_000;
  return inputCost;
}

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21from openai.types.responses import ResponseUsage


def calculate_input_cost(
    usage: ResponseUsage,
    input_price_per_million: float,
    cache_input_multiplier: float = 0.1,
    cache_write_multiplier: float = 1.25,
) -> float:
    input_tokens = usage.input_tokens
    cached_tokens = usage.input_tokens_details.cached_tokens
    cache_write_tokens = usage.input_tokens_details.cache_write_tokens
    ordinary_input_tokens = input_tokens - cached_tokens - cache_write_tokens

    weighted_input_tokens = (
        ordinary_input_tokens
        + cached_tokens * cache_input_multiplier
        + cache_write_tokens * cache_write_multiplier
    )
    input_cost = weighted_input_tokens * input_price_per_million / 1_000_000
    return input_cost

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17def calculate_input_cost(
  usage,
  input_price_per_million,
  cache_input_multiplier = 0.1,
  cache_write_multiplier = 1.25
)
  input_tokens = usage.input_tokens
  details = usage.input_tokens_details
  cached_tokens = details.cached_tokens
  cache_write_tokens = details.cache_write_tokens
  ordinary_input_tokens = input_tokens - cached_tokens - cache_write_tokens

  weighted_input_tokens = ordinary_input_tokens +
                          (cached_tokens * cache_input_multiplier) +
                          (cache_write_tokens * cache_write_multiplier)
  (weighted_input_tokens * input_price_per_million) / 1_000_000
end

• Conserva los prefijos estables existentes.
• Si usas prompt_cache_key, conserva los valores existentes para seguir contabilizando por separado el uso de la caché de cada cliente o usuario.
• Reemplaza prompt_cache_retention por prompt_cache_options.ttl.
• Confirma que los prefijos reutilizables cumplan con la longitud mínima que se puede almacenar en caché del modelo.
• Si el punto de corte predeterminado incluye contenido que cambia entre solicitudes, agrega un punto de corte explícito después del prefijo estable.
• Usa prompt_cache_options.mode: "explicit" cuando no valga la pena escribir el contenido posterior en caché.
• Compara cached_tokens, cache_write_tokens, la latencia y el costo total antes y después de la migración.

Considera un LLM que actúa como juez en un solo turno para determinar si una interacción finalizada con un chatbot muestra indicios de que el usuario quedó satisfecho. Cada solicitud usa la misma rúbrica de evaluación y unos pocos ejemplos etiquetados para evaluar una interacción diferente.

• Conservar el prefijo: la rúbrica fija y los ejemplos se colocan primero. Su longitud combinada se mantiene deliberadamente apenas por encima de la longitud mínima que se puede almacenar en caché del modelo, con material que ayuda a calibrar al juez. La interacción que se evalúa se coloca al final.
• Modo de almacenamiento en caché y punto de corte: se habilita el almacenamiento en caché exclusivamente explícito, con un punto de corte después de la rúbrica fija y los ejemplos. La conversación entre el usuario y el chatbot que se evalúa se coloca después de ese punto de corte y no se escribe en caché, lo que evita un cargo de escritura por contenido que probablemente no se reutilice.

Un ejemplo de implementación que aplicó estos principios registró una tasa de aciertos de caché por token de ~70 %. Esta cifra ilustra un resultado posible. Las tasas máximas reales de aciertos de caché dependerán de tu contexto y del uso de la aplicación.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22{
  "model": "gpt-5.6-sol",
  "reasoning": { "effort": "medium", "context": "all_turns" },
  "text": { "verbosity": "low" },
  "prompt_cache_options": { "mode": "explicit" },
  "input": [
    {
      "role": "developer",
      "content": [
        {
          "type": "input_text",
          "text": "Judge whether the completed interaction provides evidence that the user is satisfied. Return true or false. Full grading rubric and labeled few-shot examples...",
          "prompt_cache_breakpoint": { "mode": "explicit" }
        }
      ]
    },
    {
      "role": "user",
      "content": "Completed interaction to evaluate..."
    }
  ]
}

Considera un agente de varios turnos con instrucciones del desarrollador extensas y compartidas, y llamadas frecuentes a herramientas. En el uso habitual, los usuarios ejecutan varias sesiones con el agente a la vez y suelen crear forks de los hilos.

• Conservar el prefijo: cada turno agrega nuevos mensajes, llamadas a herramientas y resultados sin reescribir el contexto anterior, por lo que el prefijo reutilizable crece con el tiempo.
• Clave opcional de caché de prompts: este ejemplo usa agent_123_v1:user_456 para contabilizar por separado el uso de la caché del usuario 456, lo que facilita la explicación de su uso de tokens en caché y su facturación. Esto también ayuda a prevenir el sondeo de aciertos de caché entre usuarios. La clave se mantiene igual en todas las sesiones y los forks de ese usuario con el agente. Omítela si tu aplicación no necesita esta separación.
• Modo de almacenamiento en caché implícito: se habilita el almacenamiento en caché implícito para que el último mensaje apto del usuario o de una herramienta proporcione un punto de corte.
• Puntos de corte explícitos: se agrega un punto de corte después de cada resultado de herramienta para conservar los prefijos reutilizables anteriores y mejorar la eficiencia de la caché al crear forks.

Una implementación de ejemplo que aplicó estos principios registró una tasa de aciertos de caché de tokens >90 %. Esta cifra ilustra un resultado posible. Las tasas máximas de aciertos de caché que se alcancen dependerán del contexto y del uso de la aplicación.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41{
  "model": "gpt-5.6-sol",
  "reasoning": { "effort": "medium", "context": "all_turns" },
  "text": { "verbosity": "medium" },
  "prompt_cache_key": "agent_123_v1:user_456",
  "prompt_cache_options": { "mode": "implicit" },
  "tools": [
    {
      "type": "function",
      "name": "function_name",
      "description": "Function description",
      "parameters": { "...": "..." }
    }
  ],
  "input": [
    {
      "role": "developer",
      "content": "Stable developer instructions and reference material..."
    },
    { "role": "user", "content": "Can you do...?" },
    {
      "type": "function_call",
      "call_id": "call_123",
      "name": "function_name",
      "arguments": "..."
    },
    {
      "type": "function_call_output",
      "call_id": "call_123",
      "output": [
        {
          "type": "input_text",
          "text": "Tool result...",
          "prompt_cache_breakpoint": { "mode": "explicit" }
        }
      ]
    },
    { "role": "assistant", "content": "Assistant response..." },
    { "role": "user", "content": "Can you also do...?" }
  ]
}

Esto es especialmente frecuente al migrar de modelos anteriores a GPT-5.6 o versiones posteriores, debido al cambio en el comportamiento del almacenamiento implícito en caché. Si las solicitudes comparten un prefijo largo, pero tienen sufijos diferentes, almacenar en caché la primera solicitud completa usando solo el modo implícito no permite reutilizar el prefijo compartido más corto.

Considera un mensaje de desarrollador estático seguido de un mensaje de usuario dinámico en cada solicitud. Esta solicitud escribe en caché hasta el final del contenido dinámico. Al cambiar ese contenido en la siguiente solicitud, deja de coincidir con el prefijo más largo almacenado en caché, y no hay un punto de corte independiente después del contenido estático.

1
2
3
4
5
6
7
8
9
10{
  "model": "gpt-5.6-sol",
  "reasoning": { "effort": "medium", "context": "all_turns" },
  "text": { "verbosity": "low" },
  "prompt_cache_options": { "mode": "implicit" },
  "input": [
    { "role": "developer", "content": "Static content..." },
    { "role": "user", "content": "Dynamic content..." }
  ]
}

Para solucionarlo, coloca un punto de corte explícito después del contenido estático en ambas solicitudes. La primera solicitud escribe el prefijo reutilizable en caché; la siguiente puede reutilizarlo incluso si cambia el contenido dinámico. Este ejemplo usa el modo exclusivamente explícito para evitar escribir el contenido dinámico en caché.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17{
  "model": "gpt-5.6-sol",
  "reasoning": { "effort": "medium", "context": "all_turns" },
  "text": { "verbosity": "low" },
  "prompt_cache_options": { "mode": "explicit" },
  "input": [
    {
      "role": "developer",
      "content": [{
        "type": "input_text",
        "text": "Static content...",
        "prompt_cache_breakpoint": { "mode": "explicit" }
      }]
    },
    { "role": "user", "content": "Dynamic content..." }
  ]
}

Supongamos que la solicitud 1 usa el modo implícito y almacena en caché un prefijo hasta el final de un mensaje de usuario. Luego, la solicitud de seguimiento 2 conserva ese prefijo, pero cambia a prompt_cache_options.mode: "explicit". Como se explica en Cómo funciona la coincidencia de prefijos, la solicitud 2 comprueba solo los puntos de corte explícitos de su propia entrada, por lo que no reutilizará ese prefijo implícito guardado por la solicitud 1 (a menos que uno de los puntos de corte explícitos de la solicitud 2 coincida con el punto final almacenado en caché por la solicitud 1).

▼ = breakpoint

- Request 1: implicit mode
  [Developer message][User message] ▼

- Request 2: explicit-only mode. Does not hit cache.
  [Developer message][User message][Follow-up] ▼

Para reutilizar el prefijo implícito de la solicitud 1, coloca un punto de corte explícito en el límite del bloque de contenido correspondiente en la solicitud 2, o mantén habilitado el modo implícito para que el final del mensaje anterior apto siga siendo un candidato para la búsqueda.

Incluso cuando ambas solicitudes usan el modo implícito, conservar los mismos tokens iniciales no siempre es suficiente. Supongamos que la solicitud 1 termina con un mensaje de usuario que contiene Content A y, luego, la solicitud de seguimiento 2 amplía ese mismo mensaje a Content A + Content B. El punto final anterior, después de Content A, ahora está dentro de un mensaje, en lugar de estar al final. Como se explica en Cómo funciona la coincidencia de prefijos, sin un punto de corte explícito en ese límite, la solicitud 2 no reutiliza el prefijo guardado allí.

▼ = breakpoint

- Request 1: implicit mode
  [Developer message][User message: Content A] ▼

- Request 2: implicit mode. Cannot reuse the prefix through Content A.
  [Developer message][User message: Content A + Content B] ▼

Cuando la estructura de la conversación lo permita, conserva el mensaje original y agrega un mensaje nuevo en lugar de ampliarlo. De lo contrario, mantén el texto reutilizable en un bloque de contenido separado y coloca un punto de corte explícito después de ese bloque en ambas solicitudes.

En el modo implícito, los mensajes de desarrollador posteriores al bloque inicial de mensajes de desarrollador consecutivos no son límites automáticos de búsqueda en caché. Agrega un punto de corte explícito al final del mensaje de desarrollador reutilizable y consérvalo en las solicitudes posteriores para que OpenAI pueda buscar un prefijo coincidente en caché.

Un prefijo que cumple los requisitos para almacenarse en caché en un modelo puede ser demasiado corto en otro. Consulta la comparación de modelos y mide el prefijo reutilizable con el modelo y la configuración que realmente usas. Cuando cambies de modelo, repite esa comprobación en lugar de suponer que el umbral del modelo anterior sigue siendo válido.

La compactación reemplaza el contexto anterior de la conversación por una representación más breve. Esto puede cambiar el prefijo, por lo que la primera solicitud después de la compactación podría reutilizar una porción menor de la caché anterior, aunque la conversación siga siendo la misma desde el punto de vista lógico.

Mantén estables las instrucciones y el material de referencia reutilizables siempre que sea posible y, luego, deja que los turnos posteriores se construyan sobre el contexto compactado. Compara el costo total de entrada antes y después de la compactación: reducir los tokens de entrada puede ahorrar dinero incluso si baja la tasa de aciertos de caché.

No. El almacenamiento de prompts en caché no cambia la forma en que el modelo genera los tokens de salida. El modelo genera una nueva respuesta usando el prefijo almacenado en caché, por lo que no se garantiza que solicitudes idénticas produzcan salidas idénticas.

No. Actualmente no se puede vaciar la caché manualmente. Las entradas de caché vencen según la duración de la caché y la configuración de retención del modelo.

Sí. Los tokens de entrada almacenados en caché siguen contando para los límites de tokens por minuto. El almacenamiento de prompts en caché no cambia la forma en que se calculan los límites de solicitudes.