DEV Community

Cover image for Cómo extender el uso de Claude Fable 5 con el prompt perfecto
Roobia
Roobia

Posted on • Originally published at apidog.com

Cómo extender el uso de Claude Fable 5 con el prompt perfecto

Claude Fable 5 es más capaz que los modelos anteriores, pero esa capacidad tiene coste: si no delimitas la tarea, puede recopilar contexto innecesario, deliberar demasiado y modificar código que no pediste tocar. La forma práctica de extender tu uso no es “forzar” límites, sino escribir instrucciones que ajusten esfuerzo, alcance y verbosidad a cada solicitud.

Prueba Apidog hoy

Esta guía convierte la guía oficial de instrucciones de Fable 5 de Anthropic en pasos aplicables. Después verás cómo probar esas instrucciones con Apidog para medir tokens, latencia y comportamiento en lugar de ajustar por intuición.

Qué significa realmente “extender tu uso”

En Fable 5, tres controles influyen directamente en coste, latencia y utilidad de cada llamada:

  • Esfuerzo. Es el principal equilibrio entre capacidad, tiempo de respuesta y coste. Anthropic recomienda high como valor general, xhigh para tareas especialmente difíciles, y medium o low para trabajo rutinario.
  • Tokens de salida. Sin una instrucción clara, el modelo puede explicar de más, narrar opciones descartadas o añadir comentarios innecesarios. Una instrucción de concisión reduce salida sin perder contenido útil.
  • Duración de ejecución. Fable 5 puede sostener ejecuciones largas en tareas complejas. Eso es útil cuando el problema lo justifica, pero caro si la tarea era simple.

Imagen

El objetivo es simple: usa menos deliberación en tareas fáciles y reserva la capacidad alta para problemas donde realmente aporte valor.

Patrones de instrucciones para optimizar cada llamada

Estos patrones vienen de la guía de Anthropic y funcionan bien como fragmentos de system prompt. Úsalos como bloques reutilizables según el tipo de tarea.

1. Ajusta el esfuerzo a la tarea

No uses siempre el mismo nivel de esfuerzo.

Guía práctica:

  • Usa low o medium para:
    • reformatear texto;
    • clasificar entradas simples;
    • generar respuestas cortas;
    • aplicar cambios mecánicos.
  • Usa high para:
    • análisis técnico;
    • debugging;
    • generación de código con contexto;
    • decisiones con varias restricciones.
  • Usa xhigh solo para:
    • problemas ambiguos;
    • arquitectura;
    • razonamiento extenso;
    • tareas críticas donde la calidad pesa más que la latencia.

Si una tarea se completa bien pero tarda demasiado, baja el esfuerzo y vuelve a medir. Para entender el impacto en volumen, revisa el desglose del costo de la API de Claude y los límites de velocidad de la API de Claude.

2. Dile que actúe cuando tenga suficiente información

Usa esta instrucción cuando veas respuestas largas que vuelven a justificar decisiones ya tomadas:

Cuando tengas suficiente información para actuar, actúa. No vuelvas a derivar hechos ya establecidos
en la conversación, no vuelvas a debatir una decisión que el usuario ya ha tomado, ni narres
opciones que no vas a seguir. Si estás sopesando una elección, da una recomendación, no un
estudio exhaustivo. Esto no se aplica a los bloques de pensamiento.
Enter fullscreen mode Exit fullscreen mode

Cuándo usarlo:

  • agentes que trabajan con herramientas;
  • tareas de edición de código;
  • análisis donde ya diste restricciones claras;
  • flujos multi-turno con mucho contexto acumulado.

3. Empieza con el resultado

Este patrón reduce preámbulos y hace que la respuesta sea más útil para humanos y sistemas que consumen el output:

Comienza con el resultado. Tu primera frase después de terminar debe responder a "qué pasó"
o "qué encontraste": lo que el usuario pediría si dijera "solo dame el
resumen". Los detalles de apoyo y el razonamiento vienen después. Ser legible y ser conciso son
cosas diferentes, y la legibilidad importa más.
Enter fullscreen mode Exit fullscreen mode

Ejemplo de uso:

Sistema:
Comienza con el resultado. Da primero la conclusión y luego los detalles técnicos.

Usuario:
Revisa este diff y dime si introduce riesgos de seguridad.
Enter fullscreen mode Exit fullscreen mode

4. Restringe el alcance

Fable 5 puede “ayudar demasiado”: refactorizar, limpiar o añadir validaciones fuera del alcance. Para tareas de código, delimita explícitamente:

