xsai: a small OpenAI-compatible SDK for browser, edge and agent tooling

The problem xsai solves: an OpenAI-compatible client that fits in a bundle

Most AI SDKs are application frameworks. They ship provider adapters for a dozen vendors, retry and caching layers, and a runtime that assumes Node. If your app only ever calls an OpenAI-compatible endpoint, you pay for all of that in install size and in bundle size, and you inherit whatever runtime constraints the framework has.

xsai takes the opposite position. The README states the project is built for cases where full-featured AI frameworks are "too heavy, too broad, or simply unnecessary", and it lists three goals: small size, runtime portability, and a focused OpenAI-compatible surface. The audience follows from that: people writing browser clients, edge functions, and agent tooling who already know which endpoint they are calling.

The README is explicit about what is out of scope. There is no universal provider abstraction, no attempt to be a full AI application framework, and no extra runtime baggage. Those exclusions are the product. If you need to swap between Anthropic, Google and OpenAI behind one interface, xsai is not that library, and the documentation does not pretend otherwise.

How xsai stays small: Fetch, ESM-only, and per-utility packages

The mechanism is stated plainly in the README: xsai builds directly on top of the Fetch API, stays ESM-only, and avoids extra dependencies unless they are strictly necessary. Because it does not depend on Node.js built-in modules, the README says it works in browsers, Deno, Bun, and the Edge Runtime. That is the whole portability story, and it is a consequence of the Fetch choice rather than a separate adapter layer.

The repository layout backs this up. It is a pnpm workspace (packageManager pnpm@11.18.0, private root package @xsai/workspace) with packages/, packages-top/, and packages-ext/ directories, built with turbo and tsdown or pkgroll. The README points out that you can install only some of the utilities, naming @xsai/generate-text and @xsai/stream-text as examples. So the API surface is split across packages rather than re-exported from one bundle.

The size comparison in the README is the clearest statement of intent. Using Packagephobia install size and Bundlephobia minified/gzipped size, it lists xsai@0.4.0 at 142KB install, 22.7KB bundled, 7.1KB gzipped, against ai@6.0.11 at 5740KB, 301.5KB, and 74.3KB. The README concludes that xsAI reduces install size 40x and bundled size 13x. Two caveats matter here. First, those are 0.4.0 figures while the current version is 0.5.0, so treat them as a historical snapshot rather than a claim about what you will download. Second, the README notes the measured bundle includes dependencies introduced for tool calls and structured output, which means the number moves with the features you actually import. The README also gives the narrower case: @xsai/generate-text@0.4.0 alone is 22.6KB install, 4KB bundled, 1.7KB gzipped.

Installing xsai and making a first call

The README gives install commands for five package managers. Pick the one your project already uses. The npm form is:

npm install xsai

The same section lists yarn add xsai, pnpm add xsai, bun install xsai, and deno install npm:xsai. If you only need one capability, the README says you can install individual utilities instead, and the quick example below imports from the split packages rather than the umbrella package.

The first real call is generateText. This example is adapted from the README quick example, which reads the key from the environment and sends a system message plus a user message. The README shows the expected output as the string "YES".

import { env } from 'node:process'

import { generateText } from 'xsai'

const { text } = await generateText({
  apiKey: env.OPENAI_API_KEY!,
  baseURL: 'https://api.openai.com/v1/',
  messages: [
    { content: 'You are a helpful assistant.', role: 'system' },
    { content: 'This is a test, so please answer \'YES\' and nothing else.', role: 'user' },
  ],
  model: 'gpt-4o',
})

console.log(text)

Note the shape: apiKey, baseURL, messages, model. There is no provider object and no client instance to construct. baseURL is what makes the library OpenAI-compatible rather than OpenAI-only; point it at any endpoint that speaks the same API.

For streaming, the README imports streamText from @xsai/stream-text and iterates the returned textStream with for await. The example collects parts into a string array and logs the joined result. That async-iterator shape is the reason the library can run on edge runtimes, where a long-lived response body is normal and Node streams may not be available.

