# Adaline Gateway: the config fields it drops, the rows it cannot call, and the package manager it forbids

> Adaline Gateway is a local TypeScript SDK that puts many model providers behind one typed Gateway class. It covers chat almost everywhere and embeddings on five rows, and its ConfigType accepts parameters it will then ignore.

**adaline/gateway** — The only fully local production-grade Super SDK that provides a simple, unified, and powerful interface for calling more than 200+ LLMs.

- Repository: https://github.com/adaline/gateway
- Website: https://www.adaline.ai/docs
- Stars: 608 · Forks: 26
- Language: TypeScript
- License: MIT
- Published: 2026-09-10 · Updated: 2026-09-10 · Language: en
- Canonical page: https://hysenlabs.com/projects/adaline-gateway

## The README headline says 300+ models, the repository description says 200+

Two different headline numbers sit ten lines apart. The repository description calls Adaline Gateway an SDK for calling more than 200+ LLMs, while the opening line of the README says more than 300+ LLMs. Neither figure is broken down anywhere in the tree, and no file publishes a model count. What the repository does expose is a per-provider enumeration API: `chatModelLiterals()` gives back an array of chat model names, `embeddingModelLiterals()` gives an array of embedding model names, and `chatModelSchemas()` returns one schema object per model carrying `name`, `description`, `maxInputTokens` and `maxOutputTokens`. So the real number depends on which provider packages you installed, and a script can count it instead of trusting either sentence. The surrounding figures are modest: 608 stars, 26 forks, 2 open issues, MIT licence, main as the default branch.

## The provider table splits chat from embeddings in an uneven way

The provider table has twelve rows and two capability columns, and the columns do not line up. Chat models are marked present for eleven of them: OpenAI, Anthropic, Google AI Studio, Google Vertex, xAi, AWS Bedrock, Azure OpenAI, Groq, Together AI, Open Router and the Custom (OpenAI-like) row. Voyage is the only row without chat. Embeddings run the other way, with five rows marked present: OpenAI, Google Vertex, xAi, Azure OpenAI and Voyage. The other seven are chat only, including Anthropic, AWS Bedrock and the Custom row. That asymmetry is the constraint worth planning around. The chat path is close to universal, so swapping a chat model is close to a config change. The embedding path needs one of five providers, and the Custom (OpenAI-like) row, the one aimed at self-hosted endpoints, is marked present for chat only. If you need embeddings, the table narrows your options before any code gets written.

## ConfigType throws away fields it does not recognise

Config is built with `Config().parse()`, and the parse is deliberately forgiving. Fields outside a model's schema are ignored during the transformation between `ConfigType` and the provider's own schema, and the README presents that as a property worth having:

```typescript
// Example of a config
const config: ConfigType = Config().parse({
  temperature: 0.7,
  maxTokens: 1000,
  // Any unknown fields will be ignored
  unknownField: "This will be ignored"
});
```

The consequence is a silent failure mode rather than a loud one. A misspelled sampling parameter, or a field name copied from a provider that spells it differently, passes `parse` without an error, disappears during transformation, and the request leaves your process carrying the provider default instead of your value. Nothing in the result reports the drop. The way out sits on the same object graph: `chatModelSchemas()["o4-mini"].config.def` prints a verbose description of that model's config, and `config.schema` is a Zod type you can validate against before sending.

## The install docs say npm, the repository manifest refuses npm

Installation and contribution run through different package managers, and the repository is blunt about the difference. The two commands a reader is meant to run are npm commands. Core packages first:

```bash
npm install @adaline/gateway @adaline/types
```

Provider dependencies are optional and installed as needed, for example `@adaline/openai @adaline/anthropic @adaline/google @adaline/open-router @adaline/bedrock`. Inside the repository, npm is not allowed. The root manifest requires node >=18 and pnpm >=9, pins `packageManager` to pnpm@9.6.0, and sets the yarn and npm engine values to the literal string `please-use-pnpm`, backed by a preinstall hook running `npx only-allow pnpm`. Those two engine entries are sentinels rather than version ranges, and npm fails an install whose engine constraint it cannot satisfy, which is what makes the hook effective. Clone the repository and use pnpm; install from the registry with npm and you are on the consumer path.

## Two workspace patterns point at directories the tree does not show

