Which Upstream AI Services Does Sub2API Support? Complete Provider Guide

Sub2API functions as a unified API gateway for nine upstream AI services—OpenAI GPT, Anthropic Claude, Google Gemini, Grok, Antigravity, Kimi, Zhipu, DeepSeek, and Composite multi-provider orchestration—each implemented via dedicated Go handlers that translate internal requests into provider-specific HTTP contracts.

Sub2API normalizes access to diverse large language model (LLM) providers through a single entry point. The Wei-Shaw/sub2api repository defines supported upstream AI services in its frontend type system and implements routing logic through specialized gateway handlers in the backend.

Complete List of Upstream AI Service Providers

The supported platforms are enumerated in the TypeScript type definitions and mapped to individual handlers. Each identifier corresponds to a specific upstream AI service with distinct API capabilities.

OpenAI GPT

The openai platform identifier routes to backend/handler/openai_gateway_handler.go, which implements OpenAI-compatible endpoints including /v1/chat/completions, /v1/completions, and /v1/images/generations. This handler manages standard GPT model interactions and image generation tasks.

Anthropic Claude

Identified by anthropic, this service is handled in backend/handler/gateway_handler.go (Messages implementation). It specifically targets the Claude Messages endpoint at /v1/messages, translating Sub2API's internal format into Anthropic's structured message protocol.

Google Gemini

The gemini platform uses backend/handler/gemini_gateway_handler.go to interface with Google's Gemini API. It supports chat and generation endpoints under the /v1beta/models/* path, handling content generation requests with Google's distinct payload structure.

Grok (xAI)

Registered as grok, this provider is managed by backend/handler/grok_gateway_handler.go. Unlike text-only providers, Grok's implementation routes image and video media prompt requests to /v1/images/ and /v1/videos/ endpoints, supporting multimodal inputs.

Kimi, Zhipu, and DeepSeek

Sub2API includes dedicated handlers for regional and specialized model providers:

• Kimi: backend/handler/kimi_gateway_handler.go supports the Kimi LLM API
• Zhipu: backend/handler/zhipu_gateway_handler.go connects to Zhipu AI services
• DeepSeek: backend/handler/deepseek_gateway_handler.go handles DeepSeek model families

Each maintains the kimi, zhipu, and deepseek platform identifiers respectively.

Antigravity

The antigravity platform routes to backend/handler/antigravity_gateway_handler.go, which implements a custom endpoint for specialized or partner models that do not conform to standard OpenAI or Anthropic schemas.

Composite Multi-Provider Mode

The composite platform identifier activates backend/handler/composite_gateway_handler.go, enabling orchestration across multiple upstream providers in a single request chain. This handler sequences calls to different services—such as using OpenAI for summarization followed by Gemini for poetic rewriting—within one unified workflow.

Platform Enumeration in Source Code

The authoritative list of upstream AI services resides in the frontend type definitions at frontend/src/types/index.ts. The GroupPlatform type serves as the single source of truth for valid platform values throughout the application:

// frontend/src/types/index.ts
export type GroupPlatform =
  'anthropic' | 'openai' | 'gemini' | 'antigravity' |
  'grok' | 'kimi' | 'zhipu' | 'deepseek' | 'composite';

This type-safe enumeration ensures that backend handlers and frontend routing logic remain synchronized regarding supported upstream providers.

Gateway Handler Architecture

Request routing to upstream AI services follows a consistent pattern across the codebase. According to backend/internal/server/routes/prompt_audit_route_coverage_test.go, incoming requests are dispatched to provider-specific handlers based on the platform identifier. Each handler in the backend/handler/ directory implements a translation layer that converts Sub2API's normalized internal request format into the exact HTTP contract required by the target upstream service.

The architecture maintains separation of concerns: routing logic resides in the server routes configuration, while protocol translation logic is encapsulated within individual *_gateway_handler.go files. This design allows Sub2API to support divergent API schemas—from OpenAI's chat completions to Gemini's content generation—behind a unified facade.

API Integration Examples

Sub2API exposes all upstream services through a consistent API interface. The following examples demonstrate how to invoke each supported provider using standard HTTP requests, assuming the Sub2API server is accessible at https://api.example.com.

OpenAI-Compatible Chat Completion

curl https://api.example.com/v1/chat/completions \
     -H "Authorization: Bearer <SUB2API_TOKEN>" \
     -H "Content-Type: application/json" \
     -d '{"model":"gpt-4","messages":[{"role":"user","content":"Explain quantum mechanics"}]}'

