API Reference¶

Continuum Router exposes an OpenAI-compatible API with additional administrative endpoints for monitoring and management. This document covers all available endpoints, request/response formats, and error handling.

Table of Contents¶

• Overview
• Authentication
• Core API Endpoints
  • Health Check
  • Version
  • List Models
  • Proxy a Backend Model List
  • Force-Refresh Models
  • Get Single Model
  • Chat Completions
  • Responses API
  • Retrieve or Delete a Stored Response
  • Responses Compact
  • Batch API
  • Image Generation
  • Image Edit (Inpainting)
  • Image Variations
  • Text Completions
  • Embeddings
  • Rerank
  • Sparse Embeddings
  • Files API
  • File Resolution in Chat Completions
• Anthropic Native API
  • Messages API
  • Token Counting
  • Models List
  • Claude Code Compatibility
• Admin Endpoints
• Configuration Management API
  • Configuration Query APIs
  • Configuration Modification APIs
  • Configuration Save/Restore APIs
  • Backend Management APIs
• Error Handling
• Rate Limiting
• Streaming
• Examples

Overview¶

Base URL¶

http://localhost:8080

Content Type¶

All requests and responses use application/json unless otherwise specified.

OpenAI Compatibility¶

Continuum Router provides OpenAI-compatible API surfaces for: - Chat completions with streaming - Text completions - Embeddings - Reranking (Cohere-compatible /v1/rerank) - Sparse embeddings (TEI/Jina-compatible /embed_sparse) - Image generation - Image editing/inpainting - Image variations - Files API (upload, list, retrieve, delete) - File resolution in chat completions (image_file references) - Model listing - Error response formats

Authentication¶

Continuum Router supports API key authentication with configurable enforcement modes.

Authentication Modes¶

The router supports two authentication modes for API endpoints:

Configuration¶

api_keys:
  # Authentication mode: "permissive" (default) or "blocking"
  mode: blocking

  # API key definitions
  api_keys:
    - key: "${API_KEY_1}"
      id: "key-production-1"
      user_id: "user-admin"
      organization_id: "org-main"
      scopes: [read, write, files, admin]

Protected Endpoints (when mode is blocking)¶