No añadas características, refactorices ni introduzcas abstracciones más allá de lo que la tarea requiere. Una
corrección de errores no necesita limpieza adicional. No añadas manejo de errores, fallbacks, ni
validación para escenarios que no pueden ocurrir. Solo valida en los límites del sistema (entrada del
usuario, APIs externas). Haz lo más simple que funcione bien.
Enter fullscreen mode Exit fullscreen mode

Úsalo especialmente en:

  • bug fixes;
  • pull requests pequeños;
  • migraciones mecánicas;
  • cambios en archivos sensibles;
  • tareas donde el diff debe ser mínimo.

5. Basa el progreso en resultados reales de herramientas

En ejecuciones largas, evita reportes de progreso no verificados. Añade esta instrucción:

Antes de informar el progreso, audita cada afirmación contra un resultado de herramienta de esta sesión.
Solo informa el trabajo para el que puedas señalar evidencia; si algo aún no está verificado, dilo
explícitamente.
Enter fullscreen mode Exit fullscreen mode

Esto es útil para agentes que:

  • ejecutan tests;
  • modifican repositorios;
  • llaman APIs;
  • inspeccionan logs;
  • generan reportes de estado.

6. Explica la intención, no solo la tarea

Fable 5 responde mejor cuando entiende para qué se usará la salida:

Estoy trabajando en [la tarea más grande] para [quién es]. Necesitan [lo que la salida
permite]. Con eso en mente: [solicitud].
Enter fullscreen mode Exit fullscreen mode

Ejemplo:

Estoy preparando una guía interna para desarrolladores backend que migran de REST a GraphQL.
Necesitan ejemplos concretos y advertencias de implementación. Con eso en mente:
resume los riesgos principales de esta migración y propón un checklist técnico.
Enter fullscreen mode Exit fullscreen mode

7. Mantén un archivo de memoria para trabajo repetido

Para tareas recurrentes, crea un archivo Markdown de aprendizaje:

# Memoria del flujo de revisión

Resumen: evitar refactors no solicitados y priorizar diffs pequeños.

## Lecciones

- 2026-06-12: En correcciones de bugs, no modificar nombres públicos salvo que el usuario lo pida.
- 2026-06-12: Antes de sugerir cambios de API, verificar compatibilidad con clientes existentes.
Enter fullscreen mode Exit fullscreen mode

Reglas prácticas:

  • una lección por entrada;
  • resumen corto al inicio;
  • actualiza entradas existentes en vez de duplicarlas;
  • carga esta memoria en tareas futuras relacionadas.

Prueba y ajusta tus instrucciones en Apidog

La guía oficial te da patrones, pero tú necesitas verificar si realmente funcionan en tu caso. Una instrucción que parece más corta puede no reducir tokens. Una instrucción de brevedad puede empeorar la calidad. La única forma fiable es comparar variantes.

Apidog te permite guardar solicitudes, parametrizar variables, comparar respuestas, añadir aserciones y simular la API para iterar sin gastar tokens. Si ya haces pruebas de API sin Postman, el flujo es el mismo: solo apuntas al endpoint de Mensajes.

Imagen

1. Parametriza la instrucción y la tarea

Crea una solicitud a la API de Mensajes y mueve los valores cambiantes a variables de entorno:

  • ANTHROPIC_API_KEY
  • SYSTEM_PROMPT
  • TASK

Ejemplo:

POST https://api.anthropic.com/v1/messages
x-api-key: {{ANTHROPIC_API_KEY}}
anthropic-version: 2023-06-01
content-type: application/json

{
  "model": "claude-fable-5",
  "max_tokens": 2048,
  "system": "{{SYSTEM_PROMPT}}",
  "messages": [
    { "role": "user", "content": "{{TASK}}" }
  ]
}
Enter fullscreen mode Exit fullscreen mode

Con esto puedes cambiar una instrucción completa sin editar el cuerpo de la request.

2. Crea dos variantes A/B

Guarda dos versiones de la misma solicitud:

  • Variante A: prompt base.
  • Variante B: prompt con instrucciones de concisión, alcance o progreso verificado.

Ejemplo de SYSTEM_PROMPT para la variante B:

Comienza con el resultado. No añadas características, refactorices ni introduzcas abstracciones
más allá de lo que la tarea requiere. Cuando tengas suficiente información para actuar, actúa.
Enter fullscreen mode Exit fullscreen mode

Ejecuta ambas contra la misma TASK.

3. Compara tokens, latencia y calidad

Después de ejecutar ambas variantes, revisa:

  • Tokens de salida: usage.output_tokens.
  • Latencia: tiempo de respuesta mostrado por Apidog.
  • Calidad: si la respuesta cumple la tarea sin omitir información necesaria.
  • Alcance: si cambió solo lo pedido.
  • Formato: si la salida es estable para tu integración.

