Adaline Gateway
A fully local, production-grade Super SDK offering a simple, unified, strongly typed TypeScript interface for calling 300+ LLMs.
As a fully local LLM gateway SDK, the privilege surface is narrow: HTTP requests go only to user-configured provider endpoints, no proxy, no telemetry by default (OpenTelemetry is opt-in). Deductions: no user-confirmation mechanism (weakly relevant for a library but undiscussed); sensitive-data handling rests on assertion only, and the Anthropic tests show a default 'anthropic-dangerous-direct-browser-access: true' header whose browser-side key-exposure implications are never discussed; rollback exists only implicitly via release PRs, with no consumer-facing rollback guidance; the release workflow writes NPM_TOKEN into a .npmrc file with continue-on-error — a pointed-out hygiene defect. Source attribution is clear (LICENSE, author, repository fields), though publisher identity is registry-unverified.
Reasonably self-consistent: README examples align with the @adaline/types type system; however the README contradicts itself — it claims 'more than 300+ LLMs' at the top while the provider table lists ~12 providers, and the task brief says '200+'. Dependency availability depends on external LLM providers, mitigated by retries/backoff/timeouts (covered by queue tests). Failure messages are a strength: typed GatewayError/InvalidMessagesError with tests asserting exact message content.
Aimed at TypeScript/Node>=18 developers; scenarios (chat, embeddings, tool calling, streaming) are clearly described; model schemas expose capability boundaries (maxTokens, modalities, roles); isomorphic environment claims. Deductions: trigger precision is largely inapplicable to a library (scored 1); browser-safety implications are undiscussed; unsupported modalities like PDF are inferable only from tests, not documented.
Strong information architecture: clear README, disciplined pnpm/turbo/changesets monorepo, installation notes distinguishing core vs optional provider packages, generous annotated examples, full MIT LICENSE, changesets-based versioning with a semver-validated release workflow. Deductions: known_limitations scored 1 — no limitations section exists and marketing claims ('trusted by enterprises', 'the only fully local Super SDK') are unsupported; naming stability lacks any deprecation policy; maintenance responsibility rests on a single named maintainer email with no governance files.
Output usability is strong: completeChat returns structured results (provider request/response, cache flag, latency, usage), and getChatUsageCost offers tiered pricing calculation with detailed unit tests (tiers, precision, boundaries). Marginal value: a unified interface over hundreds of models is real value, but the space is crowded (LiteLLM, Vercel AI SDK) and the README offers no comparative argument. Cost-benefit: fully local with no per-call fees; plugin design lowers integration cost — adequately evidenced.
Claim traceability is fair: code and tests corroborate each other (queue behavior, config transforms, error types all tested), and schemas are programmatically inspectable via chatModelSchemas(). Cross-source corroboration is weak: 'trusted by enterprises', '300+ LLMs', and 'production-grade' have no independent support within the provided files. Fact/inference separation is fair: example structures are checkable, but marketing assertions are intermixed with verifiable technical content without labeling. Confidence is low; this was a static source review with no execution.
- The README's '300+ LLMs' conflicts with the task brief's '200+' and the actual provider table; verify actual model coverage before adoption.
- The Anthropic provider sends a default 'anthropic-dangerous-direct-browser-access: true' header; in browser contexts this exposes API keys to end users — assess carefully.
- Marketing claims ('trusted by enterprises', 'production-grade') lack in-repo evidence and should not drive adoption decisions.
- The release flow writes NPM_TOKEN into .npmrc and uses continue-on-error on publish; pin versions and verify integrity on the consumer side.
- No known-limitations documentation; unsupported modalities (e.g., PDF) are inferable only from tests — validate per-modality before committing.
- This was a static source review (low confidence); no tests were executed and no requests were made.
What does this agent do, and when should you use it?
Adaline Gateway (GitHub: adaline/gateway) is a TypeScript library published to npm that provides one unified interface for calling over 300 LLM chat and embedding models. It is explicitly not a proxy: the SDK runs entirely in your process, so you can deploy it anywhere while keeping data private. The core Gateway class exposes completeChat, streamChat, and getEmbeddings methods with built-in batching, automatic retries with exponential backoff, caching, callbacks, and OpenTelemetry instrumentation. Providers ship as pluggable packages (e.g., @adaline/openai, @adaline/anthropic, @adaline/google, @adaline/bedrock), and a custom OpenAI-like provider type lets you run fully custom providers. All requests and responses flow through strongly typed structures from @adaline/types (MessageType, ConfigType, ToolType) that Gateway transforms to and from each provider's native schema. The project is MIT licensed and the README describes it as production-ready and trusted by enterprises.
After installing @adaline/gateway, @adaline/types, and the provider packages you need, you instantiate a Gateway and a provider (e.g., new OpenAI()) and build a model handle via openai.chatModel({ modelName: "gpt-4o", apiKey }). Calling gateway.completeChat (non-streaming) or gateway.streamChat (streaming) takes the model, a ConfigType (temperature, maxTokens, etc.), an array of MessageType objects, and ToolType definitions; the Gateway converts messages, roles (e.g., mapping assistant to Google's model role), and tool calls into each provider's native HTTP API and returns a normalized result containing response.usage (promptTokens/completionTokens/totalTokens), the raw provider.request/provider.response, a cached flag, and latencyInMs. gateway.getEmbeddings uses EmbeddingRequestsType to generate embeddings from providers such as OpenAI, Azure OpenAI, Google Vertex, xAi, and Voyage. Methods like openai.chatModelSchemas() expose each model's config schema and capabilities (maxInputTokens, modalities, roles) programmatically.
- TypeScript teams that need to switch or compare providers (OpenAI, Anthropic, Google, Bedrock) without rewriting integration code
- Platform engineers who want retries, batching, caching, and OpenTelemetry tracing in-process, without adding a proxy service or extra network hop
- Agent developers building tool-calling workflows who want a unified ToolType/tool-response abstraction across models
- Teams running local or private models via a custom OpenAI-like provider while keeping all SDK features
- Application developers who need one API for both chat completions and text embeddings (e.g., text-embedding-3-large)
- Enterprises that want to instrument every LLM call via callback hooks or plug in custom caching, logging, and HTTP client plugins
What are this agent's strengths and limitations?
- Fully local and not a proxy: the SDK runs inside your process and calls providers directly, preserving privacy and avoiding proxy infrastructure
- Batteries-included batching, automatic retries with exponential backoff, caching, callback hooks, and OpenTelemetry integration you don't have to build
- One strongly typed API (completeChat/streamChat/getEmbeddings) across 300+ models with automatic transformation of roles, content, and tool calls per provider
- Extensible via custom plugins (caching, logging, HTTP clients) and custom OpenAI-like providers
- MIT-licensed, typed, isomorphic TypeScript packages on npm
- You must hold and manage each provider's API keys and pay provider pricing; the SDK supplies no model credits itself
- Provider coverage is uneven: Anthropic, Groq, Together AI, and AWS Bedrock are documented as embedding-unsupported, and Voyage supports embeddings only
- Adoption couples your codebase to Adaline-specific types (ConfigType, MessageType, ToolType) and the @adaline/* package ecosystem, creating migration cost
- The README gives little detail on error-handling semantics, observability configuration, or the plugin API; you may need to read source code before committing
- Requires a Node.js/npm runtime; no concrete evidence is provided for specific browser or other JS runtimes beyond the generic isomorphic claim
How do you install or deploy this agent?
Requires a Node.js/npm environment and provider API keys. Install core packages: npm install @adaline/gateway @adaline/types. Install optional provider packages as needed, e.g.: npm install @adaline/openai @adaline/anthropic @adaline/google @adaline/open-router @adaline/bedrock.
How do you use this agent?
1) Import and instantiate: import { Gateway } from "@adaline/gateway"; import { OpenAI } from "@adaline/openai"; const gateway = new Gateway(); const openai = new OpenAI(); 2) Create a model with your API key: const gpt4o = openai.chatModel({ modelName: "gpt-4o", apiKey: OPENAI_API_KEY }); 3) Parse config and build messages: const config = Config().parse({ temperature: 0.7, maxTokens: 300 }); 4) Call await gateway.completeChat({ model: gpt4o, config, messages, tools: [] }) for non-streaming, or consume chunks from gateway.streamChat with a for-await loop. For embeddings, build openai.embeddingModel({ modelName: "text-embedding-3-large", apiKey }) and call gateway.getEmbeddings({ model, config, embeddingRequests }). Enumerate supported models and their schemas with openai.chatModelLiterals() and openai.chatModelSchemas().
How does this agent compare with similar options?
The README positions the project as a unified Super SDK for 300+ LLMs, implicitly contrasting with per-provider native SDKs (e.g., official OpenAI or Anthropic packages) and proxy-based LLM gateways; its stated differentiators are being fully local, not a proxy, multi-provider, and shipping built-in retries/caching/telemetry. No specific competitor products are named in the source.