API-key middleware protects all routes in the core API router: /v1/models*, /v1/chat/completions, /v1/completions, /v1/embeddings, /v1/responses*, /v1/images/*, /v1/rerank, /embed_sparse, /anthropic/v1/messages*, /anthropic/v1/models, and feature-gated /v1/batches* routes.

Note: Health and version endpoints (/health, /version) are always accessible without authentication. Admin, Files, and Metrics endpoints have separate authentication mechanisms.

Making Authenticated Requests¶

Every protected route accepts the API key in either of two header forms: Authorization: Bearer <api_key> or the Anthropic-native x-api-key: <api_key>. Both forms work on every route, not only the /anthropic/* endpoints, so Anthropic SDKs and Claude Code (which set only ANTHROPIC_API_KEY and send it via x-api-key) authenticate the same way OpenAI-style clients do. When a request carries both headers, Authorization: Bearer takes precedence.

POST /v1/chat/completions HTTP/1.1
Authorization: Bearer sk-your-api-key
Content-Type: application/json

{
  "model": "gpt-4",
  "messages": [{"role": "user", "content": "Hello"}]
}

POST /v1/chat/completions HTTP/1.1
x-api-key: sk-your-api-key
Content-Type: application/json

{
  "model": "gpt-4",
  "messages": [{"role": "user", "content": "Hello"}]
}

Authentication Errors¶

When authentication fails, the API returns:

{
  "error": {
    "message": "Missing or invalid API key. Expected Authorization: Bearer <api_key> or x-api-key",
    "type": "authentication_error",
    "code": "invalid_api_key"
  }
}

Status Codes:

• 401 Unauthorized: Missing or invalid API key

Core API Endpoints¶

Health Check¶

Check the health status of the router service.

GET /health

Response:

{
  "status": "ok",
  "service": "continuum-router",
  "version": "1.14.0"
}

Status Codes:

• 200: Service is healthy

Version¶

Return the running router version.

GET /version

Response:

{
  "version": "1.14.0"
}

Status Codes:

• 200: Always returned; no authentication required

List Models¶

Retrieve all available models from all healthy backends.

GET /v1/models

Response:

{
  "object": "list",
  "data": [
    {
      "id": "gpt-4",
      "object": "model",
      "created": 1677610602,
      "owned_by": "openai-compatible",
      "permission": [],
      "root": "gpt-4",
      "parent": null
    },
    {
      "id": "llama2:7b",
      "object": "model", 
      "created": 1677610602,
      "owned_by": "local-ollama",
      "permission": [],
      "root": "llama2:7b",
      "parent": null
    }
  ]
}

Status Codes:

• 200: Models retrieved successfully
• 503: All backends are unhealthy

Features:

• Model Aggregation: Combines models from all healthy backends
• Deduplication: Removes duplicate models across backends
• Caching: An internal 60-second hard TTL with stale-while-revalidate and request coalescing
• Health Awareness: Only includes models from healthy backends

Proxy a Backend Model List¶

Return the raw /v1/models response from one selected eligible backend instead of aggregating all backends. This compatibility endpoint uses normal backend selection, retry, health, and caller backend-visibility rules.

GET /v1/models/proxy

Use GET /v1/models for the router's deduplicated aggregate catalog. Use this endpoint only when a client needs one backend's provider-native model-list payload.

Status Codes:

• 200: Selected backend response returned
• 502: Backend connection or gateway failure
• 503: No eligible healthy backend

Force-Refresh Models¶

Immediately invalidate the model-aggregation cache and synchronously re-aggregate from all configured backends. Returns the same OpenAI-compatible model list shape as GET /v1/models so the caller can use the response immediately.

This endpoint is designed for interactive "Refresh" actions in desktop clients (e.g. the "Refresh models" button in backend.ai-go). It bypasses the stale-while-revalidate and soft-TTL windows, triggering an upstream fetch from every backend before responding.

POST /v1/models/refresh

Response:

{
  "object": "list",
  "data": [
    {
      "id": "gpt-4o",
      "object": "model",
      "created": 1677610602,
      "owned_by": "openai-compatible"
    }
  ]
}

Status Codes:

• 200: Cache cleared and fresh model list returned
• 429 Too Many Requests: Force-refresh rate limit exceeded (3 requests per 5-second burst window, 12 per minute)

Rate Limiting:

The endpoint applies a tighter budget than the regular GET /v1/models because each call triggers an upstream fetch from every configured backend. The default limits are 3 requests per 5-second window and 12 per minute. Valid API keys receive separate buckets keyed by API key ID. Anonymous callers and requests with invalid bearer tokens share one global anonymous bucket, so spoofed Authorization, X-Forwarded-For, or X-Real-IP headers cannot bypass the force-refresh budget. Clients that exceed the limit receive 429 and should wait before retrying.

Cache policy:

The model-list cache currently uses internal fixed defaults: a 60-second hard TTL, an 80% soft TTL, stale-while-revalidate, request coalescing, and bounded empty-result backoff. These values and force-refresh availability are not fields in the public configuration schema.

Get Single Model¶

Retrieve information about a specific model, including its availability status and optional rich metadata.

GET /v1/models/{model}

Path Parameters:

Response (Basic):

{
  "id": "gpt-4",
  "object": "model",
  "created": 1677610602,
  "owned_by": "openai",
  "available": true
}

Response (With Extended Metadata):

When model metadata is available in model-metadata.yaml, the response includes additional fields:

{
  "id": "gpt-4o",
  "object": "model",
  "created": 1704067200,
  "owned_by": "openai",
  "available": true,
  "supported_methods": ["chat.completions"],
  "features": ["chat", "vision", "audio", "code"],
  "max_tokens": 16384,
  "metadata": {
    "display_name": "GPT-4o",
    "developer": "OpenAI",
    "summary": "Multimodal optimized model with text, image, and audio capabilities.",
    "knowledge_cutoff": "2023-10",
    "relative_speed": 4,
    "pricing": {
      "input_tokens": 2.50,
      "output_tokens": 10.0
    },
    "limits": {
      "context_window": 128000,
      "max_output": 16384
    }
  }
}

Response Fields:

Metadata Object Fields:

Supported Methods Mapping:

The supported_methods field is derived from model capabilities:

Status Codes:

• 200: Model found and information returned
• 404: Model does not exist in any configured backend

Features:

• OpenAI-Compatible: Response format matches OpenAI API with additional extension fields
• Health-Aware: The available field reflects real-time backend health status
• Privacy: Does not expose internal backend information
• Optional Metadata: Extended fields are present only when metadata is available
• Rich Metadata: Includes display name, developer, capabilities, and context-window limits to inform client-side model selection

Model Availability Algorithm:

The available field is determined by the following algorithm:

The algorithm uses short-circuit evaluation: it returns true as soon as the first healthy backend is found, avoiding unnecessary health checks for remaining backends. This optimizes performance when backends are generally healthy.

Performance Optimization:

• Fast Path: If the model cache is valid, lookup is O(n) where n = number of models
• Slow Path: If cache is empty/expired, triggers one-time aggregation with singleflight protection to prevent cache stampede
• Stale-While-Revalidate: Cache serves stale data while refreshing in background

Example Request:

curl http://localhost:8080/v1/models/gpt-4o

Example Response (Model Available with Full Metadata):

{
  "id": "gpt-4o",
  "object": "model",
  "created": 1704067200,
  "owned_by": "openai",
  "available": true,
  "supported_methods": ["chat.completions"],
  "features": ["chat", "vision", "audio", "code"],
  "max_tokens": 16384,
  "metadata": {
    "display_name": "GPT-4o",
    "developer": "OpenAI",
    "summary": "Multimodal optimized model with text, image, and audio capabilities; faster and cheaper than GPT-4 Turbo.",
    "knowledge_cutoff": "2023-10",
    "relative_speed": 4,
    "pricing": {
      "input_tokens": 2.50,
      "output_tokens": 10.0
    },
    "limits": {
      "context_window": 128000,
      "max_output": 16384
    }
  }
}

Example Response (Model Without Extended Metadata):

For models without metadata in model-metadata.yaml, only the basic fields are returned:

{
  "id": "custom-model",
  "object": "model",
  "created": 1677610602,
  "owned_by": "local",
  "available": true
}

Example Response (Model Exists but Unavailable):

{
  "id": "gpt-4o",
  "object": "model",
  "created": 1704067200,
  "owned_by": "openai",
  "available": false,
  "supported_methods": ["chat.completions"],
  "features": ["chat", "vision", "audio", "code"],
  "max_tokens": 16384,
  "metadata": {
    "display_name": "GPT-4o",
    "developer": "OpenAI"
  }
}

Chat Completions¶

Generate chat completions using the OpenAI Chat API format.

POST /v1/chat/completions

Request Body:

{
  "model": "gpt-3.5-turbo",
  "messages": [
    {
      "role": "system",
      "content": "You are a helpful assistant."
    },
    {
      "role": "user", 
      "content": "Explain quantum computing in simple terms."
    }
  ],
  "temperature": 0.7,
  "max_tokens": 150,
  "top_p": 1.0,
  "frequency_penalty": 0.0,
  "presence_penalty": 0.0,
  "stream": false,
  "stop": null,
  "logit_bias": {},
  "user": "user123"
}

Parameters:

Valid reasoning_effort values by backend:

For detailed conversion tables and backend-specific behavior, see Reasoning Effort Architecture.

For OpenAI models, the router applies the same exact model-specific validation to streaming and non-streaming requests. Unsupported values return 400 invalid_request_error; the router never rewrites auto, xhigh, or max to a different effort. Other providers retain their provider-specific conversion behavior shown above.

Response (Non-streaming):

{
  "id": "chatcmpl-123456789",
  "object": "chat.completion",
  "created": 1677652288,
  "model": "gpt-3.5-turbo",
  "choices": [
    {
      "index": 0,
      "message": {
        "role": "assistant",
        "content": "Quantum computing uses quantum mechanical phenomena like superposition and entanglement to process information..."
      },
      "finish_reason": "stop"
    }
  ],
  "usage": {
    "prompt_tokens": 25,
    "completion_tokens": 150,
    "total_tokens": 175
  }
}

Response (Streaming): When stream: true, the response uses Server-Sent Events (SSE):

data: {"id":"chatcmpl-123","object":"chat.completion.chunk","created":1677652288,"model":"gpt-3.5-turbo","choices":[{"delta":{"role":"assistant","content":""},"index":0,"finish_reason":null}]}

data: {"id":"chatcmpl-123","object":"chat.completion.chunk","created":1677652288,"model":"gpt-3.5-turbo","choices":[{"delta":{"content":"Quantum"},"index":0,"finish_reason":null}]}

data: {"id":"chatcmpl-123","object":"chat.completion.chunk","created":1677652288,"model":"gpt-3.5-turbo","choices":[{"delta":{"content":" computing"},"index":0,"finish_reason":null}]}

data: {"id":"chatcmpl-123","object":"chat.completion.chunk","created":1677652288,"model":"gpt-3.5-turbo","choices":[{"delta":{},"index":0,"finish_reason":"stop"}]}

data: [DONE]

Status Codes:

• 200: Completion generated successfully
• 400: Invalid request format or parameters
• 404: Model not found on any healthy backend
• 502: Backend connection error
• 504: Request timeout
• 503: All backends unhealthy

Features:

• Model-Based Routing: Automatically routes to backends serving the requested model
• Load Balancing: Distributes load across healthy backends
• Streaming Support: Real-time response streaming via SSE
• Error Recovery: Automatic retry on transient failures
• Request Deduplication: Prevents duplicate processing of identical requests
• Reasoning Parameter Normalization: Automatically normalizes nested reasoning format to flat reasoning_effort format; removes reasoning parameters for models that don't support them
• Transparent Responses-API routing: When the requested model is marked responses_only: true (e.g., gpt-5-pro, gpt-5.2-pro, gpt-5.4-pro, gpt-5.5-pro), the router transparently dispatches to the upstream /v1/responses endpoint and translates the result back into a strict-mode chat.completion (or chat.completion.chunk for streaming) envelope, so clients keep using /v1/chat/completions unchanged. Only OpenAI and Azure OpenAI backends serve these models; pairing a responses_only model with another backend type produces a 400 invalid_request_error before dispatch. See Responses-API-only Models for the full list and configuration.

Responses API¶

Generate responses using OpenAI's Responses API format. This endpoint provides an alternative interface to Chat Completions, internally converting requests to the Chat Completions format for backend processing.

POST /v1/responses

Request Body:

{
  "model": "gpt-4o",
  "input": "Explain quantum computing in simple terms.",
  "instructions": "You are a helpful assistant that explains complex topics simply.",
  "max_output_tokens": 1000,
  "temperature": 0.7,
  "reasoning": {
    "effort": "high"
  }
}

Parameters:

Tool Definition Format:

The Responses API uses a flat tool format where function properties are at the same level as the type field. This differs from the Chat Completions API which uses a nested function object.

{
  "type": "function",
  "name": "get_weather",
  "description": "Get weather for a location",
  "parameters": {
    "type": "object",
    "properties": {
      "location": {"type": "string", "description": "City name"}
    },
    "required": ["location"]
  },
  "strict": true
}

Other supported tool types include code_interpreter, file_search, web_search, and computer_use.

Multi-Modal Input Types:

When input is an array of items, each item can be a message containing multi-modal content parts. The following content part types are supported:

Message Roles:

Each message item carries one of five roles. The router accepts all five for /v1/responses and translates them per backend.

The router preserves arrival order when multiple developer and system messages are present. When the target backend (Anthropic, Gemini) only accepts a single instruction slot, the router concatenates them with a blank-line separator so no instruction text is silently dropped.

Item References:

An input item of the form {"type": "item_reference", "id": "item_..."} points at an output item from a previously stored response. This is how the OpenAI and Vercel AI SDKs submit multi-step tool round-trips by default: instead of echoing the full function-call item back, step 2 references the item produced in step 1.

• On the OpenAI / Azure OpenAI passthrough path, references are forwarded unchanged and the upstream resolves them.
• On the converted paths (Anthropic, Gemini, and chat-completions-backed routes), the router resolves each reference from its session store before dispatch, rewriting it to the inline function_call, message, or function_call_output item it points to. References are de-duplicated by call_id (first wins).
• Streamed responses participate as well: the accumulated response is stored when the stream completes, so a follow-up request can reference items produced by a streaming step.
• An unresolvable reference returns HTTP 400 naming the id, and a request may carry at most 256 references.

Input File Format:

The input_file content part supports three input methods:

{
  "type": "input_file",
  "filename": "document.pdf",
  "file_data": "data:application/pdf;base64,JVBERi0xLjQ..."
}

Input Image Format:

{
  "type": "input_image",
  "image_url": "data:image/png;base64,iVBORw0KGgo...",
  "detail": "high"
}

Exactly one of image_url or file_id must be present. A part with neither is rejected with 400. When file_id is provided, the file is resolved to an inline base64 data URL before the request reaches the backend; file ownership is verified and a 10MB size limit applies, matching the input_file + file_id path.

Multi-Modal Request Example:

curl -X POST http://localhost:8080/v1/responses \
  -H "Content-Type: application/json" \
  -d '{
    "model": "gpt-4o",
    "input": [
      {
        "type": "message",
        "role": "user",
        "content": [
          {"type": "input_text", "text": "What does this document say?"},
          {"type": "input_file", "filename": "report.pdf", "file_data": "data:application/pdf;base64,..."}
        ]
      }
    ]
  }'

Security Notes:

• External URLs in file_url are validated to prevent SSRF attacks
• Private IP addresses and localhost URLs are rejected
• Only HTTPS URLs are recommended for external files
• The file_id field references files uploaded via the Files API. Files are resolved and converted to base64 before sending to backends. File ownership is verified and a 10MB size limit applies for file injection

Reasoning Parameter:

The reasoning parameter controls the reasoning effort level for reasoning-capable models. It uses a nested format:

{
  "reasoning": {
    "effort": "high"
  }
}

Valid effort values:

The router automatically converts this nested format to the flat reasoning_effort format used by Chat Completions backends. Invalid effort levels are rejected with a 400 Bad Request error.

Example Request with Reasoning:

curl -X POST http://localhost:8080/v1/responses \
  -H "Content-Type: application/json" \
  -d '{
    "model": "o1",
    "input": "Solve this complex mathematical problem step by step.",
    "reasoning": {
      "effort": "high"
    }
  }'

Response:

{
  "id": "resp_abc123",
  "object": "response",
  "created_at": 1699000000,
  "model": "o1",
  "output": [
    {
      "type": "message",
      "id": "msg_001",
      "role": "assistant",
      "content": [
        {
          "type": "output_text",
          "text": "Let me solve this step by step..."
        }
      ]
    }
  ],
  "usage": {
    "input_tokens": 25,
    "output_tokens": 150
  },
  "status": "completed"
}

Status Codes:

• 200: Response generated successfully
• 400: Invalid request format, parameters, or invalid reasoning effort value
• 404: Model not found on any healthy backend
• 502: Backend connection error
• 504: Request timeout
• 503: All backends unhealthy

Features:

• Smart Routing: Routes requests based on backend capabilities - native pass-through for OpenAI/Azure, automatic conversion for others
• Native Pass-through: For OpenAI and Azure OpenAI backends, requests are forwarded directly to /v1/responses endpoint, preserving all native features
• Automatic Conversion: For other backends (Anthropic, Gemini, vLLM, Ollama, etc.), converts Responses API format to their native format
• Reasoning Support: Full support for reasoning parameter with type-safe validation
• Multi-Backend Support: Works with OpenAI, Anthropic, Gemini, Ollama, vLLM, and other backends
• Streaming Support: Real-time response streaming via SSE when stream: true
• Session Management: Supports multi-turn conversations via previous_response_id

Routing Strategy:

The router automatically determines the best strategy for each backend:

Pass-through Benefits:

When using OpenAI or Azure OpenAI backends with pass-through mode:

• Native PDF file support (Chat Completions only supports images)
• Preserved reasoning state between turns for better performance
• Access to built-in tools (web_search, file_search, etc.)
• Better cache utilization (40-80% improvement per OpenAI documentation)
• Full compatibility with the latest OpenAI Responses API features

Anthropic Native Conversion Benefits:

When using Anthropic (Claude) backends with native conversion:

• Native PDF file support via Anthropic's document understanding
• Image file support with automatic format detection
• Extended thinking support for Claude 3+ models
• SSRF protection for external file URLs
• Media type whitelisting for security

Retrieve or Delete a Stored Response¶

Responses created with store: true can be retrieved or deleted by ID. Stored sessions are process-local and are scoped to the authenticated API-key principal (api_keys[].user_id) that created the response. Both Authorization: Bearer <key> and X-API-Key: <key> credentials use the same configured identity namespace. Missing, expired, unauthenticated, or differently scoped requests all return 404.

Migration from X-User-ID Scoping¶

X-User-ID is not an authorization boundary for the Responses API. The router ignores it for stored response access, previous_response_id context reconstruction, item-reference resolution, and local Files API ownership checks, and it is not forwarded to backends. Deployments that previously multiplexed multiple end users behind one shared router API key by setting X-User-ID must migrate to one router API key per isolated user or tenant, or place their own trusted service in front of the router and keep per-user state outside the router's stored Responses session and Files API ownership controls.

GET /v1/responses/{response_id}
DELETE /v1/responses/{response_id}

A successful GET returns the stored response object. A successful DELETE returns:

{
  "id": "resp_abc123",
  "object": "response.deleted",
  "deleted": true
}

Responses Compact¶

Compact a conversation context by summarizing or compressing a sequence of input items. For OpenAI and Azure OpenAI backends, the request is forwarded directly to the backend's native /v1/responses/compact endpoint. Other backends return HTTP 501 (Not Implemented), as context compaction is not natively supported.

POST /v1/responses/compact

Request Body:

{
  "model": "gpt-4o",
  "instructions": "Summarize the key points from this conversation.",
  "input": [
    {
      "type": "message",
      "role": "user",
      "content": [{"type": "input_text", "text": "What is the capital of France?"}]
    },
    {
      "type": "message",
      "role": "assistant",
      "content": [{"type": "output_text", "text": "The capital of France is Paris."}]
    }
  ]
}

Parameters:

Response:

{
  "id": "cmpt_abc123",
  "object": "response.compaction",
  "created_at": 1699000000,
  "output": [
    {
      "type": "text",
      "text": "Compacted conversation summary..."
    }
  ],
  "usage": {
    "input_tokens": 120,
    "output_tokens": 45
  }
}

Status Codes:

• 200: Compaction successful
• 400: Invalid request (empty model, empty input, instructions too long)
• 501: Backend does not support native context compaction
• 502: Backend connection error
• 504: Request timeout

Batch API (control-plane builds)¶

The OpenAI-style Batch API is compiled only with the control-plane Cargo feature. It is absent from default source builds. Official release binaries compile the feature, but the routes remain inert unless control_plane.enabled, policy enforcement, and control_plane.batch.enabled are active and the Hub marks the presented key/tier as batch-eligible.

A hub-synced API key is required. Ownership checks deliberately return the same 404 for unknown and other-key IDs. Results return 409 until available. The selected batch backend may be OpenAI-compatible or native Anthropic; the router presents one common surface. x-continuum-batch: off always opts a request out and cannot be overridden by policy.

Image Generation¶

Generate images using OpenAI's DALL-E, GPT Image models, or Google's Nano Banana (Gemini) models.

POST /v1/images/generations

Request Body:

{
  "model": "dall-e-3",
  "prompt": "A serene Japanese garden with cherry blossoms",
  "n": 1,
  "size": "1024x1024",
  "quality": "standard",
  "response_format": "url"
}

Parameters:

Model-specific constraints:

Quality Parameter (GPT Image Models):

For GPT Image models, standard maps to medium and hd maps to high.

Output Format Options (GPT Image Models):

Note: Transparent background (background: "transparent") requires png or webp format.

Nano Banana (Gemini) Models:

Nano Banana provides access to Google's Gemini image generation capabilities through an OpenAI-compatible interface:

• nano-banana: Maps to Gemini 2.5 Flash Image - fast, general-purpose image generation
• nano-banana-pro: Maps to Gemini 2.0 Flash Image - advanced model with high-resolution support (up to 4K)

Nano Banana Size Mapping:

The router automatically converts OpenAI-style size parameters to Gemini's aspectRatio and imageSize format:

The conversion sends the following Gemini API structure:

{
  "contents": [{"parts": [{"text": "Your prompt"}]}],
  "generationConfig": {
    "imageConfig": {
      "aspectRatio": "3:2",
      "imageSize": "1K"
    }
  }
}

Example Nano Banana Request:

{
  "model": "nano-banana",
  "prompt": "A white siamese cat with blue eyes, photorealistic",
  "n": 1,
  "size": "1024x1024",
  "response_format": "b64_json"
}

Response:

{
  "created": 1677652288,
  "data": [
    {
      "url": "https://oaidalleapiprodscus.blob.core.windows.net/...",
      "revised_prompt": "A tranquil Japanese garden featuring..."
    }
  ]
}

Response (with b64_json):

{
  "created": 1677652288,
  "data": [
    {
      "b64_json": "/9j/4AAQSkZJRgABAQAA...",
      "revised_prompt": "A tranquil Japanese garden featuring..."
    }
  ]
}

Nano Banana Response Notes:

• When using response_format: "url" with Nano Banana, the image is returned as a data URL (data:image/png;base64,...) since Gemini's native API returns inline base64 data
• The revised_prompt field contains any text response from Gemini describing the generated image

Streaming Image Generation (GPT Image Models):

When stream: true is specified for GPT Image models, the response will be streamed as Server-Sent Events (SSE):

Example Streaming Request:

{
  "model": "gpt-image-1",
  "prompt": "A beautiful sunset over mountains",
  "stream": true,
  "partial_images": 2,
  "response_format": "b64_json"
}

Streaming Response Format:

data: {"type":"image_generation.partial_image","partial_image_index":0,"b64_json":"...","created":1702345678}

data: {"type":"image_generation.partial_image","partial_image_index":1,"b64_json":"...","created":1702345679}

data: {"type":"image_generation.complete","b64_json":"...","created":1702345680}

data: {"type":"image_generation.usage","usage":{"input_tokens":25,"output_tokens":1024}}

data: {"type":"done"}

SSE Event Types:

Example GPT Image Request with New Options:

{
  "model": "gpt-image-1.5",
  "prompt": "A white cat with blue eyes, photorealistic",
  "size": "auto",
  "quality": "high",
  "output_format": "webp",
  "output_compression": 85,
  "background": "transparent",
  "response_format": "b64_json"
}

Status Codes:

• 200: Image(s) generated successfully
• 400: Invalid request (e.g., invalid size for model, n > 1 for DALL-E 3)
• 401: Invalid API key
• 429: Rate limit exceeded
• 500: Backend error
• 503: Gemini backend unavailable (for Nano Banana models)

Timeout Configuration: Image generation requests use a configurable timeout (default: 3 minutes). See timeouts.request.image_generation in configuration.

Image Edit (Inpainting)¶

Edit existing images using OpenAI's inpainting capabilities. This endpoint allows you to modify specific regions of an image based on a text prompt and optional mask. Supports GPT Image models and DALL-E 2.

POST /v1/images/edits
Content-Type: multipart/form-data

Request Parameters (multipart/form-data):

Supported Models and Sizes:

Note: DALL-E 3 and Gemini (nano-banana) do NOT support image editing via this endpoint. Gemini uses semantic masking via natural language, which is incompatible with OpenAI's mask-based editing format.

Image Requirements:

• Format: PNG only
• Size: Less than 4MB
• Dimensions: Must be square (width equals height)

Mask Requirements:

• Format: PNG with alpha channel (RGBA)
• Dimensions: Must match the source image exactly
• Transparent areas: Indicate regions to edit/generate
• Opaque areas: Indicate regions to preserve

Example Request:

curl -X POST http://localhost:8080/v1/images/edits \
  -F "image=@source_image.png" \
  -F "mask=@mask.png" \
  -F "prompt=A sunlit indoor lounge area with a pool containing a flamingo" \
  -F "n=1" \
  -F "size=1024x1024" \
  -F "response_format=url"

Example Request (without mask):

curl -X POST http://localhost:8080/v1/images/edits \
  -F "image=@source_image.png" \
  -F "prompt=Add a sunset in the background" \
  -F "n=1" \
  -F "size=512x512"

Response:

{
  "created": 1677652288,
  "data": [
    {
      "url": "https://oaidalleapiprodscus.blob.core.windows.net/..."
    }
  ]
}

Response (with b64_json):

{
  "created": 1677652288,
  "data": [
    {
      "b64_json": "/9j/4AAQSkZJRgABAQAA..."
    }
  ]
}

Status Codes:

• 200: Image(s) edited successfully
• 400: Invalid request (e.g., non-square image, invalid size, missing required field)
• 401: Invalid API key
• 503: OpenAI backend unavailable

Error Examples:

Non-square image:

{
  "error": {
    "message": "Image must be square (800x600 is not square)",
    "type": "invalid_request_error",
    "param": "image",
    "code": "image_not_square"
  }
}

Mask dimension mismatch:

{
  "error": {
    "message": "Mask dimensions (256x256) do not match image dimensions (512x512)",
    "type": "invalid_request_error",
    "param": "mask",
    "code": "dimension_mismatch"
  }
}

Unsupported model:

{
  "error": {
    "message": "Model 'dall-e-3' does not support image editing. Supported models: gpt-image-1, gpt-image-1-mini, gpt-image-1.5, dall-e-2. Note: dall-e-3 does NOT support image editing.",
    "type": "invalid_request_error",
    "param": "model",
    "code": "unsupported_model"
  }
}

Notes:

• Supported models: gpt-image-1, gpt-image-1-mini, gpt-image-1.5, dall-e-2
• DALL-E 3 does NOT support image editing via API
• Gemini (nano-banana) is NOT supported - uses different editing approach (semantic masking)
• When no mask is provided, the entire image may be modified
• The source image should have transparent regions if editing without a mask
• Request timeout uses the image generation timeout configuration

Image Variations¶

Generate variations of an existing image using OpenAI's DALL-E 2 model.

POST /v1/images/variations
Content-Type: multipart/form-data

Form Fields:

Example Request:

curl -X POST http://localhost:8080/v1/images/variations \
  -F "image=@source_image.png" \
  -F "model=dall-e-2" \
  -F "n=2" \
  -F "size=512x512" \
  -F "response_format=url"

Response:

{
  "created": 1677652288,
  "data": [
    {
      "url": "https://oaidalleapiprodscus.blob.core.windows.net/..."
    },
    {
      "url": "https://oaidalleapiprodscus.blob.core.windows.net/..."
    }
  ]
}

Response (with b64_json):

{
  "created": 1677652288,
  "data": [
    {
      "b64_json": "/9j/4AAQSkZJRgABAQAA..."
    }
  ]
}

Model Support:

Image Requirements:

• Format: PNG only
• Size: Less than 4MB
• Dimensions: Must be square (width == height)
• Supported input sizes: Any square dimensions (will be processed by the model)

Error Scenarios:

Status Codes:

• 200: Variation(s) generated successfully
• 400: Invalid request (invalid format, non-square image, unsupported model)
• 401: Invalid API key
• 429: Rate limit exceeded
• 500: Backend error
• 503: Backend unavailable

Text Completions¶

Generate text completions using the OpenAI Completions API format.

POST /v1/completions

Request Body:

{
  "model": "gpt-3.5-turbo-instruct",
  "prompt": "Once upon a time in a distant galaxy",
  "max_tokens": 100,
  "temperature": 0.7,
  "top_p": 1.0,
  "frequency_penalty": 0.0,
  "presence_penalty": 0.0,
  "stream": false,
  "stop": null,
  "logit_bias": {},
  "user": "user123"
}

Response:

{
  "id": "cmpl-123456789",
  "object": "text_completion",
  "created": 1677652288,
  "model": "gpt-3.5-turbo-instruct",
  "choices": [
    {
      "text": ", there lived a young explorer named Zara who dreamed of discovering new worlds...",
      "index": 0,
      "finish_reason": "stop",
      "logprobs": null
    }
  ],
  "usage": {
    "prompt_tokens": 10,
    "completion_tokens": 90,
    "total_tokens": 100
  }
}

Status Codes: Same as Chat Completions

Embeddings¶

Generate embeddings for input text using the OpenAI Embeddings API format.

POST /v1/embeddings

Request Body:

{
  "model": "text-embedding-3-small",
  "input": "The quick brown fox jumps over the lazy dog",
  "encoding_format": "float",
  "dimensions": 512,
  "user": "user123"
}

Request Parameters:

Input Format Examples:

Single string:

{
  "model": "text-embedding-3-small",
  "input": "Hello, world!"
}

Array of strings:

{
  "model": "text-embedding-3-large",
  "input": [
    "First text to embed",
    "Second text to embed",
    "Third text to embed"
  ]
}

Token arrays:

{
  "model": "text-embedding-ada-002",
  "input": [[1234, 5678, 9012], [3456, 7890, 1234]]
}

Multimodal content parts (Gemini Embedding 2 only):

{
  "model": "gemini-embedding-2",
  "input": [
    {"type": "text", "text": "A photo of a golden retriever"},
    {"type": "image_url", "image_url": {"url": "data:image/jpeg;base64,/9j/4AAQ..."}}
  ]
}

Response:

{
  "object": "list",
  "data": [
    {
      "object": "embedding",
      "index": 0,
      "embedding": [0.0023064255, -0.009327292, 0.0045318254, ...]
    }
  ],
  "model": "text-embedding-3-small",
  "usage": {
    "prompt_tokens": 8,
    "total_tokens": 8
  }
}

Response Fields:

Supported Models:

Status Codes:

• 200: Embeddings generated successfully
• 400: Invalid request (missing model/input, invalid dimensions)
• 401: Invalid API key
• 404: Model not found or doesn't support embeddings
• 429: Rate limit exceeded
• 500: Backend error
• 503: Backend unavailable

Features:

• Multiple Input Formats: Supports single string, array of strings, token arrays, or multimodal content parts
• Multimodal Embeddings: gemini-embedding-2 and gemini-embedding-2-preview accept mixed text, image, audio, video, and document parts in a single request
• Dimension Control: For text-embedding-3-* and gemini-embedding-2* models, specify custom dimensions for reduced vector size
• Backend Agnostic: Routes to appropriate backend based on model
• Load Balancing: Applies configured load balancing strategy
• Error Handling: Returns 400 with a clear message when multimodal input is sent to a text-only model

Multimodal Content Part Types (Gemini Embedding 2 only):

Example Request:

curl -X POST http://localhost:8080/v1/embeddings \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer your-api-key" \
  -d '{
    "model": "text-embedding-3-small",
    "input": "The quick brown fox jumps over the lazy dog",
    "encoding_format": "float"
  }'

Example with Multiple Inputs:

curl -X POST http://localhost:8080/v1/embeddings \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer your-api-key" \
  -d '{
    "model": "text-embedding-3-large",
    "input": [
      "First document text",
      "Second document text",
      "Third document text"
    ]
  }'

Example with Custom Dimensions:

curl -X POST http://localhost:8080/v1/embeddings \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer your-api-key" \
  -d '{
    "model": "text-embedding-3-small",
    "input": "Sample text",
    "dimensions": 512
  }'

Example with Multimodal Input (Gemini Embedding 2):

curl -X POST http://localhost:8080/v1/embeddings \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer your-api-key" \
  -d '{
    "model": "gemini-embedding-2",
    "input": [
      {"type": "text", "text": "A photo of a sunset over the ocean"},
      {"type": "image_url", "image_url": {"url": "data:image/jpeg;base64,/9j/4AAQ..."}}
    ],
    "dimensions": 768
  }'

Rerank¶

Rerank documents based on their relevance to a query using the Cohere-compatible Rerank API. This is commonly used as a second-stage retrieval step after initial vector search to improve accuracy.

POST /v1/rerank

Request Body:

{
  "model": "bge-reranker-v2-m3",
  "query": "What is machine learning?",
  "documents": ["Document 1 content", "Document 2 content", "Document 3 content"],
  "top_n": 3,
  "return_documents": false
}

Request Parameters:

Document Format Options:

Simple string array:

{
  "model": "bge-reranker-v2-m3",
  "query": "What is deep learning?",
  "documents": [
    "Deep learning uses neural networks with multiple layers",
    "Machine learning is a subset of artificial intelligence",
    "Natural language processing deals with text understanding"
  ]
}

Structured documents with text field:

{
  "model": "rerank-english-v3.0",
  "query": "What is deep learning?",
  "documents": [
    {"text": "Deep learning uses neural networks with multiple layers"},
    {"text": "Machine learning is a subset of artificial intelligence"}
  ]
}

Response:

{
  "results": [
    {
      "index": 0,
      "relevance_score": 0.95
    },
    {
      "index": 2,
      "relevance_score": 0.72
    },
    {
      "index": 1,
      "relevance_score": 0.45
    }
  ],
  "model": "bge-reranker-v2-m3",
  "id": "rerank-abc123",
  "usage": {
    "prompt_tokens": 150,
    "total_tokens": 150
  }
}

Response with Documents (when return_documents: true):

{
  "results": [
    {
      "index": 0,
      "relevance_score": 0.95,
      "document": {
        "text": "Deep learning uses neural networks with multiple layers"
      }
    }
  ],
  "model": "bge-reranker-v2-m3"
}

Response Fields:

Supported Backends:

Status Codes:

• 200: Documents reranked successfully
• 400: Invalid request (missing model/query/documents, empty documents array)
• 401: Invalid API key
• 404: Model not found or doesn't support reranking
• 429: Rate limit exceeded
• 500: Backend error
• 503: Backend unavailable

Use Cases:

• Two-stage retrieval: Use vector search to retrieve candidates, then rerank for higher precision
• RAG systems: Improve context quality by reranking retrieved documents before LLM processing
• Search result refinement: Reorder search results based on semantic relevance

Example Request:

curl -X POST http://localhost:8080/v1/rerank \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer your-api-key" \
  -d '{
    "model": "bge-reranker-v2-m3",
    "query": "What are the benefits of renewable energy?",
    "documents": [
      "Solar panels convert sunlight into electricity",
      "Wind turbines generate power from wind",
      "Coal is a fossil fuel used for electricity"
    ],
    "top_n": 2
  }'

Sparse Embeddings¶

Generate sparse embeddings for input text using the TEI/Jina-compatible Sparse Embedding API. Sparse embeddings (e.g., SPLADE) preserve lexical information through explicit term weights, complementing dense embeddings for hybrid search.

POST /embed_sparse

Request Body:

{
  "model": "naver/splade-v3",
  "input": "What is sparse embedding?"
}

Request Parameters:

Input Format Examples:

Single string:

{
  "model": "naver/splade-v3",
  "input": "What is sparse embedding?"
}

Array of strings:

{
  "model": "naver/splade-v3",
  "input": [
    "First text to embed",
    "Second text to embed",
    "Third text to embed"
  ]
}

Response:

{
  "data": [
    {
      "index": 0,
      "sparse_embedding": {
        "indices": [123, 456, 789, 1024, 2048],
        "values": [0.5, 0.3, 0.1, 0.8, 0.2]
      }
    }
  ],
  "model": "naver/splade-v3",
  "usage": {
    "prompt_tokens": 8,
    "total_tokens": 8
  }
}

Response Fields:

Understanding Sparse Vectors:

A sparse vector only stores non-zero values along with their vocabulary indices. For example:

• indices: [123, 456, 789] - positions in the vocabulary
• values: [0.5, 0.3, 0.1] - weights for those terms

This is memory-efficient for high-dimensional vectors with few non-zero elements (typically 100-500 non-zero values out of 30,000+ vocabulary size).

Supported Backends:

Status Codes:

• 200: Sparse embeddings generated successfully
• 400: Invalid request (missing model/input, empty input)
• 401: Invalid API key
• 404: Model not found or doesn't support sparse embeddings
• 429: Rate limit exceeded
• 500: Backend error
• 503: Backend unavailable

Use Cases:

• Hybrid search: Combine dense (semantic) and sparse (lexical) retrieval for better results
• Keyword matching: Exact term matching with learned weights
• Domain-specific retrieval: Better handling of specialized terminology and rare words
• Cross-lingual retrieval: Some SPLADE models support multilingual sparse retrieval

Example Request:

curl -X POST http://localhost:8080/embed_sparse \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer your-api-key" \
  -d '{
    "model": "naver/splade-v3",
    "input": "What are the benefits of sparse embeddings for search?"
  }'

Example with Multiple Inputs:

curl -X POST http://localhost:8080/embed_sparse \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer your-api-key" \
  -d '{
    "model": "naver/splade-v3",
    "input": [
      "First query text",
      "Second query text"
    ]
  }'

Files API¶

The Files API allows you to upload, manage, and use files in chat completions. Uploaded files can be referenced in messages using the image_file content type, and the router automatically resolves these references by injecting the file content.

Upload File¶

Upload a file for use in chat completions.

POST /v1/files
Content-Type: multipart/form-data

Form Fields:

Example:

curl -X POST http://localhost:8080/v1/files \
  -F "file=@image.png" \
  -F "purpose=vision"

Response:

{
  "id": "file-abc123def456",
  "object": "file",
  "bytes": 12345,
  "created_at": 1699061776,
  "filename": "image.png",
  "purpose": "vision"
}

Status Codes:

• 200: File uploaded successfully
• 400: Invalid request (missing file, invalid purpose)
• 413: File too large (exceeds configured max_file_size)

List Files¶

Retrieve a list of uploaded files.

GET /v1/files
GET /v1/files?purpose=vision

Query Parameters:

Response:

{
  "object": "list",
  "data": [
    {
      "id": "file-abc123def456",
      "object": "file",
      "bytes": 12345,
      "created_at": 1699061776,
      "filename": "image.png",
      "purpose": "vision"
    }
  ]
}

Get File Metadata¶

Retrieve metadata for a specific file.

GET /v1/files/{file_id}

Response:

{
  "id": "file-abc123def456",
  "object": "file",
  "bytes": 12345,
  "created_at": 1699061776,
  "filename": "image.png",
  "purpose": "vision"
}

Status Codes:

• 200: File metadata retrieved
• 404: File not found

Download File Content¶

Download the content of an uploaded file.

GET /v1/files/{file_id}/content

Response: Binary file content with appropriate Content-Type header.

Status Codes:

• 200: File content returned
• 404: File not found

Delete File¶

Delete an uploaded file.

DELETE /v1/files/{file_id}

Response:

{
  "id": "file-abc123def456",
  "object": "file",
  "deleted": true
}

Status Codes:

• 200: File deleted successfully
• 404: File not found

Error Bodies¶

Every Files API error uses the OpenAI envelope: an error object with message, type, and code.

Client-caused failures name what the request got wrong, including the file_id the caller supplied:

{
  "error": {
    "message": "file not found: file-abc123def456",
    "type": "invalid_request_error",
    "code": "file_not_found"
  }
}

Server-side failures return a fixed message instead of the router's internal diagnostics. The type and code still distinguish the cause, so a client that branches on them is unaffected:

{
  "error": {
    "message": "storage error: the file operation could not be completed",
    "type": "server_error",
    "code": "storage_error"
  }
}

The full diagnostic (the absolute path under files.storage_path, the temporary upload filename, and the underlying operating-system error) is written to the router log at ERROR level and is never placed in a response body. It is deliberately not exposed through a configuration switch: an operator debugging a storage failure reads the log, and a caller has no use for the router's filesystem layout. The same applies to the /admin/files* endpoints and to the file_id resolution failures surfaced on /v1/chat/completions and /anthropic/v1/messages.

File Resolution in Chat Completions¶

The router automatically resolves file references in chat completion requests. When a message contains an image_file content block, the router:

1. Validates the file ID format
2. Loads the file content from storage
3. Converts the file to a base64 data URL
4. Replaces the image_file block with an image_url block

Supported File Types¶

File resolution in chat completions supports the following file types:

Note: PDF and plain text support is available for Anthropic backends (and PDF for OpenAI). The file transformers automatically convert document files to the appropriate format for each backend (OpenAI uses file blocks for PDF, Anthropic uses document blocks for both PDF and plain text). Non-image and non-document files will return a 400 Bad Request error with a helpful message indicating the supported file types.

Request with File Reference:

{
  "model": "gpt-4-vision-preview",
  "messages": [
    {
      "role": "user",
      "content": [
        {"type": "text", "text": "What's in this image?"},
        {"type": "image_file", "image_file": {"file_id": "file-abc123def456"}}
      ]
    }
  ]
}

Transformed Request (sent to backend):

{
  "model": "gpt-4-vision-preview",
  "messages": [
    {
      "role": "user",
      "content": [
        {"type": "text", "text": "What's in this image?"},
        {"type": "image_url", "image_url": {"url": "data:image/png;base64,..."}}
      ]
    }
  ]
}

File Resolution Errors:

Supported MIME Types:

• image/png - All backends
• image/jpeg - All backends
• image/gif - All backends
• image/webp - All backends
• application/pdf - OpenAI, Anthropic (max 32MB, 100 pages)
• text/plain - Anthropic (max 32MB)

Anthropic Native API¶

Continuum Router provides native Anthropic API endpoints that allow clients to use Anthropic's API format directly while still benefiting from the router's load balancing, failover, and multi-backend routing capabilities.

Messages API¶

Send messages using Anthropic's native API format.

POST /anthropic/v1/messages

Headers:

Request Body:

{
  "model": "claude-sonnet-4-20250514",
  "max_tokens": 1024,
  "messages": [
    {
      "role": "user",
      "content": "Hello, Claude!"
    }
  ],
  "stream": false
}

Request Parameters:

Response (non-streaming):

{
  "id": "msg_01XFDUDYJgAACzvnptvVoYEL",
  "type": "message",
  "role": "assistant",
  "content": [
    {
      "type": "text",
      "text": "Hello! How can I help you today?"
    }
  ],
  "model": "claude-sonnet-4-20250514",
  "stop_reason": "end_turn",
  "stop_sequence": null,
  "usage": {
    "input_tokens": 12,
    "output_tokens": 15,
    "cache_creation_input_tokens": 0,
    "cache_read_input_tokens": 0
  }
}

Backend Routing:

The router automatically transforms requests based on the target backend:

Transparent Responses-API routing¶

When the requested model is marked responses_only: true in model-metadata.yaml or the built-in OpenAI registry (e.g., gpt-5-pro, gpt-5.2-pro, gpt-5.4-pro, gpt-5.5-pro), the router transparently routes the Anthropic-formatted request to the upstream /v1/responses endpoint instead of /v1/chat/completions:

• The request is converted from Anthropic Messages format into the Responses API shape before dispatch.
• The upstream response is converted back into Anthropic Messages JSON (non-streaming) or the Anthropic SSE event sequence (streaming).
• Tool-call round-trips, web-search emulation, and Unix-socket transports all honor the flag.

The dispatch is transparent: clients keep targeting /anthropic/v1/messages and continue to receive Anthropic-shaped responses. Only OpenAI and Azure OpenAI backends serve these models; pairing a responses_only model with another backend type produces a 400 invalid_request_error (Anthropic-shaped on this surface) before any upstream call. See Responses-API-only Models for the full list, configuration syntax, and how to mark new models.

File references and resolution limits¶

Image and document blocks may point at a file uploaded through the Files API instead of carrying inline base64:

{"type": "image", "source": {"type": "file_id", "file_id": "file-abc123def456"}}

Every such reference is loaded and base64-encoded into the request before dispatch, including references nested inside a tool_result content array. Each reference gets its own copy of the encoded data, so the cost of a request grows with the number of references rather than with the number of distinct files. The following per-request limits apply:

A single referenced file is additionally capped at 10 MiB, unchanged from earlier releases.

The reference cap is intentionally higher than the 20-reference limit on /v1/chat/completions. The Messages API replays the whole conversation transcript on every turn, so a long multimodal session legitimately accumulates references that a single chat-completions call never would. Base64 expands the raw bytes by roughly 4/3, so the 32 MiB budget corresponds to an emitted ceiling of about 43 MiB.

Token Counting¶

Count the number of tokens in a message request payload.

POST /anthropic/v1/messages/count_tokens

Request Body:

{
  "model": "claude-sonnet-4-20250514",
  "messages": [
    {
      "role": "user",
      "content": "Hello, how are you?"
    }
  ],
  "system": "You are a helpful assistant."
}

Response:

{
  "input_tokens": 18
}

Tiered Token Counting¶

Token counting uses different strategies based on the backend type:

Note: For backends that don't support native tokenization, the router uses a character-based estimation of approximately 4 characters per token. This provides a reasonable approximation for planning purposes but may not match the exact token count used by the model.

Models List¶

List available models in Anthropic API format.

GET /anthropic/v1/models

Response:

{
  "data": [
    {
      "id": "claude-sonnet-4-20250514",
      "type": "model",
      "display_name": "Claude Sonnet 4",
      "created_at": "2025-05-14T00:00:00Z"
    },
    {
      "id": "claude-opus-4-20250514",
      "type": "model",
      "display_name": "Claude Opus 4",
      "created_at": "2025-05-14T00:00:00Z"
    }
  ],
  "has_more": false,
  "first_id": "claude-sonnet-4-20250514",
  "last_id": "claude-opus-4-20250514"
}