LAMBDA: a self-hosted data analysis agent that runs Python in your own workspace

The gap LAMBDA fills between a chat window and a notebook

Most analysts already have the pieces: a dataset, a Python environment, and a model that can write code. What they do not have is a loop that carries state across those pieces. LAMBDA's README describes exactly that loop. You upload a dataset, ask a question in natural language, and the agent inspects the data, writes and runs code, produces charts, summarizes findings, and emits a report or notebook from the session. The target user is an analyst or statistician who wants the conversational entry point without giving up the artifacts. The repository is the runnable codebase behind the paper published in the Journal of the American Statistical Association, and the citation block names Sun, Han, Jiang, Qi, Sun, Yuan and Huang. That provenance matters for how you read the project: it is a research system that was productized into a web app, not a commercial analytics platform with a support contract.

A conversation-scoped workspace is the core design decision

The architecture is a React and TypeScript frontend talking to a FastAPI backend, with SQLite for storage. The mechanism that holds it together is the per-conversation workspace. The README states each conversation gets its own directory under backend/data/workspaces/<conversation_id>/, and that this workspace is persistent, so variables and generated files stay available throughout the analysis. That is the difference between this and a stateless code-generation chatbot. When the agent writes a dataframe to disk in one turn, the next turn can read it back, because the working directory did not change. Uploaded files, charts, reports and notebooks all land in the same tree and are surfaced in the Files panel, which the README describes as automatic artifact tracking. Runtime state lives under backend/data/ alongside lambda_local.db, uploads/ and workspaces/, and the README notes these paths are intentionally git-ignored. The model layer is deliberately thin: LAMBDA calls an OpenAI-style chat completions endpoint, so the agent logic is decoupled from any single provider.

Getting it running: two commands and three environment variables

The quick start assumes Python 3.11 or newer, Node.js 20 or newer, npm, and optionally TeX Live with XeLaTeX for PDF and Chinese reports. The documented path is to copy the backend environment template, edit three keys, and launch both services:

cp backend/.env.example backend/.env # set OPENAI_API_KEY, OPENAI_BASE_URL, MODEL_LIST ./start.sh

The app then serves at http://localhost:3000, and ./stop.sh shuts it down. If the default ports are taken, the README gives BACKEND_PORT=8010 FRONTEND_PORT=3010 ./start.sh. Model configuration is three variables: OPENAI_API_KEY, OPENAI_BASE_URL, and MODEL_LIST, which is a JSON array such as '["mimo-v2.5-pro","deepseek-v4-pro"]'. LAMBDA appends /chat/completions to the base URL. The README states the first model in the list becomes the default unless DEFAULT_MODEL is also set. For manual setup, the backend runs under uvicorn main:app --host 0.0.0.0 --port 8000 --reload from the backend directory, and the frontend under npm run dev. Note the host binding in that command: 0.0.0.0, not localhost.

The execution model is the security model, and the README says so

LAMBDA runs analysis code on the machine hosting the backend. The README's Runtime Note is blunt about the consequence: use it with trusted users and trusted data, and do not expose the backend directly to untrusted traffic without adding sandboxing or other isolation. There is no container boundary, no per-session process isolation and no permission layer described in the material. The manual setup command binds uvicorn to 0.0.0.0, which makes the backend reachable on every interface by default. If you follow the manual instructions on a cloud VM and open the port, you have a service that accepts natural-language instructions and executes Python. That is the single most important constraint in this review, and it is stated by the project itself rather than inferred. The optional system dependency script compounds the surface area: scripts/install-system-deps.sh installs pdflatex, xelatex, Chinese LaTeX packages and Noto CJK fonts, and the README notes that LAMBDA_AUTO_INSTALL_SYSTEM_DEPS=1 ./start.sh uses sudo apt-get, which is why it is opt-in.

Where LAMBDA is the wrong tool

Two cases stand out. The first is multi-tenant deployment. Nothing in the material describes user accounts, authentication or per-user isolation of the SQLite database. The storage layout is a single lambda_local.db plus shared uploads/ and workspaces/ directories. If two people point at the same backend, they are working inside the same filesystem and the same database, and the agent can read whatever the process can read. The second case is reproducibility-critical work. LAMBDA exports to Jupyter Notebook, Markdown and report bundles, PDF and slides, which is a genuine strength, but the session itself is a conversation. A notebook export captures the code that was run; it does not capture which model produced it or at which point in the dialogue. Teams with audit requirements will want to treat the exported notebook as the artifact of record and the conversation as scratch. There is also a licensing gap: the repository listing shows no licence, so the terms under which you may use or redistribute the code are not stated in the supplied material. That is a question for your own legal review, not something this review can settle.

How it differs from papermill, nbconvert and a BI dashboard

The closest comparison is not another agent, it is the notebook toolchain. Papermill executes a parameterized .ipynb and nbconvert renders it; both are deterministic and neither involves a model. LAMBDA inverts that: the analysis path is generated at runtime from a natural-language question, and the notebook is an output rather than an input. The trade is flexibility for predictability. A papermill run on the same parameters produces the same notebook every time, which is what you want for a scheduled report. LAMBDA produces a different path depending on the question, the model and the data, which is what you want for exploration. Against a BI dashboard the difference is starker: dashboards execute predefined queries against a governed semantic layer, while LAMBDA writes arbitrary Python against whatever files are in the workspace. The autonomous exploration mode described in the README, where the agent inspects the dataset, plans the analysis, runs code, builds charts and produces a report without step-by-step prompting, sits at the far end of that spectrum. It is the mode most likely to surprise you, in both directions.

Versioning, maintenance and what an upgrade costs you

The README states the latest code is on main and tagged lambda-v2, with the previous open source version preserved on the legacy-open-source branch and the lambda-v1 tag. The release list shows lambda-v2 in July 2026, an application beta in September 2025, and an alpha build in August 2025. That cadence suggests active development, and it also means the interface between frontend and backend is still moving. If you fork LAMBDA, budget for re-reading the diff between lambda-v1 and lambda-v2 rather than assuming the branch is a drop-in fallback. The dependency footprint is the other recurring cost: Python 3.11+, Node 20+, a running model endpoint, and optionally a full TeX Live installation with CJK fonts if you want Chinese reports. The TeX requirement is the one people underestimate, because it is a system-level install outside the virtual environment. There is no licence identifier in the repository listing, so the maintenance question of what you may ship downstream is unresolved in the material available here.

Editorial conclusion

Adopt LAMBDA if you want a self-hosted conversational layer over Python analysis and you control the machine it runs on, since the README states the backend executes analysis code on the host and should not be exposed to untrusted traffic without sandboxing. Skip it if you need a hosted multi-tenant service or a project with a declared licence, because the repository listing shows no licence file and the material gives no compliance guidance. Before rolling it out, verify three things: that your model endpoint actually serves {OPENAI_BASE_URL}/chat/completions, that the model IDs in MODEL_LIST resolve at the provider, and that backend/data/ (lambda_local.db, uploads/, workspaces/) sits on storage you are willing to keep conversation history in.

Official sources

1. AMA-CMFAI/LAMBDA on GitHub
2. Issues
3. Project website
4. README
5. Releases