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
| Source | Connection method | Instructions |
|---|---|---|
| Public inference | An administrator creates it from a model detail page in asset management, then manages the running service under AI Gateway | Public inference management, Using public inference |
| Dedicated endpoint | A user creates an endpoint from a model page and follows its API examples | Create an endpoint, Use an endpoint |
| Commercial API | An administrator configures a model name, endpoint, and provider credentials under Commercial API | Commercial 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
- Open Admin Console → AI Gateway → Commercial API.
- Create a service and enter its public model identifier and model information.
- Add the upstream endpoint and provider credentials. Multiple upstreams must support the same target model capability.
- Set model capabilities, enabled status, and any required content checks.
- 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.
The gateway supports different upstream authentication requirements, including authentication header names and credential prefixes. Applications continue to use gateway API keys without maintaining separate authentication logic for each upstream provider.
Request interfaces
The following interfaces are available according to deployment, upstream, and model support. Replace proxy path placeholders with registered resource identifiers.
| Capability | Endpoint | Notes |
|---|---|---|
| Model list | /v1/models | Use GET to list available models |
| Text generation | /v1/chat/completions | Streaming and non-streaming |
| Responses | /v1/responses | Supports the OpenAI Responses API protocol |
| Embeddings | /v1/embeddings | Text vectorization |
| Rerank | /v1/rerank | Text reranking extension; not a standard OpenAI endpoint |
| Anthropic messages | /v1/messages | Anthropic protocol proxy; follow the service's authentication and request instructions |
| Image generation | /v1/images/generations | Supported image-generation tasks |
| Speech to text | /v1/audio/transcriptions | Audio transcription |
| Video generation | /v1/videos | Supported 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 |
Responses API and Chat Adapter
For upstreams serving the Responses API through Chat Adapter mode, the gateway can convert Responses requests into upstream Chat requests. This lets applications use compatible Chat model services through a Responses interface.
The adapter supports enabling or disabling reasoning, mapping reasoning effort, and applying model-specific extension parameters. Support depends on the adapter configuration and upstream model capabilities; it does not imply that every upstream natively supports all Responses API features.
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.
Related guides
Identity and Access · Routing and Reliability · MCP and Agent Access