NeuroLink: one TypeScript interface for 24+ LLM providers

Who NeuroLink is for, and the problem it removes

The repository describes NeuroLink as the pipe layer for the AI nervous system: streams of tokens, tool calls, memory, voice and documents moving from providers to connectors. Strip the metaphor and the problem is ordinary. A TypeScript codebase that talks to OpenAI, then adds Anthropic, then adds Bedrock, ends up with three client libraries, three error shapes, three streaming formats and three sets of retry rules. NeuroLink's answer is to make the provider a parameter. The README's own framing is that you switch providers with a single parameter change.

The audience is narrower than the README's universal platform language suggests. The package is published as @juspay/neurolink, the primary language is TypeScript, and package.json sets engines to node >=22.0.0 and pnpm >=10.0.0. That is a modern Node target, not a library you drop into an older runtime. It is also a production extraction rather than a greenfield side project: the description says it powers Tara, Yama and Clairvoyance at Juspay, and the repository carries a .yama/ directory at the top level. Teams already running Node 22 and pnpm are the natural fit. Anyone on Node 18 or 20 has an upgrade to do first.

The streaming mechanism behind the single interface

The README's opening example is the clearest statement of the architecture. You construct a NeuroLink instance, call stream with an input object, and iterate the returned stream. Each chunk is checked with an "in" test before its content is written, which tells you the stream is a union of chunk shapes rather than a plain string sequence. That is the design decision the whole library rests on: everything is modelled as a stream, and the consumer filters for the shape it cares about.

Above that layer sits provider dispatch. The package description lists 24+ providers behind one consistent API, and the README's What's New table shows how new ones arrive: SambaNova and Cerebras are described as OpenAI-compatible Tier 2 catalog entries, with Cerebras noted as live-verified end to end for generate, stream, tools and structured output. That phrase matters. It implies a tiered catalog where some providers are first-class and others ride an OpenAI-compatible adapter, so behaviour across the long tail is not uniform by construction.

The rest of the surface hangs off the same object: built-in tools plus any MCP-compliant tool server, Redis memory, multi-provider failover, and a providerFallback callback with modelChain config introduced in v9.58.0. Failover is configured, not automatic. If you never set modelChain, a provider outage is still your outage.

Installing NeuroLink and running a first stream

The README points to docs.neurolink.ink and a Quick Start page, and the npm badge targets @juspay/neurolink. The package manager is pinned in package.json as [email protected], and the engine field requires Node 22 or newer, so check your runtime before anything else. Install the package itself with your package manager of choice.

pnpm add @juspay/neurolink

Credentials come from environment variables. The repository ships .env.example, which you copy to .env and fill in. For OpenAI the example names OPENAI_API_KEY, an optional OPENAI_MODEL defaulting to gpt-4o, and OPENAI_MAX_TOOLS with a documented default of 150, where lower values improve performance but limit tool availability.

cp .env.example .env
# then set OPENAI_API_KEY=sk-your-openai-api-key-here

The first real call is the README's streaming example. Construct the instance, call stream, and iterate. You should see text arrive in chunks rather than in one block, which is the behaviour the rest of the API is built around.

import { NeuroLink } from "@juspay/neurolink";

const pipe = new NeuroLink();

const result = await pipe.stream({ input: { text: "Hello" } });
for await (const chunk of result.stream) {
  if ("content" in chunk) {
    process.stdout.write(chunk.content);
  }
}

The README also advertises a CLI, built through the build:cli script into tsconfig.cli.json, and a GitHub Action defined by action.yml and built into action-dist/. Neither has documented usage beyond its presence in the repository, so treat the SDK path as the supported route until you read the docs site.

Where NeuroLink stops being the right tool

The provider catalog is the first limit. The README says 30+ providers and 100+ models in one place and 24+ in another, and the package description says 24+. Those numbers describe breadth, not parity. The Cerebras entry is honest about its own constraint: new SambaNova accounts require purchased credits. Breadth also means the long tail is thinner than the headline. If your application depends on one provider's newest feature, its native SDK will expose it before a compatibility layer does.

Node 22 is a hard floor. The engines field will block installs on older runtimes, and pnpm is pinned at 10.x. Teams on npm or yarn with a legacy lockfile have work to do before the first import.

Configuration is opt-in, which cuts both ways. Multi-provider failover needs providerFallback and modelChain wired up. Credential checking needs sdk.checkCredentials(), added in v9.59.0 alongside a typed ModelAccessDeniedError. None of this protects you unless you call it. And the surface area is large: voice, avatar, music, image generation, embeddings, RAG, memory and MCP all live in one package. If you want a small client for one vendor, you are carrying code you will never execute.

What NeuroLink does that a thin provider wrapper does not

The obvious alternative is to skip the abstraction and use each vendor's own SDK directly, or a lighter multi-provider client that only normalises chat completions. The difference is scope. A thin wrapper gives you one generate call and leaves tools, memory and audio to you. NeuroLink bundles them: the README lists 6 TTS providers (OpenAI TTS, ElevenLabs, Google TTS, Azure TTS, Fish Audio, Cartesia), 4 STT providers (Whisper, Deepgram, Azure STT, Google STT) and 2 realtime APIs (OpenAI Realtime, Gemini Live), all under the same object as chat.

The second difference is MCP. NeuroLink is MCP-native, meaning it connects to any MCP server, and the repository ships .mcp-config.json plus .mcp-servers.example.json and examples for dynamic and HTTP-transport MCP servers. A generic provider wrapper has no opinion about tool servers. If your stack already speaks MCP, that integration is the reason to look here rather than at a chat-completions shim.

The third is operational. Redis-backed memory and the modelChain fallback config are things you would otherwise write yourself. The trade is that you inherit NeuroLink's opinions about how those pieces fit together, and its release cadence with them.

Maintenance, versioning and what the MIT licence leaves you

The repository is not archived, and the last push was on 2026-08-29, the same day v12.7.0 shipped, with v12.6.1 and v12.6.0 landing hours earlier. Releases arrive in clusters, and the What's New table spans v9.58.0 through v9.62.0 plus entries marked next. Note that package.json in the repository still reads version 11.2.3 while the release list is at v12.7.0, so the checked-in manifest and the published tags are not in step. Read the tag, not the file, when you pin.

Upgrade cost is real. The major version has moved at least once between the manifest and the tags, and a library that adds providers, modalities and error types this quickly will keep changing its surface. The repository carries .changeset/ and .releaserc.json, so changes are recorded and versioned deliberately rather than dumped.

The licence is MIT, stated in the LICENSE file and in package.json. That is permissive and permits commercial use, but it also means no warranty and no support obligation from Juspay. The package lists a support address and a GitHub Sponsors funding link; neither is a contractual commitment. Read the licence text yourself rather than relying on this summary, which is not legal advice.

Editorial conclusion

Adopt NeuroLink if you are writing TypeScript and expect to change model vendors more than once, because the provider name is a parameter rather than a rewrite. Do not adopt it if you need a Python SDK, or if you want a narrow client for a single vendor whose own SDK you already understand. Before committing, check the provider matrix against the models you actually call, confirm the Node 22.0.0 engine requirement against your runtime, and read the licence file for the MIT terms.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes