Custom Providers

AI Supreme Council supports any LLM API that implements the OpenAI chat completions format. This lets you connect to self-hosted models, corporate LLM gateways, alternative providers, and local inference servers.

What Are Custom Providers

Custom providers are user-defined LLM endpoints that use the OpenAI-compatible API format (/v1/chat/completions with SSE streaming). Most modern inference servers and LLM gateways implement this format, making it the de facto standard for LLM APIs.

Use Cases

Self-hosted models -- Connect to vLLM, Text Generation Inference, or LocalAI running on your own hardware
Corporate LLM gateways -- Route through your company's API proxy with authentication and logging
Local proxies -- Use LiteLLM or similar tools to unify multiple providers behind a single endpoint
Alternative providers -- Connect to any provider not yet built into the app
Fine-tuned models -- Access your custom fine-tuned models on any compatible hosting platform
Air-gapped deployments -- Use models running on a local network without internet access

Adding a Custom Provider via Settings

Open Settings (click the gear icon or press Ctrl+Shift+S)
Go to the API Keys section
Scroll to Custom Providers
Fill in the fields:

Field	Required	Description
Provider ID	Yes	A short identifier (e.g., `my-llm`). Must be unique, lowercase, no spaces
Display Name	Yes	Human-readable name shown in the provider dropdown
Endpoint URL	Yes	Full URL to the chat completions endpoint (e.g., `https://my-api.example.com/v1/chat/completions`)
API Key	No	Bearer token for authentication (leave empty if none required)
Models	Yes	Comma-separated list of model IDs available at this endpoint

Click Save
The provider appears in the provider dropdown when creating or configuring a bot

Programmatic Registration

You can register custom providers from the browser console or from a script:

AIS.Providers.registerCustom('my-provider', {
  name: 'My Provider',
  endpoint: 'https://my-api.example.com/v1/chat/completions',
  models: [
    { id: 'my-model-7b', name: 'My Model 7B' },
    { id: 'my-model-70b', name: 'My Model 70B' }
  ],
  apiStyle: 'openai'
});

Registration Options

Option	Type	Default	Description
`name`	string	Provider ID	Display name
`endpoint`	string	Required	Full URL to chat completions endpoint
`models`	array	`[{id: 'default', name: id}]`	Available models
`apiStyle`	string	`'openai'`	API format (currently only `'openai'` is supported)
`extraHeaders`	object	`{}`	Additional HTTP headers to include in every request
`pricing`	object	`null`	Pricing info (for cost tracking)
`maxInput`	number	`0`	Max input context length (for display only)

Extra Headers

If your endpoint requires custom headers (e.g., for authentication schemes other than Bearer tokens):

AIS.Providers.registerCustom('corp-gateway', {
  name: 'Corporate Gateway',
  endpoint: 'https://llm.corp.internal/v1/chat/completions',
  models: [{ id: 'gpt-4o', name: 'GPT-4o (via gateway)' }],
  extraHeaders: {
    'X-Corp-Token': 'your-internal-token',
    'X-Department': 'engineering'
  }
});

Persistence

Custom providers are automatically saved to localStorage under the key ais-custom-providers. They are restored on every page load, so you only need to register them once.

Managing Custom Providers

List registered custom providers

const customIds = AIS.Providers.listCustom();
// ['my-provider', 'corp-gateway']

Remove a custom provider

AIS.Providers.removeCustom('my-provider');

This removes it from both the runtime registry and localStorage.

List all providers (built-in + custom)

const all = AIS.Providers.list();
// [{ name: 'anthropic', models: [...] }, { name: 'my-provider', models: [...] }, ...]

How It Works Internally

Custom providers use the same openaiCompatible() SSE streaming factory that powers the built-in OpenAI, xAI, OpenRouter, DeepSeek, Groq, and other providers. This factory:

