Choose how you want to use ModelRush

Integrate ModelRush into the current project and make the required code changes directly. This task is independent of any agent brand: inspect the project first, then choose the implementation that fits its architecture.
​
This integration covers every live ModelRush capability: text, code, image, video, and audio. Do not implement it as an LLM-only or Chat-Completions-only integration.
​
API key onboarding (complete this before making any ModelRush request):
1. First ask whether the user already has a ModelRush API key and check whether MODELRUSH_API_KEY is configured in the server environment. Confirm presence only; never print or log its value.
2. If it is not configured, pause the API integration and guide the user to:
   - create an API key at https://modelrush.ai/dashboard/keys;
   - identify or create the correct gitignored server environment file for the project (for example, .env.local) and add a MODELRUSH_API_KEY= placeholder;
   - paste the real key into that file themselves; never ask them to send the key in chat;
   - add the same variable to the hosting platform's encrypted environment variables or Secret settings for production instead of putting it in source code.
3. Resume only after confirming the server can read the variable, without printing it in the terminal, logs, or final response. If it is still missing, stop all authenticated or potentially billable requests and state the exact next step.
​
Requirements:
1. Inspect the language, framework, package manager, server boundary, environment-variable conventions, and existing AI layer. Do not guess.
2. Use https://api.modelrush.ai/v1 as the API base URL. Read the Bearer key only from the server-side MODELRUSH_API_KEY environment variable. Put placeholders only in environment example files, and never expose the real key in source, logs, Git, or a client bundle.
3. Call GET /v1/models and GET /v1/regions first. Use the returned model IDs, modalities, operations, limits, and available regions as the source of truth alongside the public docs.
4. Design the adapter around each operation. Do not assume every model accepts LLM messages or returns Chat Completions:
   - Reuse an existing OpenAI-compatible client for compatible Chat, Embeddings, or Rerank operations;
   - use each documented HTTP schema for image, video, audio, and voice operations;
   - for asynchronous media, persist the Prediction ID, handle queued / processing / succeeded / failed / cancelled / expired, and support polling or webhooks;
   - use /v1/uploads for private inputs instead of treating local paths or permanent public URLs as a production design.
5. Add bounded exponential-backoff retries for 429, 5xx, and timeout failures. Never retry non-idempotent submissions indefinitely.
6. Preserve request_id, model, operation, region, status, usage, and billing fields when present so requests remain traceable in the Dashboard.
7. Expose one clear application-layer entry point while preserving modality-specific inputs, outputs, and async state. Do not flatten everything into a fake LLM type.
8. Verify discovery with the non-billable GET /v1/models endpoint first. Run a billable generation smoke test only after explicit approval.
9. Run the project's existing lint, typecheck, tests, or build.
​
Acceptance criteria:
- The environment example is updated without a real secret.
- The selected scope is discovered and routed from the live Registry without depending on agent names such as Codex, Claude, or Cursor.
- Synchronous and asynchronous operations are handled separately, with traceable errors and request IDs.
- The final response lists changed files, validation results, any billable checks not run, and remaining risks.
​
Public docs: https://modelrush.ai/docs