Anthropic Claude Messages

curl https://api.example.com/v1/messages \
     -H "Authorization: Bearer <SUB2API_TOKEN>" \
     -H "Content-Type: application/json" \
     -d '{"model":"claude-2","messages":[{"role":"user","content":"Explain quantum mechanics"}]}'

Google Gemini Content Generation

curl https://api.example.com/v1beta/models/gemini-pro:generateContent \
     -H "Authorization: Bearer <SUB2API_TOKEN>" \
     -H "Content-Type: application/json" \
     -d '{"contents":[{"role":"user","parts":[{"text":"Write a haiku about AI"}]}]}'

Grok Image Generation

curl https://api.example.com/v1/images/generations \
     -H "Authorization: Bearer <SUB2API_TOKEN>" \
     -H "Content-Type: application/json" \
     -d '{"prompt":"A futuristic cityscape","n":1,"size":"1024x1024"}'

Kimi, Zhipu, and DeepSeek Text Completion

Kimi:

curl https://api.example.com/v1/completions \
     -H "Authorization: Bearer <SUB2API_TOKEN>" \
     -H "Content-Type: application/json" \
     -d '{"model":"kimi-1.5","prompt":"Translate to French:"}'

Zhipu:

curl https://api.example.com/v1/chat/completions \
     -H "Authorization: Bearer <SUB2API_TOKEN>" \
     -H "Content-Type: application/json" \
     -d '{"model":"zhipu-chat","messages":[{"role":"user","content":"What is the capital of Italy?"}]}'

DeepSeek:

curl https://api.example.com/v1/completions \
     -H "Authorization: Bearer <SUB2API_TOKEN>" \
     -H "Content-Type: application/json" \
     -d '{"model":"deepseek-coder","prompt":"Write a Python function to sort a list"}'

Composite Multi-Provider Orchestration

curl https://api.example.com/v1/composite \
     -H "Authorization: Bearer <SUB2API_TOKEN>" \
     -H "Content-Type: application/json" \
     -d '{"steps":[
            {"provider":"openai","model":"gpt-4","prompt":"Summarize the following: ..."},
            {"provider":"gemini","model":"gemini-pro","prompt":"Rewrite the summary in poetic form"}
          ]}'

Summary

• Sub2API supports nine upstream AI service providers: OpenAI, Anthropic Claude, Google Gemini, Grok, Antigravity, Kimi, Zhipu, DeepSeek, and Composite mode.
• Valid platform identifiers are type-enforced through the GroupPlatform union type in frontend/src/types/index.ts.
• Each provider is implemented via a dedicated gateway handler in backend/handler/ that manages protocol translation.
• The Composite handler enables chaining multiple upstream AI services within a single request workflow.
• Routing configuration is centralized in backend/internal/server/routes/prompt_audit_route_coverage_test.go.

Frequently Asked Questions

How does Sub2API route requests to upstream AI services?

Sub2API examines the platform identifier in the request and dispatches to the corresponding handler file—such as backend/handler/openai_gateway_handler.go for OpenAI requests—through the routing table defined in backend/internal/server/routes/prompt_audit_route_coverage_test.go. Each handler translates the normalized internal request into the provider's native API format.

What file defines the supported upstream AI service platforms?

The authoritative enumeration of supported upstream AI services resides in frontend/src/types/index.ts as the GroupPlatform TypeScript union type. This definition includes all nine supported platforms: openai, anthropic, gemini, antigravity, grok, kimi, zhipu, deepseek, and composite.

Can Sub2API combine multiple upstream providers in a single request?

Yes, through the Composite platform mode implemented in backend/handler/composite_gateway_handler.go. This handler orchestrates sequential calls to multiple upstream AI services—specified via the steps array—allowing you to chain outputs from one provider (like OpenAI GPT) into inputs for another (like Google Gemini) within a single API call.

Where are the provider-specific API translations implemented?

Each upstream AI service has its own translation layer in the backend/handler/ directory. For example, OpenAI compatibility is handled in openai_gateway_handler.go, Claude integration in gateway_handler.go, and Gemini support in gemini_gateway_handler.go. These files contain the logic for converting Sub2API's internal request schema into the specific HTTP contracts required by each upstream provider.

{
  "mcpServers": {
    "instagit": {
      "command": "npx",
      "args": ["-y", "instagit@latest"]
    }
  }
}