Agent Prompt

Integra ModelRush en el proyecto actual y aplica directamente los cambios de código necesarios. Es una tarea de ingeniería independiente de cualquier marca de agente: inspecciona primero el proyecto y elige después la implementación que encaje con su arquitectura.
​
Esta integración cubre todas las capacidades activas de ModelRush: texto, código, imagen, vídeo y audio. No la implementes como una integración exclusiva de LLM ni limitada a Chat Completions.
​
Alta de la clave de API (complétala antes de hacer cualquier petición a ModelRush):
1. Pregunta primero si la persona usuaria ya tiene una clave de API de ModelRush y comprueba si MODELRUSH_API_KEY está configurada en el entorno del servidor. Confirma únicamente que existe; nunca imprimas ni registres su valor.
2. Si no está configurada, detén la integración de la API y guía a la persona usuaria para que:
   - cree una clave de API en https://modelrush.ai/dashboard/keys;
   - identifique o cree el archivo de entorno de servidor correcto e ignorado por Git que use el proyecto (por ejemplo, .env.local) y añada un marcador MODELRUSH_API_KEY=;
   - pegue ella misma la clave real en ese archivo; nunca le pidas que envíe la clave por el chat;
   - añada la misma variable a las variables de entorno cifradas o a la configuración de Secrets de la plataforma de despliegue para producción, en lugar de escribirla en el código fuente.
3. Continúa solo después de confirmar que el servidor puede leer la variable, sin imprimirla en la terminal, en los registros ni en la respuesta final. Si sigue ausente, detén todas las peticiones autenticadas o potencialmente facturables e indica exactamente el siguiente paso.
​
Requisitos:
1. Inspecciona el lenguaje, el framework, el gestor de paquetes, la frontera de servidor, las convenciones de variables de entorno y la capa de IA existente. No hagas suposiciones.
2. Usa https://api.modelrush.ai/v1 como URL base de la API. Lee la clave Bearer únicamente desde la variable de entorno de servidor MODELRUSH_API_KEY. Escribe solo marcadores en los archivos de ejemplo de entorno y no expongas nunca la clave real en el código, los registros, Git o un bundle de cliente.
3. Llama primero a GET /v1/models y GET /v1/regions. Toma como fuente de verdad los model IDs, las modalidades, las operaciones, los límites y las regiones disponibles que devuelvan, junto con la documentación pública.
4. Diseña el adaptador en torno a cada operación. No des por hecho que todos los modelos aceptan mensajes de LLM ni devuelven Chat Completions:
   - reutiliza un cliente compatible con OpenAI para las operaciones compatibles de Chat, Embeddings o Rerank;
   - usa el esquema HTTP documentado de cada operación de imagen, vídeo, audio y voz;
   - en medios asíncronos, guarda el Prediction ID, gestiona queued / processing / succeeded / failed / cancelled / expired y admite sondeo o webhooks;
   - usa /v1/uploads para las entradas privadas en lugar de tratar rutas locales o URLs públicas permanentes como un diseño de producción.
5. Añade reintentos con retroceso exponencial acotado para los fallos 429, 5xx y de tiempo de espera. Nunca reintentes indefinidamente envíos no idempotentes.
6. Conserva los campos request_id, model, operation, region, status, usage y de facturación cuando existan, para que las peticiones sigan siendo rastreables en el panel.
7. Expón un único punto de entrada claro en la capa de aplicación, conservando las entradas, salidas y estados asíncronos propios de cada modalidad. No lo aplanes todo en un tipo LLM ficticio.
8. Verifica primero el descubrimiento con el endpoint no facturable GET /v1/models. Ejecuta una prueba de generación facturable solo tras una aprobación explícita.
9. Ejecuta el lint, la comprobación de tipos, las pruebas o la compilación que ya tenga el proyecto.
​
Criterios de aceptación:
- El archivo de ejemplo de entorno está actualizado y no contiene ningún secreto real.
- El alcance seleccionado se descubre y se enruta desde el Registry en producción, sin depender de nombres de agentes como Codex, Claude o Cursor.
- Las operaciones síncronas y asíncronas se tratan por separado, con errores e identificadores de petición rastreables.
- La respuesta final enumera los archivos modificados, los resultados de validación, las comprobaciones facturables no ejecutadas y los riesgos pendientes.
​
Documentación pública: https://modelrush.ai/docs