Local reasoning for your notes, docs, and research

A project-scoped reasoning layer that runs on your machine.

lala ingests documents into named projects, answers from that project's context, and gives you a dedicated Plan: mode for turning grounded context into action. It runs locally through lala serve, which requires Docker to be installed and running, plus an ai-config.yml and locally available GGUF models.

Windows available nowmacOS nextDocker required (Docker Desktop recommended)BM25 / PostgreSQL FTS in v1

Download for Windows View on GitHub

lala serve → local runtime bootstrap

lala.ai CLI banner — Intelligent · Local first · Reasoning

1. Install Docker Desktop and make sure Docker is running

2. Download the lala.exe release

3. Run lala serve to start LLML + PostgreSQL locally

4. Run lala and work inside a project

Product shape at launch

lala serve

Bootstraps the local runtime. Requires Docker to be installed and running, then starts the inference layer and PostgreSQL and prints the connection details.

lala

The actual reasoning CLI: create/select projects, ingest files or feeds, search, ask grounded questions, and run Plan:.

Launch promise

Download a binary, bring up the local stack, and start reasoning over project-bounded knowledge. No GUI fiction, no cloud-first detour.

What lala actually is

Not a code editor with a chatbot bolted on.

lala is a local reasoning layer over knowledge you explicitly ingest. The model runs locally, retrieval is project-scoped, and answers are grounded in the active project instead of a vague global memory pool.

Project-scoped reasoning

Create a project, ingest notes or docs into it, and keep retrieval bounded to that project. No silent cross-project bleed.

Grounded in your material

v1 uses PostgreSQL full-text search over files, folders, and RSS content you ingest. It answers from what you gave it, not from the open web.

Local by construction

Inference runs through your local LLML runtime. Your machine, your model, your data path.

Projects + Plan mode

The core product is not "chat." It's bounded reasoning inside a project.

A project is the unit of memory, retrieval, and planning. That matters because it turns lala from a generic local chatbot into a workspace that can stay grounded in one body of knowledge at a time.

(onboarding-notes) >> /ingest ./docs

Ingested: 14 files · 118 chunks

(onboarding-notes) >> what should a new backend engineer read first?

Start with service topology, auth model, deployment flow, and on-call runbooks. Here's the order…

(onboarding-notes) >> Plan: create a 5-day onboarding plan

Day 1: repo access + local setup. Day 2: architecture walkthrough. Day 3: shadow incident review…

Why this matters

Project context is visible — the active project should be part of the prompt, not hidden state.
Plan is a named mode — it should render differently from normal chat because it's a different workflow.
Ingestion/search are scoped — users should know exactly what knowledge base the answer came from.

Reasoning model

Fast when it can be. Deliberate when it needs to be.

v1 uses a single work model. Simple queries can return directly; comparative or planning-style prompts can route through a deeper reasoning pass. The product should expose the result, not make users care about routing internals.

Direct path

"What files are in this project?"
"Summarize the latest design note."
"What does the infra doc say about auth?"

Reasoning / Plan path

"Compare the two approaches in my research notes."
"Plan a migration based on the design docs."
"What tradeoffs do these three RFCs imply?"

Launch scope honesty

What ships in v1, and what does not.

The landing page should not get ahead of the product. If a feature is not in the retrieval path at launch, say so plainly.

Shipped in v1

Windows CLI release
lala serve local runtime bootstrap
Single-model direct / reasoning flow
Projects + Plan: mode
File, folder, and RSS ingestion
BM25 / PostgreSQL full-text retrieval

Next up

macOS release
Real structured memory extraction
Semantic / vector retrieval and hybrid reranking
CLI onboarding polish and doctor/init flow

Get started

Ship the install story you actually support.

The landing page should mirror the real release flow. For end users, that means Docker first, then the lala binary. If the binary path is the launch story, the CLI output and docs need to reflect that exactly.

Install Docker Desktop

lala serve depends on Docker being available locally. For Windows and macOS users, Docker Desktop is the intended setup path and should be running before the user starts lala.

Install Docker Desktop and verify Docker is running

Create a working directory with ai-config.yml

lala expects ai-config.ymlin the same directory where the CLI is launched. The file defines the model directory, default work model, and local GGUF model file names.

C:\lala\my-project\ai-config.yml

Download GGUF models and point the config at them

Users must download their own GGUF models. model_dir should point to the folder containing those files, and each model_pathentry must match a real file name on disk.

model_dir: "D:\models"
default_work_model: "qwen-work"

work_models:
  - name: "qwen-work"
    model_path: "qwen2.5-3b-instruct-q4_k_m.gguf"

embedding_model:
  name: "bge-embedding"
  model_path: "bge-small-en-v1.5-q4_k_m.gguf"

Download the Windows binary

Use GitHub Releases as the distribution channel, but don’t make “browse the repo” the primary action. The page should point directly to the binary release.

lala-v1.x.x-windows-amd64.exe

Bring up the local runtime

lala serve should be the canonical path. It starts the local inference layer and PostgreSQL, then prints or persists the connection info.

lala serve

Run lala from the same directory

Launch lala from the directory containingai-config.yml. The CLI should fail fast with readable errors if the config is missing or if the configured GGUF files do not exist.

lala
/project create --name my-notes
/ingest ./docs