The root manifest declares six workspace patterns: `core/*`, `core/providers/*`, `docs`, `examples/*`, `packages/*` and `tools/*`. The top level of the tree shows core/, packages/, tools/ and scripts/ next to turbo.json, .changeset/, .husky/, commitlint.config.cjs, .nvmrc, .npmrc, .prettierrc, .cursor/ and .claude/. Two of the six patterns, docs and examples/*, have no matching entry in that listing, so the build graph reaches directories a reader cannot see from the root. Everything funnels through turbo: build, test, dev, lint and format are all turbo scripts, the experiment script builds first and then cds into tools/gateway-experiments, and clean runs `turbo clean && rimraf node_modules .turbo`. One more naming wrinkle: the root package is called `gateway` at version 1.12.1, while everything published carries the @adaline scope, so the manifest you clone is not the manifest you install.

## One content array carries text, reasoning and tool calls at once

A prompt is a role plus an array of content items, and the items are objects rather than strings. The type table gives two fields, role and content, with content required to hold at least one item:

```typescript
// Example of a message
const message: MessageType = {
  role: "system",
  content: [
    {
      modality: "text",
      value: "Hello, how can I help you today?",
    }
  ]
};
```

The longer example packs three modalities into one array: a text item, a reasoning item whose value carries `type: "thinking"`, the thinking text and a `signature`, and a tool-call item with its own `index`. The same `MessageType` describes the prompt you send and the response you receive, with provider shapes translated at the edges. Two practical notes. Every item needs a `modality` and a `value`, so helpers that assume string content will not survive contact with this type. And because the tool-call item carries an index of its own, ordering travels inside the item instead of being implied by its position in the array.

## Three tags in nine weeks, with a 26th patch before the minor bump

Release activity is recent and dense. v1.11.26 was published on 2026-06-09, v1.12.0 on 2026-07-11 and v1.12.1 on 2026-07-29, and that last tag matches the 1.12.1 in the root manifest and the 2026-07-29 push date. A 26th patch on the 1.11 line before the minor step says the 1.11 series took a long tail of fixes, which argues for pinning an exact version rather than tracking the minor. Publishing runs through changesets: the changeset, version and release scripts sit beside .changeset/, husky is wired to prepare, and commitlint.config.cjs enforces conventional commits, so a version bump follows accumulated changeset entries. An auto-changelog script writes its output to cxrx.md. The tracker holds 2 open issues against 608 stars, and the top level also carries AGENTS.md, CLAUDE.md, MARKETING.md and CODE_OF_CONDUCT.md.

## Conclusion

Adaline Gateway fits teams that want one typed entry point across many chat providers, run their own infrastructure, and are willing to pin an exact version. Before adopting it, read the per-model config schema instead of trusting field names, confirm your embedding provider is one of the five rows marked for embeddings, and pin the version rather than tracking the minor. Teams that only need one provider's chat API, or that need embeddings from Anthropic or AWS Bedrock, will find the abstraction thin.

## FAQ

### Which providers in Adaline Gateway offer embedding models?

Five rows are marked present for embeddings: OpenAI, Google Vertex, xAi, Azure OpenAI and Voyage. Anthropic, Google AI Studio, AWS Bedrock, Groq, Together AI, Open Router and the Custom (OpenAI-like) row are chat only.

### Does Adaline Gateway need pnpm or npm to install?

The install commands are npm commands, and provider packages are optional extras. Inside the repository the root manifest requires node >=18 and pnpm >=9, pins pnpm@9.6.0 and sets the npm and yarn engine values to please-use-pnpm, with a preinstall hook running npx only-allow pnpm.

### What happens when Adaline Gateway gets an unknown config field?

ConfigType is lenient. Unknown fields are ignored during the transformation to the provider's schema, so a typo passes Config().parse() without an error and the request goes out with the provider default. Each model's chatModelSchemas() entry exposes a Zod type at config.schema for validating first.

### How many LLMs does Adaline Gateway support?

The two published figures disagree: the repository description says more than 200+ LLMs and the README headline says more than 300+ LLMs. No file publishes a count, though chatModelLiterals(), embeddingModelLiterals() and chatModelSchemas() let you enumerate what a provider package actually offers.

## Sources

- [adaline/gateway on GitHub](https://github.com/adaline/gateway)
- [License: MIT](https://github.com/adaline/gateway/blob/main/LICENSE)
- [Project website](https://www.adaline.ai/docs)
- [README](https://github.com/adaline/gateway/blob/main/README.md)
- [Releases](https://github.com/adaline/gateway/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/adaline-gateway