Gemini: repetir el inicio de una consulta puede favorecer la caché, pero hay que comprobar el resultado
La guía actual distingue la caché implícita de la gestión explícita. La versión del modelo y los datos de uso importan más que asumir un ahorro.
La documentación de Gemini sobre caché de contexto, actualizada el 13 de octubre, aconseja colocar el contenido común al comienzo de las solicitudes y enviar prefijos semejantes en un intervalo corto. Es una pauta para favorecer coincidencias en la caché implícita, no una confirmación de que cualquier texto repetido se haya reutilizado.
La misma guía indica que esta modalidad se activa por defecto desde Gemini 2.5. También advierte que Interactions API no admite gestionar objetos de caché explícita y que esa gestión tampoco está disponible para Gemini 4 Argon y posteriores. Por eso una receta antigua con creación manual de caché no debe trasladarse automáticamente a cualquier modelo nuevo.
Un ejemplo de organización sería analizar tres capítulos distintos con un mismo criterio editorial. Se podría mantener primero la rúbrica común y colocar después el capítulo correspondiente, en lugar de introducir cambios innecesarios delante de la rúbrica en cada petición. Es un ejemplo de estructura, sin una prueba realizada ni una reducción de coste medida.
Para evaluar ese diseño conviene anotar modelo, interfaz, contenido reutilizado y tokens que la respuesta identifica como recuperados de caché. La guía sitúa ese dato en usage.total_cached_tokens. Si no se consulta la respuesta real, el parecido entre dos solicitudes solo permite describir una posibilidad.
Reutilizar una entrada tampoco verifica su vigencia. Si cambia el documento base o el criterio de análisis, hay que actualizarlo aunque rompa la coincidencia anterior. Una organización eficiente de las consultas sirve de poco si conserva una instrucción obsoleta.