# Thread is a Jupyter alternative whose five feature headings have no prose under them, and whose AI runs as a separate service > Thread installs from PyPI, launches with any of three command names, and puts a copilot beside the notebook editing experience rather than inside a replacement kernel. The architecture is legible in its dependency list: an embedded Jupyter kernel reached over JSON-RPC, a CodeMirror editor with third-party extensions, and an AI layer with two providers wired in behind its own Node service on a separate port. **alishobeiri/thread-notebook** — AI-powered Jupyter Notebook. Use AI to generate and edit code cells, automatically fix errors, and chat with your data - Repository: https://github.com/alishobeiri/thread-notebook - Stars: 1,105 · Forks: 56 - Language: JavaScript - License: AGPL-3.0 - Published: 2026-09-15 · Updated: 2026-09-15 · Language: en - Canonical page: https://hysenlabs.com/projects/alishobeiri-thread-notebook ## Five feature headings with no prose under any of them The features section is a numbered list of five titles and nothing else. A familiar notebook editing experience, natural language code edits, generating cells to answer questions, a context aware chat sidebar in the side panel, and automatic explanation or fixing of errors. Each is a heading with no paragraph, no example and no screenshot, which is unusual for a project that otherwise explains its setup carefully. It means the readme tells you what the product intends to be and nothing about how any of it behaves. The demo link is a video asset, and the one detailed workflow in the file is the settings path for pointing the model at a local runtime, so the interface is documented only where the author happened to be walking through it. Treat the dependency list as the real specification; it is far more informative than the feature section. ## Three entry points and two toolchains Installation is a single command from the Python registry: ```bash pip install thread-notebook ``` Launching accepts three names for the same program, which is a small kindness for people arriving from different directions: ```bash thread-notebook ``` ```bash thread ``` ```bash jupyter thread-notebook ``` The third form is the interesting one, because it registers the program in the same launcher namespace as every other notebook server on the machine, so it sits next to the classic one in a running list. Then the toolchains diverge. Consumers install with pip and never see a Node toolchain. Contributors clone a repository built on yarn workspaces with a monorepo tool, install dependencies with yarn, and run two terminals at once, one for the Jupyter server and one for the front end. Two build systems for one product is a cost paid by contributors, not by users, but it is the cost you are signing up for if you intend to change the code. ## The copilot is a separate Node service on its own port The development instructions say that running the repository takes two terminals, one running the Jupyter server and one running the Next.js front end. The AI features need a third thing, which almost nobody would guess from the install instructions: a folder named proxy, with its own dependencies, started on port 5001, while the notebook interface is served on port 3000 under a path. ```bash yarn install ``` ```bash yarn dev --port 5001 ``` So the shipped product is at least three processes: a notebook kernel, a web front end, and a service that mediates model calls. That third process is where credentials and prompts pass, and it is the component a self-hosted deployment has to keep alive. The published install hides all of it behind one console command, which is fine for a user and a genuine operational fact for anyone putting it on a server. ## Offline means pointing the settings at a local runtime The promise is that the copilot can run entirely locally, and the mechanism is a settings path rather than a flag. Once the notebook is running you open the settings icon in the bottom left, choose model settings, navigate to the local runtime entry and type in your model details. There is a keyboard shortcut for the chat panel, and the file invites you to run a query to see the result. Nothing about this requires an account, and no cloud key is needed if you already run models locally, which is the configuration that matters for anyone whose notebooks cannot leave the machine. The trade is the usual one: a local runtime means you own the model, the serving and the hardware, and the readme does not say which models are expected to work well. ## Two component libraries and two icon sets in one dependency list The manifest is the clearest description of the architecture anywhere in the repository. For the kernel, the Jupyter widget packages, the Lumino widget layer, the notebook format reader and the Jupyter services client, which together say the project embeds a real kernel rather than reimplementing execution, with a JSON-RPC client to talk to it. For editing, the CodeMirror meta package, its Python and Markdown language modes, a React wrapper, an indentation-marker extension and a hyper-link extension. For the copilot, an AI SDK with providers for two model vendors already wired in, plus a parser whose only job is best-effort recovery of malformed JSON, which is the signature of a component that reads model output. And a terminal-to-HTML converter for kernel output. Two component libraries and two icon systems are both present, which is the visible cost of a codebase that grew rather than was designed. ## The JavaScript package is 0.1.0, the distribution is 0.1.36 Two version numbers live in different worlds. The repository manifest declares a private package called thread-notebook at version 0.1.0, which is the front end source and is never published as such. The single tagged release is 0.1.36, and its release name names the Python registry, so the version you install with pip comes from a Python release pipeline that has walked thirty-six iterations while the JavaScript manifest has never moved. Pin the Python package and ignore the manifest. The rest of the root tells you what kind of project this is: three error-reporting configuration files for the client, the edge and the server, a deployment ignore file and a build script for a hosting platform, a sitemap generator wired to run after every build, a shared utilities package that is built before the front end compiles, and both an ESLint configuration and a Biome configuration with a formatter config, while the scripts themselves only invoke one linter and one formatter. ## Conclusion Use Thread if you want a copilot beside a real Jupyter kernel rather than a hosted notebook product with its own execution model, and if being able to point the model settings at a local runtime matters to you. Two things to know before you commit. The copilot is a separate service, so a deployment has two processes and two ports to keep alive, and the readme documents that only for contributors. And the feature list is five headings with nothing under them, so treat the demo and the dependency list as the actual specification. There is also a version-number trap: the JavaScript package in the repository is a private 0.1.0 while the distribution you install is at 0.1.36, so pin the Python package and ignore the manifest. ## FAQ ### What is Thread and how do I install it? It is a Jupyter alternative that puts an AI copilot into the notebook editing experience, and it runs locally. Installation is one command from the Python registry, after which the program can be launched under any of three names, including the form that registers it alongside other notebook servers on the same machine. ### Can Thread use a local model instead of a cloud API key? Yes. The readme describes a fully offline experience using a locally served model runtime, configured through the interface rather than a flag: open the settings icon in the bottom left, choose model settings, select the local runtime entry and enter the model details. ### What does running Thread from source involve? Two terminals, one running the Jupyter server and one running the Next.js front end, after installing dependencies with yarn. The AI features are separate again: a proxy folder with its own dependencies, started on port 5001, while the notebook interface is served on port 3000. ### Which version of Thread should I install? Pin the Python distribution, not the repository manifest. The JavaScript package in the repository is private and sits at 0.1.0, while the tagged release that names the Python registry is 0.1.36, so the two numbers describe different things and only one of them is what pip installs. ## Sources - [alishobeiri/thread-notebook on GitHub](https://github.com/alishobeiri/thread-notebook) - [Issues](https://github.com/alishobeiri/thread-notebook/issues) - [License: AGPL-3.0](https://github.com/alishobeiri/thread-notebook/blob/main/LICENSE) - [README](https://github.com/alishobeiri/thread-notebook/blob/main/README.md) - [Releases](https://github.com/alishobeiri/thread-notebook/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/alishobeiri-thread-notebook