Skip to main content
Surplus Intelligence
Marketplace
MarketplaceModels and providers

Models & Providers

Surplus Intelligence has two related but different counts:

  • Catalog models: GET /v1/models returns every model currently known to the SI registry. The endpoint is the source of truth for the count - it moves as models are onboarded, so this page deliberately does not print a number.
  • Active marketplace models: the Market Prices page and GET /api/markets show models with active seller offers. Current live snapshot: the subset with live seller offers.

Current catalog breakdown from a recent live /v1/models snapshot:

  • text and vision-capable chat/completion models
  • image-generation models
  • text-to-speech and speech-to-text models
  • embedding models
  • video-generation models backed by the async Venice video adapter
  • music/audio-generation models backed by the async Venice audio adapter

The live /v1/prices endpoint tracks pricing across many provider pricing sources, and the seller allowlist covers 26+ provider hosts (plus every regional Bedrock host). Both move as providers are onboarded - GET /v1/providers and GET /v1/prices are the source of truth. Active production offers are currently concentrated on Venice and Bankr LLM Gateway; other allowed providers are supported by the routing/normalization layer but may not have active seller liquidity at all times.

Use these endpoints for current counts instead of copying numbers from docs:

bash
GET $SURPLUS_BASE_URL/models
GET https://api.surplusintelligence.ai/api/markets
GET $SURPLUS_BASE_URL/prices

Supported Provider Domains

Sellers may list OpenAI-compatible endpoints from the provider allowlist. Native non-OpenAI providers are only supported where the router has an adapter/translator.

Catalog is not liquidity
In the catalog - GET /v1/modelsevery known model
Has a live offer - routable right nowthe subset that matters
Known, but no seller today404 no_sellers_for_model
Every model Surplus knows about appears in /v1/models. Only the subset with a live seller offer can actually be routed - and that subset moves minute to minute.

Model Name Resolution

Request models using any of these formats - the marketplace normalizes automatically:

Canonical (recommended)Example · claude-opus-4.6
OpenRouter formatExample · anthropic/claude-opus-4.6
Venice internalExample · claude-opus-4-6
Common aliasesExample · gemini-3-flash → gemini-3-flash-preview

Live Model Catalog

bash
GET /v1/models

Returns all catalog models with pricing, context lengths, capabilities, and provider mappings in an OpenRouter-compatible format. For tool-calling compatibility, check each model's supported_parameters; tools must be present for tool calls to be forwarded.

For image, video, document, and audio input, check architecture.input_modalities and supported_features together, since the two disagree on some rows: see Media Inputs. For reasoning, see Reasoning Controls. The live provider allowlist with each provider's trusted flag is available at GET /v1/providers; what that flag does and does not establish is covered in Provider & Model Verification.

Cross-Provider Translation

The marketplace accepts buyer requests in OpenAI format. OpenAI-compatible sellers receive OpenAI-format requests after model-name and tool-format normalization. Native provider APIs require translation.

Native Anthropic Translation

When a request routes to an Anthropic-format seller (api.anthropic.com), the following translations are applied:

Request (OpenAI → Anthropic):

  • role: "system" / role: "developer" → Anthropic system parameter
  • User messages with image_url → Anthropic image content blocks (base64 + URL)
  • tools array → Anthropic tool format (name, description, input_schema)
  • tool_choice → Anthropic tool choice (auto, tool)
  • Assistant messages with tool_calls → Anthropic tool_use content blocks
  • role: "tool" messages → Anthropic tool_result content blocks
  • max_tokens / max_completion_tokens → Anthropic max_tokens
  • stop → stop_sequences

Response (Anthropic → OpenAI):

  • tool_use content blocks → OpenAI tool_calls array
  • end_turn → finish_reason: "stop"
  • tool_use stop reason → finish_reason: "tool_calls"
  • input_tokens / output_tokens → prompt_tokens / completion_tokens

Streaming (Anthropic SSE → OpenAI SSE):

  • content_block_delta with text → choices[0].delta.content
  • content_block_start with tool_use → choices[0].delta.tool_calls[i] with function name and id
  • input_json_delta → choices[0].delta.tool_calls[i].function.arguments chunks
  • message_delta with usage → final usage chunk

This translation layer is implemented and covered by tests, including multi-turn function-tool transcripts. It is not the primary active production path today because current Claude seller liquidity is mainly through OpenAI-compatible providers. Anthropic-specific beta features and non-function computer-use tools are not guaranteed.

Media Models

Media models (images, TTS, STT, embeddings, video, music/audio) use provider-specific endpoints rather than /chat/completions. The marketplace maps standard model names to provider-specific IDs via the media model registry.

Images are synchronous. Video and music/audio are asynchronous jobs: submit to /v1/video/generations or /v1/music/generations, then poll the job URL until terminal. Seller onboarding never runs a paid generation to check health: a video offer on a known async-video host is probed against a free authenticated account endpoint (Venice GET /api_keys/rate_limits, Uncensored GET /billing/balance), and every other media offer falls back to a GET /models liveness check. Quote endpoints are not used for this, because they answer 200 to a bogus key and so cannot detect a dead credential. See Provider & Model Verification.

Sellers listing Venice as a provider will see media models (Whisper, TTS, Flux, Runway/Seedance/PixVerse video, ACE-Step/ElevenLabs/MiniMax/Stable Audio, etc.) in the model discovery flow alongside text models.

Previous← How it worksNextRouting controls →