Clusy

This page is about a project that got out of hand and became a company. Clusy started as a hackathon idea. We then took 6 months of intense engineering work to build it as a tool for ourselves. Then people started using it, Founders, Inc. took us into Off-Season II, and the pet project turned into the thing we spend most of our time on. Live at clusy.io.

The problem

All three of us have worked in computational research across different fields: astrophysics, finance, signal processing, security, robotics, and more. For years, we watched domain experts doing data work in outdated tooling such as Jupyter Notebook. We were frustrated with standard Jupyter-style interfaces for two main reasons.

1. Notebooks are linear, but research is not. In a research setting it is common to try approaches in parallel, change earlier assumptions, iterate on methods, and explore a wide variety of approaches. Research is not only deep but also wide, so the linearity of notebooks, requiring you to run everything in order, limits parallelisation and wider exploration.

2. Notebooks work badly with LLMs. If you have tried Gemini on Colab, or Cursor and Claude Code against notebooks in VSCode, you know this already. The .ipynb format is hard to parse in general — push a Jupyter notebook to GitHub and you cannot even preview it. In a world where you can make a website or an app in one or two prompts, the lack of agentic workflows in data-analysis tooling felt like a huge gap.

What we built

Clusy is a better notebook with an agent built into it. You describe the experiment in chat; the agent plans, finds data, writes notebook cells, runs them, reads the output, and decides what to do next. GPU-powered sandboxes let it handle long, compute-intensive requests such as model training and fine-tuning. It is still a real notebook — cells, a running kernel, and output under each cell — so you can edit anything by hand, take over mid-run, or leave the agent to work autonomously.

Most of our optimisation work lives in the runtime. Unlike a normal Python script, notebook cells can run in any order and any number of times; deleting code does not erase the state it produced. The source of truth is therefore the kernel state, not only the code. This is why traditional coding copilots often underperform with notebooks.

We build on the Jupyter kernel with three system-level improvements:

1. Kernel snapshotting. We periodically capture and persist the kernel state, so work is not lost and can finally be shared, restored, and version-controlled.

2. Cell branching. You can branch from any cell and run workloads in parallel — for example, training three architectures or parameter sets and comparing the results. Snapshotting lets child branches inherit the same state, turning the notebook from a linear document into an experiment graph without duplicating work.

3. A kernel-aware harness. The agent does more than read and complete code: it understands and works directly with the kernel state. It can configure sandboxes, install dependencies, attach GPUs, search the web, pull datasets, and call APIs — enough to carry long-running data-science workflows from prompt to result.

Try it at clusy.io.

Where it stands

We joined Founders, Inc.'s Off-Season II, launched, and the thing that used to live in a weekend hackathon now has thousands of people on it from around the world. We ship every week. The company is based in San Francisco, and the next chapter is still being written there.