Every model provider through one API, with your own keys if you prefer

A request names a model, either with a provider prefix such as provider:model or by a well-known model name that the registry recognizes. Connect resolves the provider, picks the credential, calls the provider in its native protocol and returns the answer in the OpenAI-compatible format. Chat completions, streaming, embeddings, image generation, speech, transcription and moderation go through the same gateway.

Because the interface does not change, switching a model, or a provider, is a parameter change in the request, not a code migration. That is the practical value of a gateway: your product code depends on one contract while the provider market keeps moving.

A provider appearing in the registry means Connect can route to it. Which providers a given workspace uses depends on the keys connected and the policy applied. The providers Swfte itself relies on are listed on the sub-processors page.

The self-hosted catalogue spans far more than chat. It covers text generation, embeddings, reranking, speech-to-text, text-to-speech, OCR, image and video generation, safety classifiers and several specialist categories. Examples in the registry include Whisper Large V3 for transcription, BGE-M3 for multilingual embeddings, Qwen3-Reranker for reranking, PaddleOCR-VL for document OCR and Granite Guardian as a safety model. Hosting them on GPUs you control, through the deploy models catalogue, puts them behind the same API as the commercial providers.

This is how sovereignty and convenience coexist. Sensitive workloads route to a model running in your own environment; low-risk workloads route to the best commercial option; both use one client, one set of keys for your applications and one audit trail. See self-deployment for running the gateway next to those models.

1. Your key first. If your workspace has connected its own key for a provider, Connect uses it.
2. Platform access second. If not, Connect uses Swfte's pooled provider access, where it is offered.
3. Custom endpoints. A connected key can carry its own base URL, which is how you point a provider slot at a private or self-hosted endpoint.

Your keys are stored encrypted in a secrets manager, decrypted only at call time and cached briefly. They are never sent to the client. Using your own keys means you keep your commercial terms, quotas and data agreements with each provider, and the provider bills you directly. The security page covers credential handling in more detail.

• Fallback chains. When a primary model's provider is unavailable, rate-limited or out of funds, Connect walks an ordered chain of alternatives. Defaults are organized by pricing tier and cross providers, so one provider outage does not take a tier down.
• Your own chains. A workspace routing rule must define its own fallback chain, with priority and time-of-day conditions, so you decide the order and the models.
• Routing strategies. Strategies include cost-optimized, weighted, round-robin, least-used, priority and scoring-based selection, applied by name to a rule.
• Consensus. For high-stakes calls, a request can fan out to several providers and a decision step selects the best answer.
• Budget-aware downgrade. When a usage cap is reached, Connect can switch to a cheaper model rather than stop.

Fallbacks are a governance tool as well as a reliability tool. A chain restricted to approved models is how you make sure an outage never sends a request to a provider your policy has not cleared. That is the basis of EU-first routing.

Connect is designed to let you route by where processing happens. In practice that means restricting a workspace to providers whose processing location you have confirmed, preferring European providers and European-hosted open-weight capacity, and running self-hosted models for the most sensitive traffic. Customer data in the managed service is stored in AWS eu-west-1 (Ireland) today. The details, and the limits of what is enforced versus designed for, are on the EU routing page.

Model availability, pricing and provider terms change. Check a provider's current terms before sending regulated data to it. Swfte provides the technical controls, governance mechanisms and evidence required to deploy AI within an organization's applicable regulatory, security and policy requirements. The exact posture depends on the customer's use case, jurisdiction, deployment and configuration.

• Self-deploy Connect

  Run the gateway beside your own models.

• EU-first routing

  Restrict routing to approved providers and regions.

• Connect security

  Credential handling, policy and audit.

• Open-source model leaderboard

  Compare models before you route to them.

• AI gateways compared

  Gateway options compared on vendor-documented features.

• MCP vs API

  Two layers, not rivals.

• MCP servers

  Where to find them and how to vet one.

• What is MCP?

  The Model Context Protocol explained.

• Models and routing layer

  Connect as the model gateway and routing layer of the platform.

• Sovereign infrastructure

  Where AI runs, from managed to dedicated.

• Dedicated cloud

  Private capacity operated for you.

• GPU and inference

  GPU capacity for the models Connect routes to.

• Deploy open-source models

  The catalogue of open-weight models you can host.

• LLM API guides

  Provider and model reference pages.

• Trust centre

  What Swfte can show today.

• Sub-processors

  Providers and services Swfte itself relies on.