BaseAI: a TypeScript framework for local AI pipes, now archived by its own authors

What BaseAI was built to remove from the AI agent loop

The problem BaseAI targets is the gap between a prompt you iterate on in a chat window and an agent you can call from your own application. Its answer is the pipe: a single TypeScript file that holds the model identifier, sampling parameters, the system message, and the lists of variables, memory and tools. That file is the agent definition, and it lives in your repository next to the rest of your code rather than in a hosted prompt editor. The audience is TypeScript developers who want to keep agent configuration under version control and run it locally before it ever reaches production. The README frames the pipe as "your custom-built AI agent as an API", which is the whole pitch in one line: author it as a config object, get an API out of it.

The pipe object is the architecture

The mechanism is visible in the generated pipe file. A pipe is a function returning a PipeI object, imported from @baseai/core, and the example in the README shows the fields that matter: apiKey reading from process.env.LANGBASE_API_KEY, a name and description, a status of public, a model string in provider:model form such as openai:gpt-4o-mini, plus stream, json, store and moderate booleans. Sampling is controlled by top_p, max_tokens, temperature, presence_penalty, frequency_penalty and stop. Tool behaviour is governed by tool_choice and parallel_tool_calls. Then four arrays: messages, variables, memory and tools. The messages array carries the system prompt as ordinary chat content. The memory array is where retrieval is attached, and the tools array is where callable functions go. On the application side, you import the pipe config, construct a new Pipe with it, call pipe.run with a messages array and a stream flag, and pass the returned stream to getRunner. The runner emits connect, content, end and error events, which the README demonstrates with listener callbacks. That is the entire data flow: config object in, stream of content events out.

Getting a pipe running locally

The documented path starts with npx baseai@latest init, which creates a baseai directory containing baseai.config.ts and the memory, pipes and tools subdirectories, alongside your existing package.json and .env. You then fill in environment variables. LANGBASE_API_KEY is required for both local and production, and the README marks it as server side only. The provider keys, OPENAI_API_KEY, ANTHROPIC_API_KEY, COHERE_API_KEY, FIREWORKS_API_KEY, GOOGLE_API_KEY, GROQ_API_KEY, MISTRAL_API_KEY, PERPLEXITY_API_KEY, TOGETHER_API_KEY and XAI_API_KEY, are described as local only and needed only for the providers you actually use. The README also notes that for Langbase itself the key belongs in a Langbase LLM keyset rather than in your local env file. Next, npx baseai@latest pipe walks you through name and description and writes a pipe into baseai/pipes. To execute it, you start npx baseai@latest dev in one terminal and run your entry file with npx tsx index.ts in another. Node users are told to import dotenv/config at the top of the entry file. The README shows the expected terminal output: a Stream started line, the model's rewritten text, and a Stream ended line.

The archive notice is the most important line in the README

The first paragraph of the README states that BaseAI is archived in favour of Langbase AI Primitives, and gives the reasoning directly: "the more we built BaseAI the more we realized frameworks are a bad idea in AI engineering." The authors argue that the space moves quickly and frameworks become blockers, and that memory, pipes and agents should instead be consumed as APIs callable from any language, with TypeScript and Python SDKs. That is a self-assessment from the maintainers, and it should carry more weight than any feature list below it. It also means the framework's own roadmap is closed. There are no retrieved releases in the supplied material, so there is no changelog evidence of ongoing maintenance either way. Anyone evaluating BaseAI today is evaluating a frozen artifact, not a moving target.

Where BaseAI is the wrong tool

The pipe config couples your agent definition to Langbase's runtime. The apiKey field points at LANGBASE_API_KEY, and the README separates Langbase credentials from the provider keys used for local runs, which means local execution and deployed execution do not go through the same credential path. If you want a framework that runs entirely inside your own infrastructure with no hosted control plane, this design is a mismatch. The provider key list is also a constraint in the other direction: the README enumerates eleven provider variables, and a pipe references exactly one model string, so multi-provider routing is something you would build yourself on top of the abstraction rather than get from it. There is a further limitation in the material itself: the README is truncated mid-sentence in the memory section, pointing at a quickstart guide for local RAG, so the retrieval behaviour of the memory array is documented elsewhere and cannot be assessed from the repository text alone. Finally, the licence field reports NOASSERTION, which is not a licence. Before using this in anything you ship, resolve that from the package metadata rather than the repository.

The obvious alternative is the thing BaseAI points at

The alternative named in the README is Langbase AI primitives: memory, pipes and agents exposed as APIs with TypeScript and Python SDKs, intended to be called from any language. The difference in approach is structural rather than cosmetic. BaseAI ships a local dev server and a config file format that your application imports directly, so the agent definition is code in your repo and the runtime is something you start with a command. The primitives model removes the framework layer and leaves HTTP endpoints plus SDK calls, which means no baseai directory, no PipeI type, and no getRunner event API. You would write the orchestration yourself, in whatever language you prefer. The README's own suggestion is to use a coding agent such as CommandCode to assemble your own framework over those primitives. Whether that trade is worth it depends on how much you value having the agent definition as a typed object in your codebase versus having fewer moving parts to maintain.

Maintenance cost and what the licence field does not tell you

The maintenance picture is straightforward: the project is archived, so there is no expectation of fixes, provider updates or new model support arriving from the maintainers. The practical cost of staying on BaseAI is that the model string in each pipe, for example openai:gpt-4o-mini, and the provider key list become your responsibility to keep current, and the npx baseai@latest invocation resolves to whatever is published on npm rather than to this repository's main branch. On licensing, the repository metadata reports NOASSERTION, which means no licence was detected or asserted in the machine-readable field. That is not the same as having no licence, and it is not something to guess at. Check the licence field of the published @baseai/core package and any LICENSE file in the repository before you redistribute or vendor the code. This article is not legal advice; treat the licence question as an open item to close before adoption, not after.

Editorial conclusion

BaseAI is worth adopting only if you want to read a working example of how a TypeScript agent framework was structured, or if you already have pipes committed under a baseai directory and need to understand what npx baseai@latest dev and npx baseai@latest pipe actually do. Do not start a new project on it: the README states it is archived in favour of Langbase AI primitives, and the framework's own authors argue that frameworks are a bad idea in AI engineering. Before doing anything, check the @baseai/core package on npm for the published version and its licence field, since the repository reports NOASSERTION rather than a named licence, and confirm which provider keys the pipes you inherit actually reference.

Official sources

1. CommandCodeAI/BaseAI on GitHub
2. Issues
3. Project website
4. README