Questions about LStack

No. LStack does not ship a foundation model — it sits above coding agents and manages the plan, queue, execution, handoffs, recovery, and review workflow. You connect an execution tool and a compatible model provider, and LStack directs the resulting worker. Claude Code is supported today, with more execution tools planned.

AI-assisted development is scattered across an editor, a chat window, a stack of terminals, model endpoints, and docker commands, with no shared place to see what is queued, running, or done. LStack replaces that scatter with one operating surface: projects and tickets, managed workers and providers, and the runtimes that run what gets built.

Those tools are where code gets written — an agent or an IDE working a session at a time. LStack is the layer above them: it holds the plan as durable tickets that survive across sessions, routes work to workers running on the models you choose, keeps builder and reviewer separate, and runs the software that comes out the other side. Claude Code is the execution tool LStack supports today, not a competing control plane.

No. Your editor, your agents, and your git workflow stay where they are. LStack coordinates them and gives the work a persistent home, so you can still open any project folder and work by hand.

Configured workers can keep moving through queued tickets while you are away — that is the point of a durable queue. It is not fully autonomous: when a worker cannot proceed safely, LStack stops visibly and leaves the ticket waiting for you rather than guessing. Expect to review what happened in the morning.

State lives in tickets and on-disk project documents, not in a chat transcript. Each ticket execution is pinned to one project and, on git-enabled projects, gets an isolated git worktree. When an agent session ends, the next one can pick up durable context instead of starting from an empty prompt.

Yes. Projects are independent, and the queue view spans all of them so you can see what is queued, running, blocked, and done in one place. Actual parallelism is bounded by the concurrency caps you set on each provider.

Review is a first-class workflow step. In automated review mode, one worker builds and a separate reviewer-role worker evaluates the captured review packet; an approval then requests a guarded merge. You can instead choose manual review, where the change waits for your decision, or explicitly opt into direct mode for work that does not need a separate review step.

LStack attempts bounded recovery — a limited number of retries rather than an open-ended loop. If it still cannot proceed safely, it stops visibly, marks the ticket blocked, and keeps the session and logs so you can see exactly where it stopped and why.

Yes, when the project's review policy allows it. In automated mode, reviewer approval requests a guarded merge; in manual mode, the merge waits for your approval. Direct mode can skip separate review only when you explicitly enable it, and every guarded merge still verifies the target before changing the main branch.

Model support follows the execution tool you choose. Today, Claude Code workers require a local or hosted Anthropic-compatible Messages API. Codex support will add an execution path for OpenAI-compatible models and endpoints, and later execution tools will expand the available combinations further.

Today, LStack supports Claude Code as its execution tool. Codex support for OpenAI-compatible models and endpoints is coming next, followed by LStack's own execution tool and additional integrations. When you create a worker, you choose an execution tool and a compatible model provider.

Yes, and mixing them is a normal setup. Point cheap or bulk work at a local endpoint and reserve a hosted model for the tasks that need it — the routing follows the workers you assign, not a single global model setting.

Yes. Builder and reviewer roles can be assigned to separate workers backed by different providers, allowing one model to implement a ticket and another to review it. Workers may also share a provider, and a single worker can hold both roles when that is how you configure the project.

No. Each execution tool requires a compatible API and model. Today, Claude Code needs an Anthropic-compatible Messages API; when Codex support arrives, it will use OpenAI-compatible models and endpoints. Choose a provider and model combination supported by the execution tool you want to run.

Yes. The lstack CLI installs and operates the product, including start, stop, restart, status, open, update (with rollback), backup, diagnostics through doctor, logs, and uninstall. The dashboard remains the primary surface for managing projects, tickets, workers, reviews, and runtimes.

On your machine. The installed control plane runs as a native host process and serves the dashboard on a loopback-only address, using port 4700 by default. Docker is used for the execution plane — workers and project runtimes — and there is no hosted LStack environment your projects run inside.

Your project files stay on your disk, in real folders that move with the project. The only thing that leaves is whatever gets sent to a model provider you configure — so if every provider you connect is local, nothing goes out. Point a worker at a hosted API and the usual rules of that API apply.

Isolation and repeatability. Workers and project runtimes run in managed containers, while git-enabled projects use separate ticket worktrees so parallel work does not collide. This also lets LStack start, inspect, rebuild, and stop the software your projects produce without installing project dependencies into the native control plane.

The control plane, dashboard, SQLite database, and CLI run natively on the host. Worker sessions and project runtimes run in Docker. Docker Compose v2 is required only when a project uses a multi-container stack runtime; there is no Docker Compose stack for the dashboard.

Every session runs in its own worker container pinned to a single project path. Git-enabled projects give each ticket an isolated worktree; projects without worktree isolation serialize builds so workers do not write the same working tree concurrently. Per-project secrets are stored encrypted rather than shared across projects.

Yes. At launch, LStack will remain local-only by default, with dashboard LAN access enabled deliberately from Settings for one selected private network address. Access from another device will require HTTPS and a local LStack operator sign-in. Sensitive execution, filesystem, credential, and network-setting controls will remain unavailable over the LAN, while project runtime ports can still be published separately when you choose.

LStack is in private Beta. Invitations go out directly from the public waitlist — there are no access codes — and invited testers get access through our private GitHub Beta repository. A polished public release is next.

The installed Beta supports Apple Silicon Macs plus Linux x86_64 and Linux arm64 with real Docker Engine. Native Windows and Intel Macs are not currently supported; Windows users can run LStack inside WSL2 with an Ubuntu x86_64 distribution. Available RAM, disk, and model capacity still determine how many workers and runtimes you can run comfortably.

Not today, and there is no public repository during the Beta. If that changes it will be announced to the waitlist first.

The Beta is free for invited testers and pricing for the public release has not been announced. Model usage is separate: local endpoints do not incur hosted API charges, while any cloud provider you configure bills you under its own terms.

LStack's documentation is public and available to everyone. It covers getting started and the product areas you will use to install, configure, and operate LStack.