Your data, your model, your machine.

Open a CSV or Excel file and ask it things in plain English: filter it, clean it, chart it, write formulas for it, or have it explained back to you. You pick the model, and by default it runs on your own hardware. No account, no API key, nothing uploaded. The cloud is there if you want it, and off by default.

What it does

A question typed into the sidebar becomes read-only SQL, run against your sheet, and the result comes back as prose, or as a chart when the answer is shaped like one. Asking it to filter, sort, clean or reformat the sheet works the same way: the chat is the whole interface, and everything the app does goes through it. What you can ask lists what that covers today, and what it does not.

Charts come back as data rather than images: the backend sends a spec and the browser draws it, so no file is written and nothing has to be served back. What does reach the disk is your workspaces, in one local SQLite file, which is why this wants a host with real storage rather than a serverless function.

Local sheet, local model

Both halves run on your machine, and that is the default rather than a mode you switch into: Ollama on localhost:11434 answers the questions, a local SQLite file holds the workspaces. Nothing your sheet contains crosses the network. Not the rows, not the column names, not the question you asked. There is no account to make and no key to paste, because there is nobody on the other end.

That matters for the spreadsheets people actually have: salaries, patient lists, client records, anything under an NDA, anything an employer's policy says cannot be pasted into a chat window. The usual answer to those is that you cannot use this kind of tool at all.

If you do point it at a hosted model

Then be clear-eyed about what travels, because it is more than the question. Per question, a hosted provider receives:

• the question you typed, and the last few messages of the conversation;
• your column names on every question;
• when it draws a chart, the values inside your text columns: all of them for a column with twelve or fewer, three examples for anything wider. That is what stops it inventing categories that are not there;
• up to 200 rows of that query's results, with totals computed locally over all of them.

None of that is unusual for a tool like this, and all of it is avoidable by staying local. It is written down here because "your data stays private" is a claim worth being precise about, in both directions.

You still bring the model

Local is the default, not the limit. EDI is a harness: it talks to a local model through Ollama, to anything speaking the OpenAI-compatible wire format (LM Studio, vLLM, llama.cpp, OpenRouter), to Claude through the CLI you are already signed in to, or to Google, OpenAI, Anthropic and Groq. Pick one, and the quality of the answers follows from that choice rather than from anything in this repo.

Picking is a dropdown in the chat box, not a config file. It lists what your machine can actually reach: the models Ollama has pulled, Claude if the CLI is signed in, any provider whose key is already in your environment, each listed under the provider it came from. It switches between them without a restart. A key typed in there is written to a file next to your workspaces and never sent back to the browser. Choosing a model has the rest.

Running it with no accounts

There is nothing to configure for the local path; it is what you get by default. Six lines, none of which asks you for a key:

git clone https://github.com/illeniall239/EDI.git
cd EDI
pip install -r backend/requirements.txt
pip install langchain-ollama==0.3.3

ollama serve
EDI_LLM_PROVIDER=ollama uvicorn main:app --app-dir backend --port 8000

The Quickstart covers the frontend and the hosted path as well.

Built on Univer

The spreadsheet is Univer, an open-source office suite under Apache-2.0. EDI is a harness around it rather than a spreadsheet of its own: every cell, formula, filter and sort you touch is Univer's work. What this project adds is the part that answers questions about what is in those cells, and the adapter that lets a model edit the sheet the way you would, through the same API.

Alongside it: Next.js and React for the interface, Recharts for the charts, FastAPI and pandas on the server, and LangChain for one interface across the model providers.

Where to go next

• Quickstart: clone to running on your own machine, in about five minutes.
• What you can ask: the questions and commands it handles, tested against a real sheet.
• Choosing a model: what to run locally, the hosted options, and how to tell whether yours is good enough.
• Self-hosting, optional: what changes when EDI lives somewhere other than your machine.
• How it works: what happens between a question and an answer.
• HTTP API: the endpoints.