# Ling Stack: a local-first workspace where several AI models share one task

> Ling Stack is a TypeScript and Electron workspace that puts conversations, tool approvals and results for several AI models into one project channel, with the workspace state stored locally and the requests going to whichever provider you configure. It is a source alpha today, and the README is explicit that signed installers and a production release do not exist yet.

**ling-stack-org/ling-stack** — Local-first AI teammate workspace. Bring your own models and keep project conversations, tool approvals, and results together.

- Repository: https://github.com/ling-stack-org/ling-stack
- Stars: 1,003 · Forks: 114
- Language: TypeScript
- License: MIT
- Published: 2026-10-20 · Updated: 2026-10-20 · Language: en
- Canonical page: https://hysenlabs.com/projects/ling-stack-org-ling-stack

## The problem is scattered windows, not missing models

The README frames the problem concretely. When work involves several models, the task, their responses, tool requests and results can end up in separate windows. Ling Stack brings that work into a project channel where you give teammates model and tool bindings, review their activity, and keep the outcome with the conversation. Three usage shapes are laid out in a table. Asking a model means configuring a chat model and starting a conversation about a document, idea or project, with messages, model selection, attachments and results kept together. Working with AI teammates means binding models and tools to participants who then collaborate in a project channel, where participants, tool activity, approvals, artifacts and the final report stay together. Creating media means configuring an image or video capability and using Media Production, which keeps projects, scenes, generation jobs and outputs together. The design instruction at the end of that section is the one to hold on to: begin with a simple conversation, then add teammates or tools when the work needs them.

## One Model Workbench over seven provider families

The project connects OpenAI, Anthropic, Volcengine Ark, DeepSeek-compatible endpoints, MiniMax, GLM and OpenAI-compatible relays through a shared Model Workbench, and your own provider configuration and API key are required, with provider charges applying. The example environment file shows how concrete that is. Each provider gets its own variables: the OpenAI-compatible relay takes a base URL, an API key and a model; OpenAI takes a key and a model name; Anthropic takes a key and a model; Ark has a key, a base URL pointing at the Volcengine endpoint and a model; DeepSeek, MiniMax and GLM follow the same three-variable pattern with their own hosts; and a separate block covers Jimeng, Seedream and Seedance with an access key and a secret key rather than a single API key. The point of the environment file is that every provider is configured the same way, so adding a second model is a matter of filling in a block rather than learning a new integration. The first verified chat model becomes the workspace default, which is what the Model Workbench's Check action is for.

## Local state, remote requests, and the boundary between them

The split is stated plainly. Workspace state, conversation history and run evidence are stored locally, while requests and their context go to the model or tool providers you choose. That is the local-first claim, and it is a specific one rather than a marketing word: the record of what happened stays on your machine, and the only thing that leaves is the request you send. Run evidence in particular is the interesting term, because it implies that what a tool did is recorded alongside the conversation rather than living only in a provider's logs. The local daemon is the process that owns this state, and it listens on a loopback address by default, with the README instructing that you keep it on loopback. The default daemon address is http://127.0.0.1:17891, and the Web UI runs on a separate port at http://127.0.0.1:5173, with a health endpoint on the daemon that returns JSON containing an ok field.

## Tools and permissions are explicit, skills are only instructions

The distinction the README draws is between a skill and a tool. Skills provide instructions, while tool access and permission remain explicit, so a skill tells a teammate how to behave and a tool grant decides what it may actually do. The support table names the MCP and Plugin Manager surface as being about explicit tool assignment, activation and approval boundaries, which is the same idea stated at the platform level. The three usage scenarios each keep the approval record with the rest of the work: in the teammate scenario, participants, tool activity, approvals, artifacts and the final report are the things that stay together. The coding-agent path uses a runtime adapter called Pi, and the available execution tools depend on platform setup and workspace policy, so the same teammate behaves differently depending on what the workspace allows. This is the design that makes the workspace auditable rather than merely convenient.

## Running from source, in four commands

The requirements are Git, Node.js 22.22.1 or newer, and Corepack with pnpm 10, with pnpm 10.0.0 pinned and Node 22.22.1 as the CI baseline. The build installs dependencies and then builds the CLI, daemon and Web app together with their workspace dependencies, using a concurrency of one.

```bash
git clone https://github.com/ling-stack-org/ling-stack.git
cd ling-stack
corepack enable
corepack pnpm install --frozen-lockfile
corepack pnpm --workspace-concurrency=1 --filter '@ling-stack/cli...' -r build
```

The daemon then runs in the foreground in one terminal.

```bash
corepack pnpm ling daemon start --foreground
```

A second terminal starts the Web UI and opens the browser.

```bash
corepack pnpm ling ui --foreground --open
```

If the browser does not open, the same address works manually, and a curl to the health endpoint on the daemon should return JSON with an ok value of true. The CLI is the same entry point for everything, since the package manifest maps the ling script to the built CLI in the packages directory.

