Large Language Model Providers  
 

One of the first decisions you will need to make when using the SocketTools Large Language Model API is choosing which service provider to use. The library is designed to support a variety of providers and models, and the provider type is specified using one of following provider constants. The current version supports the following providers:

Constant Value Default Model Description
LLM_PROVIDER_LOCAL 1 None Locally hosted models using servers like LM Studio or Ollama. This is ideal for development, testing, offline use, or avoiding usage costs. A wide range of open-source models are available; for best results, start with smaller instruction-tuned models such as qwen2.5-7b-instruct, llama-3.2-3b-instruct, or mistral-7b-instruct.
LLM_PROVIDER_OPENAI 2 gpt-5.4-nano OpenAI's public API (ChatGPT) is a recommended starting point for most developers due to ease of use, strong general performance, and comprehensive documentation. For initial development and testing, lightweight models such as the GPT-5 mini series provide fast response times and lower usage costs.
LLM_PROVIDER_ANTHROPIC 3 claude-haiku-4-5 Anthropic's Claude models are well suited for structured reasoning, conversational clarity, and safety-focused applications. For initial use, the Haiku models offer lower cost and faster response times while maintaining strong performance.
LLM_PROVIDER_GOOGLE 4 gemini-2.5-flash Google's Gemini models are a good choice for multimodal applications and integration with the Google AI ecosystem. The Flash models are recommended for getting started due to their lower latency and reduced token costs.
LLM_PROVIDER_MICROSOFT 5 None Microsoft Foundry OpenAI-compatible models are typically used in enterprise environments requiring Azure integration and regional deployment control. This option requires provisioning a model deployment within Foundry and specifying the deployment name and API version when connecting.
LLM_PROVIDER_MISTRAL 6 mistral-small-3.2 Mistral AI models provide efficient and cost-effective options for general-purpose and reasoning tasks. Smaller models are recommended when getting started due to their performance and lower cost.

Choosing a Model

Although SocketTools provides a default model for most providers, the model names and availability will change over time. The providers which do not have a default model assigned to them will always require a specific model name when establishing the connection. Some providers, notably Microsoft Foundry and locally hosted services, will explicitly require you to provide a model name to establish a connection.

It is important to note that the library is not limited only to those default models listed above. Developers are encouraged to enumerate available models and explicitly select a model that meets their requirements. The library provides functions designed to return information about all of the compatible models supported by a provider. For more information refer to the LlmEnumModels function.

Most language model providers offer multiple models with different capabilities, performance characteristics, and pricing. Rather than selecting a specific model name immediately, it is often more useful to choose a general category of model based on your application's needs.

Common model categories include:

  • Lightweight. Optimized for speed and low cost. These are ideal for simple tasks such as formatting, summarization, classification, or user interface interactions where responsiveness is important. These are the default models assigned to supported providers. In most cases, we recommend you start with a lightweight model until you determine your application could benefit from a more capable model type.
  • Balanced. General purpose models that provide good performance across a wide range of tasks. These are typically the best default choice for most applications which need to balance between performance and capability. Examples are gpt-5-mini, claude-sonnet-4-6, gemini-3.1 and mistral-medium models.
  • Reasoning. Designed for more complex tasks such as multi-step problem solving, analysis, and code generation. These models may produce more detailed responses but typically use more tokens and have higher latency and increased costs. Examples are gpt-5, claude-opus-4-7, gemini-3.1-pro and mistral-large models.
  • Multimodal. Support input or output beyond plain text, such as images, audio, or structured data. These are useful when working with media content or advanced integrations.

In most cases, developers should begin with a lightweight or balanced model and only move to more advanced models when additional capability is required. The exact model names and capabilities will vary between providers, but these categories provide a useful framework for selecting an appropriate model. Applications should also avoid relying on strict token limits or attempting to precisely manage context usage. Providers ultimately determine request limits, and applications should be prepared to handle responses that are truncated or rejected when limits are exceeded.

API Keys and Authentication

Most language model providers require an API key (or authentication token) to access their services. An API key is a unique identifier associated with your account that is included with each request to authenticate the client and track usage.

When using the library, the API key is typically provided when establishing a session using the LlmConnect or LlmConnectEx function. The library will include this key in requests to the selected provider using the appropriate authentication mechanism.

Because API keys grant access to external services and may incur usage charges, they should be handled carefully and not exposed unnecessarily. The library supports several functions for providing API keys, allowing applications to balance convenience and security.

Providing an API Key

The library supports the following functions for supplying an API key:

  • Literal string
    The API key can be provided directly as a string when creating a session. This is the simplest approach and is often used for testing or development, but it is not recommended for production applications because the key may be exposed in application binaries or source code.
  • Environment variable
    The API key can be stored in an environment variable and retrieved at runtime. This approach avoids embedding the key directly in the application and is commonly used in development environments, scripts, or deployment pipelines.
  • Windows Credential Manager
    The API key can be stored securely using the Windows Credential Manager and retrieved by the application at runtime. This is the recommended approach for Windows applications because it provides secure storage and helps prevent accidental exposure of sensitive credentials.