Tool calling is where the dependency story gets more interesting. The README example imports tool from @xsai/tool and valibot primitives (description, object, pipe, string) to describe parameters, then passes tools and toolChoice: 'required' to generateText, along with stopWhen: stepCountAtLeast(2) from @xsai/generate-text/shared-chat. The README's weather example returns a JSON string from execute and expects the model to produce a sentence containing the temperature. The README's own note that the bundle measurement includes tool-call and structured-output dependencies is the practical warning: importing @xsai/tool pulls in a schema library, so the size advantage narrows as you add features.

Where xsai is the wrong tool

The README's own scope statement is the first limitation: no universal provider abstraction. If your product needs to route the same call to OpenAI, Anthropic, and a local model behind one interface, xsai gives you no such interface. You would write the branching yourself, or choose a framework that ships adapters.

ESM-only is the second constraint, and it is a hard one for some codebases. Any CommonJS consumer, including older toolchains and some test setups, cannot require it. The README presents ESM-only as a deliberate part of staying small, but it is still a compatibility boundary you have to check before adopting.

The third is that the API is OpenAI-compatible by design, not provider-neutral. baseURL lets you point at a different host, but the request and response shape is the OpenAI one. An endpoint with a meaningfully different schema is out of scope.

Finally, the project is young. The release history shows v0.5.0 "mirai" on 2026-08-29, preceded by v0.5.0-beta.8 and v0.5.0-beta.7 in July and early August 2026. A 0.x line with a beta cycle that recent means the surface can still change between minor versions. The README does not document a deprecation policy or an upgrade guide, so pinning versions and reading the release notes before bumping is the practical approach. The last push to the repository was on 2026-09-14, so the code is current, but current is not the same as stable.

How xsai differs from a full AI SDK

The honest alternative is the Vercel AI SDK, and the README makes the comparison itself by putting xsai@0.4.0 and ai@6.0.11 side by side in its size table. The difference in approach is not just size. A full SDK gives you a provider abstraction: one call signature that fans out to many vendors, plus higher-level pieces like UI hooks and framework integrations. xsai gives you a thin Fetch-based client for one wire format and lets you assemble the rest.

That trade has a clear shape. A full SDK costs more install and bundle weight, and in exchange you get portability across vendors and a larger set of batteries. xsai costs you the abstraction and asks you to commit to OpenAI compatibility, and in exchange you get a package measured in kilobytes and a runtime that works in the browser and on the edge without Node built-ins.

Neither is a superset of the other. If your provider list is one entry long, the abstraction in a full SDK is overhead. If your provider list is long, xsai's focused surface becomes the thing you have to build on top of. The README's own framing is the fairest summary: xsAI is described as a small foundation for OpenAI-compatible apps and agents, not as a replacement for a framework.

Upgrades, versioning and the MIT licence

Upgrade cost is dominated by the 0.x version number rather than by the dependency tree. The README's size table is pinned to 0.4.0 while the workspace package.json reports version 0.5.0, which is a reminder that published documentation and published code drift. Before upgrading, read the release notes for the versions between your current one and the target; the repository uses bumpp and a bump.config.ts, and the release cadence shows a beta series leading into v0.5.0, which suggests the project does pre-release testing on the path to each minor.

Dependency weight is the other upgrade consideration, and it is under your control. Because the README says you can install individual utilities, a project that only calls generateText can depend on @xsai/generate-text alone and avoid pulling in the tool-calling and structured-output dependencies. That keeps the surface you have to re-verify on each upgrade small.

The licence is MIT, stated in the README and in LICENSE.md at the repository root. MIT is permissive: it allows commercial and closed-source use with attribution and the licence text included. That is a description of the licence, not legal advice; if your organisation has a policy on third-party licences, run the dependency through it. One practical note: if you install only a subset of the @xsai packages, check the licence of each package you actually depend on rather than assuming the root repository's licence covers your bundle.

Editorial conclusion

Adopt xsai when your target is an OpenAI-compatible endpoint and you care about install size or edge runtime compatibility, especially if you can install only the utilities you use, such as @xsai/generate-text or @xsai/stream-text. Skip it if you need one abstraction across several non-OpenAI providers, since the README states there is no universal provider abstraction. Before committing, verify that your endpoint accepts the baseURL and model you pass, and check the published size figures for the exact version you install rather than the 0.4.0 numbers quoted in the README.

Frequently asked questions

Official sources

1. License: MIT
2. moeru-ai/xsai on GitHub
3. Project website
4. README
5. Releases