Mito: AI chat, autocomplete and a spreadsheet inside JupyterLab

The gap Mito fills between a notebook and a chat window

Anyone doing analysis in JupyterLab spends part of the day moving text between the notebook and a browser tab. You copy a traceback into a chat window, paste a suggestion back, then fix the cell references by hand. Mito AI attacks that loop directly: the README describes context-aware AI Chat and error debugging as tools that help you get the most from LLMs, with the explicit promise that you stop copying and pasting between Jupyter and ChatGPT or Claude. Autocomplete is listed alongside chat in the repository description, so the assistant is meant to sit in the editing flow rather than in a side panel you visit deliberately.

The second piece is Mito Spreadsheet, and its audience is narrower than "data scientists" as a category. The README lists VLOOKUP-style formulas, filters, pivot tables and graphs, and then makes the claim that matters: every edit in the spreadsheet is converted to production-ready Python code. That is a different product from a notebook widget that renders a DataFrame. The output is source you keep.

The third piece, Mito for Streamlit and Dash, is for people shipping dashboards rather than exploring data themselves. The README says a fully featured spreadsheet goes into a dashboard in two lines of code. All three sit inside the same install, which is why the repository carries packages for the JupyterLab extension, the AI core, an MCP server, a CLI, a SQL cell and a VS Code extension in one tree.

How the monorepo is laid out and what each package does

The install command pulls two distributions, mito-ai and mitosheet, but the repository root holds far more than that. mito-ai/ is the Jupyter extension for chat and autocomplete. mitosheet/ is the spreadsheet extension. mito-ai-core/ and mito-ai-python-tool-executor/ sit underneath the AI feature, which suggests the model-facing logic and the code that actually executes tool calls are separated from the UI layer. mito-ai-mcp/ is an MCP server, and the only release in the repository is named mcpb-latest, dated 2026-04-23, described as the Mito AI MCP Bundle. mito-ai-cli/ is a command line entry point. mito-sql-cell/ and mitosheet-vscode/ are separate surfaces again.

For deployment there are jupyterhub/ and deployment/ directories, and binder/ for a hosted demo environment. The evals/ directory is the interesting one for anyone judging the AI feature: an evaluation harness in the tree implies the AI behaviour is measured somewhere, though the README does not describe what the evals cover or how they are run. tests/ sits at the top level as well.

This layout has a practical consequence. The two pip packages are the product, and everything else is either infrastructure the maintainers use or a surface that ships on its own schedule. If you file an issue about the MCP server or the SQL cell, you are in a part of the tree the install instructions never mention.

Installing Mito and getting a first spreadsheet-backed cell

The README gives a two-step install. Run the pip command first, in a terminal, command prompt or Anaconda Prompt:

python -m pip install mito-ai mitosheet

Both packages install together. The README does not document installing one without the other, so if you only want the spreadsheet, you are still pulling the AI package and its dependencies.

Then start JupyterLab:

jupyter lab

The README states this installs Mito for JupyterLab 4.0. That version claim is the one hard compatibility constraint in the install section, and it is worth reading literally: nothing in the README says the extensions work on JupyterLab 3, and the repository's own deployment workflow is named deploy-mitosheet-mitoinstaller, which points at a separate installer path for cases the pip route does not cover.

The README does not walk through opening the spreadsheet or the chat panel after launch, and it does not give a configuration snippet, an environment variable or a port. For a first real use, the documentation site is the source: docs.trymito.io has a page on importing CSV files into Mito, and the README links to it directly. That page, not the README, is where the actual first-task instructions live. If you need a hosted try-before-install, the repository carries a binder/ directory, but the README does not describe how to use it.

The licence is the first thing to check, not the last

GitHub reports the licence for this repository as NOASSERTION, which means the platform could not map the LICENSE file to a known identifier. The README says the project is open source and points to a plans page for feature detail, with a suggestion to purchase Mito Pro to fund development. Those two statements are not in conflict, but they do mean the repository is not a plain permissive-licence download, and the LICENSE file at the root is the only authoritative text.

There is also a .licenserc.yaml at the top level and a CLA.md. A contributor licence agreement plus a licence configuration file is the shape you see in projects that keep some rights concentrated, often so a commercial tier can exist alongside the open source code. That is a normal arrangement, and it is not something to guess about. If you are evaluating Mito for a company, read LICENSE before you install, not after. This is not legal advice, and the file is short enough to read in full.