Builds a standard OpenAI-format request body (model, messages, temperature, max_tokens, stream, etc.)
Sends a POST request with Authorization: Bearer {apiKey} header
Parses the SSE stream (data: {...} lines) for content deltas
Handles both streaming (delta) and non-streaming (message) response formats
Extracts token usage from the usage field if present

All config fields work with custom providers: temperature, top_p, frequency_penalty, presence_penalty, stop sequences, response format, and reasoning effort.

Compatible Services

The following services implement the OpenAI-compatible API format and work as custom providers:

Service	Endpoint	Notes
LiteLLM	`http://localhost:4000/v1/chat/completions`	Proxy that unifies 100+ providers
LocalAI	`http://localhost:8080/v1/chat/completions`	Run open-source models locally
vLLM	`http://localhost:8000/v1/chat/completions`	High-performance inference server
Text Generation Inference	`http://localhost:8080/v1/chat/completions`	Hugging Face inference server
Ollama	`http://localhost:11434/v1/chat/completions`	Already built-in, but can be added as custom too
llama.cpp (server mode)	`http://localhost:8080/v1/chat/completions`	Lightweight C++ inference
Jan	`http://localhost:1337/v1/chat/completions`	Desktop app with local models
LM Studio	`http://localhost:1234/v1/chat/completions`	Desktop app with model management
Cloudflare Workers AI	`https://api.cloudflare.com/client/v4/accounts/{id}/ai/v1/chat/completions`	Built-in, but can customize
Azure OpenAI	`https://{resource}.openai.azure.com/openai/deployments/{deployment}/chat/completions?api-version=2024-02-01`	Requires `api-key` header

Troubleshooting

CORS Errors

CORS (Cross-Origin Resource Sharing)

When the browser calls an API endpoint directly, the server must include CORS headers in its response. Without them, the browser blocks the request for security reasons.

If you see a CORS error in the console, your custom endpoint needs to return these headers:

Access-Control-Allow-Origin: *
Access-Control-Allow-Headers: Content-Type, Authorization
Access-Control-Allow-Methods: POST, OPTIONS

For local services:

Ollama: Set OLLAMA_ORIGINS=* environment variable before starting
vLLM: Add --allowed-origins '*' flag
LiteLLM: Add --cors flag or set LITELLM_ALLOW_ORIGINS=*
LocalAI: CORS is enabled by default

For remote services behind a reverse proxy (Nginx):

location /v1/ {
    add_header 'Access-Control-Allow-Origin' '*' always;
    add_header 'Access-Control-Allow-Headers' 'Content-Type, Authorization' always;
    add_header 'Access-Control-Allow-Methods' 'POST, OPTIONS' always;

    if ($request_method = 'OPTIONS') {
        return 204;
    }

    proxy_pass http://localhost:8000;
}

Connection Refused

Verify the endpoint URL is correct and the service is running
For local services, ensure the server is listening on the expected port
For localhost services, try 127.0.0.1 instead (or vice versa)
Check that no firewall is blocking the port

Authentication Errors

Verify your API key is correct
Some services use different auth headers -- use extraHeaders if the service does not use standard Authorization: Bearer format
Azure OpenAI uses api-key header instead of Authorization

Empty or Garbled Responses

Confirm the endpoint returns OpenAI-compatible SSE format (data: {"choices":[{"delta":{"content":"..."}}]})
Some services require stream: true in the request body (the app sends this by default)
Check the model ID matches what the service expects
Open the browser's Network tab in DevTools to inspect the raw request and response

What Are Custom Providers​

Use Cases​

Adding a Custom Provider via Settings​

Programmatic Registration​

Registration Options​

Extra Headers​

Persistence​

Managing Custom Providers​

List registered custom providers​

Remove a custom provider​

List all providers (built-in + custom)​

How It Works Internally​

Compatible Services​

Troubleshooting​

CORS Errors​

Connection Refused​

Authentication Errors​

Empty or Garbled Responses​