Best Practices

  • Do not embed API keys directly in source code for production applications.
  • Use secure storage mechanisms, such as the Windows Credential Manager, whenever possible.
  • Limit access to API keys and avoid sharing them between applications or users.
  • Review provider usage policies and configure usage limits or alerts where available.

Each provider has its own process for creating and managing API keys. Refer to the provider documentation for details on generating keys, rotating credentials, and managing access.

Application Design

When designing an application that uses a language model provider, developers generally have two approaches for managing API keys:

  • Application-managed API key
    The developer provides an API key that is used by the application for all requests. This approach is simple to implement and provides a consistent user experience, but the developer is responsible for all usage and any associated costs.
  • User-provided API key (Bring Your Own Key)
    The application allows the end user to supply their own API key, typically through a configuration dialog or settings interface. In this case, the user is responsible for usage and costs, and the application acts as a client using the user's credentials.

Each approach has trade-offs. Using an application-managed key simplifies the user experience but may require safeguards such as rate limiting or usage monitoring. Allowing users to provide their own key can reduce operational costs and provide greater flexibility, but requires additional user interface considerations and clear instructions for obtaining and configuring API access.

Applications intended for a broad audience often prefer a built-in API key for ease of use, while developer-focused tools frequently support user-provided keys for flexibility.

Provider Overview

The following sections provide more detailed information about the supported providers. One of the advantages of the library is that applications are not limited to a single language model service. Different providers may offer advantages related to pricing, performance, regional availability, deployment flexibility, or model capabilities.

Supporting multiple providers can also provide greater flexibility for end users. Some users or organizations may already have existing accounts, billing arrangements, or infrastructure associated with a specific provider such as OpenAI, Google, Microsoft Foundry, or a locally hosted inference service. Applications can allow users to select the provider and model which best meets their requirements without requiring significant changes to application logic.

LLM_PROVIDER_LOCAL

This provider type is used for locally hosted language model inference. This is particularly useful for development, testing, and experimentation without relying on a cloud-based provider. Local hosting allows developers to evaluate model behavior, test integrations, and work offline or within a private environment. This requires you to install and configure an application on your local system or network which will provide the inference service. For the Windows platform, we recommend one of the following applications, which are free to install and use:

LM Studio

LM Studio provides a full-featured desktop environment for running and testing language models locally. It includes model management, a built-in server, and support for OpenAI-compatible APIs, making it a strong choice for development and evaluation.

Ollama

Ollama is a lightweight local model runtime that makes it easy to download and run models on a local system. It provides a simple API interface and is well suited for basic testing and self-hosted deployments.

LLM_PROVIDER_OPENAI

The OpenAI provider connects to OpenAI's public API and is generally the recommended starting point for most developers. It offers a wide range of well-documented models, consistent API behavior, and strong general-purpose performance. Developers who are new to using large language models or want a reliable default should typically begin here.

To get started, developers create an API key, select a model name, and connect to the default OpenAI endpoint. The API is widely supported and serves as the baseline for compatibility with many other providers.

LLM_PROVIDER_ANTHROPIC

The Anthropic provider connects to Anthropic's Claude API, which focuses on conversational models designed for safety and structured reasoning. Developers must create an API key and select a supported Claude model. The API is similar in concept to OpenAI but uses its own endpoints and request formats.

LLM_PROVIDER_GOOGLE

The Google provider connects to Google's Gemini API, which provides access to multimodal models and integrates with the broader Google AI ecosystem. Developers typically obtain an API key through Google AI Studio and use it to authenticate requests to the Gemini service.

LLM_PROVIDER_MICROSOFT

The Microsoft provider connects to a Microsoft Foundary OpenAI-compatible deployment. This option is often used in enterprise environments where Azure integration, regional deployment, or Microsoft-managed infrastructure is required. Unlike the public OpenAI API, Microsoft requires a resource-specific endpoint, a deployment name instead of a direct model name, and an explicit API version. Authentication is typically performed using an API key.

LLM_PROVIDER_MISTRAL

The Mistral provider connects to Mistral AI's hosted API service. Mistral models are designed to provide strong general-purpose and reasoning performance while maintaining efficient resource usage and competitive pricing. Developers who want a balance between capability, response speed, and lower operational cost may find these models to be a good alternative to larger commercial providers. Some organizations may prefer Mistral AI due to regional deployment considerations or compatibility with European-based infrastructure and services.

See Also

  
 

Copyright © 2026 Catalyst Development Corporation. All rights reserved.