## The doctor command separates service health from model readiness

The diagnostic command exists because two different things can be wrong and they look the same from the outside. Doctor reports model readiness as well as local service health, and the README is explicit about the failure it does not fix. A fresh workspace with no chat model reports a provider failure even when the daemon and the Web UI are running fine. That distinction is the useful part of the tool: the daemon being up tells you nothing about whether a model is configured, and a provider failure in doctor does not mean your local install is broken. The practical sequence is to add a chat-capable model in Settings under Model Workbench, press Check, make a small conversation, inspect the response and its details, and only then run doctor to see the whole picture. Two documentation pages back this up, one for getting started with the first model, conversation and project channel, and one for troubleshooting setup errors.

## The support table is the honest status document

Rather than a feature list, the README publishes a table of surfaces and their current scope, and it is worth reading line by line. Web, daemon and CLI are the source alpha and the default getting-started path. The Electron Desktop is a development shell, with platform setup and clean-machine acceptance as separate gates still to pass. The Chrome extension and Browser Host are a local development integration, with Chrome Web Store publication pending. MCP and the Plugin Manager have explicit tool assignment, activation and approval boundaries. Office and Computer Use native features are platform-dependent development. Image and video generation depends on the provider and the capability, and selected live adapters still have open gates. Mobile is experimental work outside the current product acceptance scope. The stated open items are platform execution, accessibility, signing and installer acceptance for selected native features. The badge in the README says source alpha, and the note at the top says to start with the web UI, local daemon and CLI from source, with desktop development available separately.

## Where Ling Stack is the wrong choice

Four situations argue against it. If you need a supported product today, the answer is no, because the README says stable signed installers and a supported production release are not available yet and the desktop shell is a development environment rather than a shipped application. If you need to run it on a shared server, note that the daemon is designed to sit on loopback, so exposing it is not a supported deployment. If your organisation forbids bringing your own API keys, or you would rather not pay per provider, the model configuration requires your own keys and provider charges apply. And if your interest is in the agent tooling rather than the workspace, the MCP and plugin surfaces are explicitly about assignment and approval boundaries, which is a different feature from a plugin ecosystem. On the positive side of the ledger, the licence field on the repository says MIT, the repository ships a CODE_OF_CONDUCT, SECURITY, SUPPORT and THIRD_PARTY_NOTICES file, and it has a gitleaks configuration for secret scanning, which tells you the project treats accidental credential commits as a real risk.

## Conclusion

Use Ling Stack when your work spans more than one model or agent and you want the conversations, the tool requests and the outcomes in one place rather than in separate browser windows, since the project channel and the shared Model Workbench are what the project is built around. Do not adopt it as production software yet, because the README calls it a source alpha and states that stable signed installers and a supported production release are not available, and the support table lists several surfaces, from the Electron desktop shell to the Chrome extension, as still behind release gates. Verify first that you can supply your own provider configuration and API key, that your Node.js is 22.22.1 or newer with Corepack and pnpm 10 available, and that the daemon stays on its loopback address rather than being bound to a public interface.

## FAQ

### What does Ling Stack keep locally and what leaves the machine?

Workspace state, conversation history and run evidence are stored locally. Requests and their context go to the model or tool providers you choose, and your own provider configuration and API key are required, with provider charges applying.

### Which AI providers can I connect to Ling Stack?

It connects OpenAI, Anthropic, Volcengine Ark, DeepSeek-compatible endpoints, MiniMax, GLM and OpenAI-compatible relays through a shared Model Workbench. The example environment file shows the base URL, key and model variables for each, plus separate credentials for Jimeng, Seedream and Seedance.

### How do I run Ling Stack from source?

You need Git, Node.js 22.22.1 or newer, and Corepack with pnpm 10. Clone the repository, run corepack enable, install with corepack pnpm install --frozen-lockfile, build the CLI, daemon and Web app with the filtered workspace build, then start the daemon and the Web UI in two terminals.

### What does the ling doctor command check?

Doctor reports model readiness as well as local service health. The README notes that a fresh workspace with no chat model reports a provider failure even when the daemon and the Web UI are running, so the two failures are distinct.

### Is Ling Stack ready for production use?

Not yet. The README describes it as a source-first alpha, states that stable signed installers and a supported production release are not available, and lists the Electron Desktop as a development shell with platform setup and clean-machine acceptance still separate gates, and the Chrome extension as pending publication.

## Sources

- [Issues](https://github.com/ling-stack-org/ling-stack/issues)
- [License: MIT](https://github.com/ling-stack-org/ling-stack/blob/main/LICENSE)
- [ling-stack-org/ling-stack on GitHub](https://github.com/ling-stack-org/ling-stack)
- [README](https://github.com/ling-stack-org/ling-stack/blob/main/README.md)
- [Releases](https://github.com/ling-stack-org/ling-stack/releases)

---

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