e2b-dev/ai-analyst: an E2B sandbox for CSV analysis with Llama 3.1

What e2b-dev/ai-analyst actually does with your CSV

The project answers a narrow question: how do you let a language model analyze a spreadsheet without giving it direct access to your machine? The README lists three features, analysis with Meta's Llama 3.1, CSV upload, and interactive charts, and the package.json shows the machinery behind them. The model never touches the numbers itself in the sense that matters. It writes code, and that code runs in an E2B sandbox, a remote code interpreter environment managed through @e2b/code-interpreter. The audience is developers who want to see that pattern working end to end in a small TypeScript codebase, roughly one app directory, one components directory, and one lib directory. It is not aimed at analysts who want to upload a file and get an answer; the homepage is a demo, and the README tells you to clone the repository and run it locally if you want your own copy.

The data flow: upload, prompt, sandbox execution, ECharts

The architecture follows the shape of a chat app with a code execution step in the middle. A CSV uploaded through the browser is passed to a Next.js route handler, which calls an LLM provider through Vercel's AI SDK. The provider is selected by which key you set: FIREWORKS_API_KEY or TOGETHER_API_KEY for hosted inference, or OLLAMA_BASE_URL for a local model server. The model produces Python, and that Python is sent to an E2B sandbox created with @e2b/code-interpreter. Charts come back as data the front end renders with echarts and echarts-for-react, so the visualization is interactive in the browser rather than a static image. The README points to the E2B documentation page on interactive charts for the supported list, which means the chart vocabulary is defined by E2B's runtime rather than by anything in this repository. One consequence worth noting: the LLM is not reading your CSV directly, it is writing code against a file that exists inside the sandbox, so the quality of the answer depends on the model's Python, not on its ability to eyeball a table.

Installing e2b-dev/ai-analyst and running a first analysis

The README gives a three-step path. Clone the repository, install dependencies, then copy the environment template and fill it in. Note the directory in the install step: the README says `cd fragments && npm i`, which does not match any top-level entry in the repository listing, so treat that line as suspect and check where package.json actually sits before running it. The package.json declares `"node": "24.x"` under engines, so a Node 24 runtime is the stated requirement.

git clone https://github.com/e2b-dev/ai-analyst.git
cd ai-analyst
npm i

The environment file is the part you cannot skip. Copy `.example.env` to `.env.local` and fill in variables for E2B and one LLM provider. E2B_API_KEY is required regardless of which model you choose, because the sandbox is where the generated Python runs.

cp .example.env .env.local

For a hosted model, set FIREWORKS_API_KEY or TOGETHER_API_KEY. For a local model, set OLLAMA_BASE_URL instead. The README links to the E2B dashboard for the E2B key. After that, the package.json scripts give you the usual Next.js commands: `npm run dev` for development, `npm run build` and `npm run start` for a production build. What you should see is the interface shown in preview.png: a prompt area, a CSV upload, and a chart panel that fills in once the sandbox returns results. If the chart panel stays empty, the first thing to check is whether the sandbox call succeeded, since a missing or invalid E2B_API_KEY fails there rather than at upload time.

Where the project is thin: deployment, limits and data handling

The README stops at running locally. It does not document deployment, authentication, rate limiting, maximum CSV size, or what happens to an uploaded file after the request finishes. For a tool whose entire purpose is uploading data, that last gap matters more than the others. The repository also carries no releases, so there is no versioned artifact to pin and no changelog to read; you are tracking the main branch. The last push was on 2026-08-17, so the code is recent, but recency of commits is not the same as a support commitment, and the README does not describe one. The dependency list is another signal: it includes @ai-sdk/anthropic, @ai-sdk/google and @ai-sdk/openai alongside the Fireworks and Ollama providers the README names, which suggests the provider surface is broader than the documentation admits and that the README has not kept pace with the code. If you need a system with an audit trail for who analyzed which file, this is the wrong starting point.

How it differs from a notebook assistant like Jupyter AI

Jupyter AI and similar notebook assistants also generate code from a prompt, but they run it in the kernel you already have open, on your machine, against data you have already loaded. The difference here is the execution boundary. In e2b-dev/ai-analyst the code runs in an E2B sandbox, which is a separate environment created through the SDK, and the CSV travels to it. That buys isolation and a clean runtime per request, and it costs you a network round trip plus E2B usage on every analysis. The trade-off is not free in either direction: a notebook assistant keeps your data local but inherits whatever packages and state your kernel has accumulated, while this project gets a predictable environment but depends on an external service being reachable and funded. If your data cannot leave your network, the sandbox model is a disqualifier rather than a feature, and you should look at the Ollama path only if the sandbox still runs somewhere you control, which the README does not address.

Licence, maintenance and what upgrading costs you

The repository is Apache-2.0, which permits commercial use and modification and includes an explicit patent grant, with the usual obligations around preserving notices and stating changes. That is a permissive baseline, and nothing in the README adds terms on top of it. It is not legal advice; check the LICENSE file and your own counsel if you plan to redistribute. On maintenance, the honest reading is that this is a demo repository with no releases and a README that has drifted from the dependency list. Upgrading means pulling main and reconciling a Next.js 14 app pinned to React 18.3.1 and Node 24, with the AI SDK at ^3.4.16 and the E2B SDK at ^1.0.2. Because there is no release cadence, you cannot plan upgrades against versions; you either follow main or fork and pin. The overrides block in package.json, which forces prismjs 1.30.0 and glob 10.5.0, is the kind of patchwork that tends to grow, and each of those pins is something you inherit.

Editorial conclusion

Adopt it if you want a readable reference implementation of LLM-generated code executed inside an E2B sandbox, and you have an E2B API key plus a Fireworks, Together AI or Ollama endpoint to point it at. Do not adopt it if you need a hosted multi-user analytics product, role-based access, or documented handling of sensitive CSVs, because none of that appears in the repository. Before deploying anywhere real, verify that the Next.js API routes enforce the file size and type limits you need, and check whether the sandbox lifetime configured in lib/ matches your cost expectations.

Frequently asked questions

Official sources

1. e2b-dev/ai-analyst on GitHub
2. Issues
3. License: Apache-2.0
4. Project website
5. README