Skip to main content

Connect and Call Models

Developers call enabled models. Platform administrators configure sources, upstream credentials, and service status. This page separates those tasks. See the Quickstart for a first request.

List available models​

Before making a model request, use GET /v1/models to list available models. The OpenCSG community endpoint is https://ai.space.opencsg.com/v1/models.

Set your gateway credential in the CSGHUB_API_KEY environment variable, then run:

curl --request GET 'https://ai.space.opencsg.com/v1/models' \
--header "Authorization: Bearer ${CSGHUB_API_KEY}"

Select a model identifier from the returned list and use it in the model parameter of subsequent requests. For self-hosted deployments, replace the domain with your gateway address and keep the /v1/models path. Check the model service's instructions for supported interfaces and parameters.

Choose a service source​

SourceConnection methodInstructions
Public inferenceAn administrator creates it from a model detail page in asset management, then manages the running service under AI GatewayPublic inference management, Using public inference
Dedicated endpointA user creates an endpoint from a model page and follows its API examplesCreate an endpoint, Use an endpoint
Commercial APIAn administrator configures a model name, endpoint, and provider credentials under Commercial APICommercial API management

Available sources and management operations depend on edition and permissions. Create and start public inference from the model details, then manage the running service in the gateway’s public inference list.

Connect a commercial API​

  1. Open Admin Console → AI Gateway → Commercial API.
  2. Create a service and enter its public model identifier and model information.
  3. Add the upstream endpoint and provider credentials. Multiple upstreams must support the same target model capability.
  4. Set model capabilities, enabled status, and any required content checks.
  5. Save, check availability, and make a request using the service's API address and model name.

Configure routing when using multiple upstreams. Applications use platform-issued gateway keys; administrators manage provider credentials on the upstream connection.

Request interfaces​

The following interfaces are available according to deployment, upstream, and model support. Replace proxy path placeholders with registered resource identifiers.

CapabilityEndpointNotes
Model list/v1/modelsUse GET to list available models
Text generation/v1/chat/completionsStreaming and non-streaming
Responses/v1/responsesSupports the OpenAI Responses API protocol
Embeddings/v1/embeddingsText vectorization
Rerank/v1/rerankText reranking extension; not a standard OpenAI endpoint
Anthropic messages/v1/messagesAnthropic protocol proxy; follow the service's authentication and request instructions
Image generation/v1/images/generationsSupported image-generation tasks
Speech to text/v1/audio/transcriptionsAudio transcription
Video generation/v1/videosSupported video-generation tasks
MCP proxy/v1/mcp/*MCP service forwarding
Agent proxy/v1/agent/:type/*Agent service proxy
Sandbox proxy/v1/sandboxes/:name/*Access to a deployed sandbox service

SDKs and model differences​

Use the OpenAI SDK with the OpenAI-compatible text interface by setting base_url and api_key, as shown in the Quickstart. Dedicated endpoints also provide Python, JavaScript, and cURL examples.

  • Use the model name and address shown by the service. Do not confuse upstream and gateway addresses.
  • Streaming, tools, structured output, and multimodal parameters require support from both the model and the interface.
  • Models can differ in parameters, context length, and output capabilities even when accessed through the same client.
  • Model asset versions and running service versions are separate concerns. Revalidate the application after changing upstreams.

Identity and Access · Routing and Reliability · MCP and Agent Access