The practical split the README implies is between a free open source tool and paid features on the plans page. Which features sit on which side is not stated in the repository text, so the plans page is the only place that answers it.

Where Mito is the wrong tool

The install section is the clearest limitation. Mito is a JupyterLab 4.0 extension, and the README does not claim support for other notebook front ends. If your team runs JupyterLab 3 for compatibility with other extensions, or works primarily in VS Code, the main product does not apply to you. The repository does contain mitosheet-vscode/, but the README's install instructions do not cover it, and nothing in the README says the VS Code surface has the same feature set.

Second, the spreadsheet-to-Python promise is a promise about generated code, and generated code is only as good as its readability for your team. The README says every edit is converted to production-ready Python. It does not show an example of the output, and it does not discuss what happens when a spreadsheet operation has no clean pandas equivalent. If your edits are complex enough that the generated code needs heavy editing, the spreadsheet interface has added a step rather than removed one.

Third, the AI features inherit the usual constraint of any assistant that sends notebook context to a model. The README describes context-aware chat as the selling point and says nothing about what context leaves your machine, what provider is used, or how to turn it off. For work under a data-handling policy, that silence is the blocker, and it is not answered anywhere in the repository text.

Finally, the release history is thin. The only release listed is mcpb-latest from 2026-04-23, and the last push was on 2026-07-21. That is recent enough that the project is not abandoned, but there is no versioned release cadence in the repository for the two packages the README tells you to install. Pinning a version for a team rollout means pinning something the repository does not document.

Mito Spreadsheet against pandas in a plain notebook

The obvious alternative is not another spreadsheet product. It is doing the work in a notebook with pandas directly, which is what most of Mito's users already do. The difference is in the interaction model. In a plain notebook, exploring a DataFrame means writing a groupby, running it, looking at the result, and rewriting it when the question changes. Mito Spreadsheet inverts that: you manipulate the data in a grid, and the code is the artifact left behind. For exploratory work where you will rewrite the same three lines five times, the grid is faster. For work where the transformation is already known, writing the pandas is faster than clicking through it, and the result is the same code either way.

The second real alternative is a notebook-native data viewer. A viewer renders your DataFrame and lets you look at it. Mito's claim is stronger than that: the edits become code you keep and can commit. That distinction matters when the result of exploration has to end up in a script or a pipeline rather than in a saved notebook output.

For the dashboard piece, the comparison is against writing the table yourself in Streamlit or Dash. Mito's pitch is two lines of code for a full spreadsheet, which is a real reduction if you need editing inside a dashboard. If you only need to display a static table, the two lines are not buying you anything you could not write in a few more.

Maintenance, upgrade cost and what the repository tells you

The last push to the default branch was on 2026-07-21, and the repository is not archived. That is the extent of what can be said about activity from the facts available. There is no versioned release for mito-ai or mitosheet in the release list, only the MCP bundle from 2026-04-23, so upgrading means taking whatever pip resolves rather than moving between documented versions.

That has a concrete cost. The README pins compatibility at JupyterLab 4.0, and JupyterLab itself moves. When a new JupyterLab major version lands, the extension has to follow, and there is no release note in the repository to tell you when it has. A team standardising on Mito should expect to test the extension against JupyterLab upgrades themselves rather than reading a compatibility table.

The monorepo layout spreads the maintenance surface further. mito-ai-mcp/, mito-ai-cli/, mito-sql-cell/ and mitosheet-vscode/ are separate deliverables with no release history listed here. If your team adopts one of those surfaces rather than the two pip packages, you are on a part of the tree with even less published about its cadence. The evals/ directory suggests the AI behaviour is tested internally; the README does not describe the results, so it is not evidence you can use in a procurement decision.

Editorial conclusion

Adopt Mito if you already work in JupyterLab and want AI assistance that sees your notebook context, or if you want spreadsheet-style data exploration that leaves pandas code behind instead of a binary file. Skip it if you need a documented licence before legal review, if you build on JupyterLab 3, or if you want a maintained release cadence you can plan upgrades around: the only release in the repository is mcpb-latest from 2026-04-23, and the last push was on 2026-07-21. Before rolling it out, run the two install commands on a test environment, confirm the extensions load in your JupyterLab version, and read the LICENSE file yourself, because GitHub reports the licence as NOASSERTION and the README only says the project is open source.

Frequently asked questions

Official sources

1. Issues
2. mito-ds/mito on GitHub
3. Project website
4. README
5. Releases