Una mejora real debería mantener la calidad y reducir coste, latencia o ruido.

4. Añade una aserción sobre stop_reason

Fable 5 puede devolver:

{
  "stop_reason": "refusal"
}
Enter fullscreen mode Exit fullscreen mode

Si tu sistema hace fallback silencioso a otro modelo, esto puede cambiar costes y comportamiento. Añade una aserción en Apidog para esperar:

stop_reason == "end_turn"
Enter fullscreen mode Exit fullscreen mode

Así detectas rechazos como fallos de prueba, no como sorpresas en producción. Trata esta comprobación como parte del contrato de tu prompt.

5. Configura timeouts realistas

Fable 5 puede tardar más en tareas difíciles. Antes de llevarlo a producción:

  • define un timeout adecuado en tu cliente;
  • prueba respuestas lentas;
  • valida que tu UI o servicio no se quede bloqueado;
  • considera streaming si tu caso lo requiere;
  • baja el esfuerzo si la tarea termina bien pero demasiado tarde.

Si aparecen problemas, la ruta para solucionar tiempos de espera de solicitudes upstream aplica directamente.

6. Simula la API para iterar sin coste

Durante el ajuste de prompts, no necesitas llamar siempre a la API real. Usa el servidor de simulación de Apidog para devolver respuestas guardadas con la misma forma:

{
  "id": "msg_123",
  "type": "message",
  "role": "assistant",
  "content": [
    {
      "type": "text",
      "text": "Resultado de prueba"
    }
  ],
  "stop_reason": "end_turn",
  "usage": {
    "input_tokens": 300,
    "output_tokens": 120
  }
}
Enter fullscreen mode Exit fullscreen mode

Simula también errores y rechazos:

{
  "stop_reason": "refusal",
  "usage": {
    "input_tokens": 280,
    "output_tokens": 40
  }
}
Enter fullscreen mode Exit fullscreen mode

Esto te permite probar:

  • manejo de errores;
  • lógica de retry;
  • aserciones;
  • timeouts;
  • parsing de respuesta;
  • comportamiento del cliente.

Cuando quieras medir tokens y latencia reales, vuelve a la API en vivo. Si lo integras en CI, la guía de Apidog CLI y habilidades de Claude muestra cómo automatizar estas comprobaciones.

Checklist de implementación

Antes de desplegar un prompt para Fable 5, valida esto:

  • [ ] ¿La tarea necesita high o puede ejecutarse con medium/low?
  • [ ] ¿El prompt empieza pidiendo el resultado primero?
  • [ ] ¿El alcance está limitado?
  • [ ] ¿El modelo tiene suficiente contexto sobre la intención?
  • [ ] ¿Hay una aserción para stop_reason?
  • [ ] ¿Mediste usage.output_tokens?
  • [ ] ¿Comparaste latencia entre variantes?
  • [ ] ¿Probaste timeouts?
  • [ ] ¿Simulaste errores y rechazos?
  • [ ] ¿Guardaste la variante ganadora?

Preguntas frecuentes

¿Una mejor instrucción significa menos tokens en Fable 5?

A menudo, sí. Una instrucción que pide empezar con el resultado y evitar narración innecesaria puede reducir output_tokens. Mídelo en Apidog en lugar de asumirlo.

¿Cuál es la forma más rápida de reducir el coste de Fable 5?

Bajar el nivel de esfuerzo en tareas rutinarias. Reserva high y xhigh para problemas donde la capacidad adicional realmente cambie el resultado.

¿Por qué mi solicitud tarda más que con modelos anteriores?

Fable 5 puede ejecutar tareas difíciles durante más tiempo. Ajusta timeouts, usa streaming si aplica o reduce el esfuerzo si la calidad sigue siendo suficiente.

¿Por qué recibo respuestas de fallback cuando pedí Fable 5?

Puede haberse producido stop_reason: "refusal". Añade una aserción sobre stop_reason para detectarlo durante las pruebas.

¿Puedo probar cambios de prompt sin gastar tokens?

Sí. Simula el endpoint de Mensajes en Apidog para probar tu cliente y ejecuta la API real solo cuando necesites medir tokens y latencia reales.

Conclusión

Extender tu uso de Fable 5 consiste en hacer que cada llamada trabaje en el nivel correcto: menos esfuerzo para tareas simples, más capacidad para problemas difíciles, menos verbosidad y alcance bien definido. Usa los patrones de Anthropic como bloques de prompt y valida el resultado con Apidog: parametriza la solicitud, compara variantes A/B, mide tokens y latencia, y añade aserciones contra rechazos. Así conviertes “este prompt parece mejor” en una decisión medible.

Top comments (0)