Incognide: a tileable workspace that keeps your models, agents and files on your own disk
Explore the unknown, build the future, own your data.
At a glance
- What is it?
- Incognide is an MIT-licensed TypeScript desktop application that combines code editors, terminals, browsers, PDF annotation, office documents and local or cloud LLM providers in one auto-saving workspace. Its pitch is data ownership and path-based organisation; the trade-off is that it asks you to install and manage the AI runtimes yourself.
- Who is it for?
- Adopt Incognide if you already run Ollama, LM Studio or llama.cpp and want a single auto-saving workspace where chats, editors, terminals and documents share a path-based layout. Do not adopt it if you expect the installer to give you a working model, or if you need a headless server component, since the material describes a desktop app with no CLI.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 1 day ago.
- What is it written in?
- Mainly TypeScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem Incognide targets: context scattered across tabs and tools
The README's opening claim is that Incognide "unifies chat, code, documents, web browsing, and media into a tileable workspace with intelligent context and composable automations." The concrete complaint behind that sentence is context switching: a coding session that also needs a browser tab, a PDF, a terminal and a chat window currently means four applications and a desktop full of windows. Incognide's answer is to make all of those tile types, arranged in one window, with each tab holding independent state. A chat tab, an editor tab and a PDF tab can sit side by side and keep their own scroll position, selection and session.
Who is this for? The setup wizard answers that question directly by asking you to pick a usage path: No AI, Cloud AI, or Local AI. The No AI path is a plain workspace for files, code, browsers, terminals, docs and maps, with no model calls at all. The Cloud AI path expects OpenAI, Anthropic or Gemini API keys. The Local AI path expects Ollama, LM Studio, llama.cpp or oMLX already running on your machine. That three-way split is the honest description of the audience. Incognide is not an AI product you buy and point at a task. It is a workspace shell that assumes you have already decided where your inference comes from.
How the workspace is put together: tiles, path organisation and a bundled backend
The README describes a path-based organisation for work, plus auto-saving workspaces that resume where you left off. Tiles are the unit of arrangement: chats, editors, PDFs, browsers, terminals and 3D viewers can be rearranged as the work changes, and each tab maintains independent state. That last detail matters more than it sounds. In a browser, tabs share a process and often share session state; here the README frames each tile as its own context, which is what makes a chat tile and an editor tile usable next to each other without one resetting the other.
On the AI side, inference is routed through what the README calls the bundled backend, including calls to locally running models via llama.cpp or omlx. That backend is deliberately thin. The README states that fine-tuning is different: for those calls, Incognide shells out to a Python virtual environment you specify, rather than bundling torch and transformers into the packaged executable. The stated reason is to keep the packaged executable small. This is the clearest architectural decision in the material, and it explains most of the setup friction described below. The app ships a backend that can talk to models, but it refuses to ship the machine learning stack.
Above the model layer sits a set of stateful features: agents that can run on scheduled jobs, team context, MCP server integration, memory suggestions you approve or reject, and knowledge graphs you can prune and evolve. There is also scheduled memory extraction, knowledge graph evolution and context compression. These are described as capabilities rather than documented workflows, and the README does not explain how a memory suggestion is generated or what a knowledge graph edge represents. Treat that part of the product as under-specified until you read the source.
Getting it running: the wizard, the config files and the provider probes
Installation is a platform installer from enpisi.com/incognide for Linux, macOS or Windows. There is no documented package-manager route and no CLI, so the install path is download, run, launch.
First launch runs a five-step wizard. Step two sets the theme and the data directory for teams, models and configs, defaulting to `~/.incognide`. Step three sets the default web search engine, the default terminal shell (auto-detected: `system`, `zsh` or `bash` on macOS and Linux, `powershell` on Windows) and an opt-in for activity tracking that the README says is local only and used for next-action predictions. Step four is the usage path choice. Step five depends on that choice: cloud keys or local models.
The wizard writes preferences to `localStorage` (theme, fonts, shortcuts, UI defaults) and settings to `~/.incogniderc`. API keys also live in `~/.incogniderc` as `export <PROVIDER>_API_KEY=...` lines, and can be added later under Settings, Global Settings or Team Management, API keys.
Local providers are probed at fixed endpoints. Ollama is expected on port 11434, LM Studio on 1234, llama.cpp on 8080, oMLX on 8000. The Model Manager checks both the port and the binary or app, and each tile reports one of three states: Running, Installed (not running), or Not found. Start and stop commands are printed where a binary exists. Ollama starts with `open -a Ollama` on macOS or `ollama serve` on Linux, and stops with `pkill -f 'ollama serve'`. LM Studio uses `lms server start` and `lms server stop` when the CLI is present. llama.cpp needs a model path, so Incognide prints the command for you: `llama-server -m <model.gguf> --port 8080`, stopped with `pkill -f llama-server`. oMLX launches as a menu-bar app. GGUF and GGML files can be loaded directly without a server, but only if llama.cpp or koboldcpp is installed; otherwise the GGUF tab shows Not found.
Fine-tuning has its own setup. Open Team Management, go to the Python Env tab, and pick an environment: Detected (venvs, pyenv, conda or uv environments found under the workspace, homedir and common paths), Create new venv (creates `<workspace>/.venv`), or a Custom path. Then click Install packages and choose a bundle: PyTorch (CPU), PyTorch (CUDA), Diffusers (Image Gen), Transformers (LLM), or Whisper (Speech). Individual packages can also be installed by name.
The states model: why Installed (not running) is the failure mode you will hit
The three-state model in the Model Manager is the most useful design detail in the README, and also the source of the most common first-run problem. A provider can be present on disk and still unusable, because the port is dead. Incognide distinguishes that case from a missing binary, which is more than most wrappers do, but it does not fix it for you. For llama.cpp in particular the app cannot start the server on its own, because a model path is required, so it prints the command and waits. If you skip that step, the tile stays in Installed (not running) and model calls fail.
The same split applies to GGUF loading. The README is explicit that direct GGUF and GGML loading depends on llama.cpp or koboldcpp being installed, and that the GGUF tab shows Not found otherwise. So the no-server path still requires an engine. There is no configuration in the supplied material for pointing Incognide at a remote inference endpoint other than the named cloud providers, and no documented way to set a custom base URL for an OpenAI-compatible server. If your inference lives behind a gateway, the material does not show how to reach it.
One more boundary: the README describes a desktop application with a setup wizard and a sidebar. Nothing in the material indicates a headless mode, a server binary or a CI story. If you need agents running on a machine without a display, this is the wrong tool, regardless of how the scheduling features read.
Where the documentation thins out: agents, knowledge graphs and memory
The highlights list is dense with features that the rest of the README does not explain. Agents can run on scheduled jobs, team context can be edited, MCP servers can be integrated, suggested memories can be approved or rejected, and knowledge graphs can be pruned and evolved. Scheduled memory extraction, knowledge graph evolution and context compression are listed as automations. Fine-tuning of text models is said to use curated data from your conversations and memories.
None of that comes with a schema, an example or a description of what happens on a schedule tick. There is no sample MCP server configuration, no explanation of how a memory becomes a suggestion, and no statement about where the knowledge graph is stored beyond the data directory. For an engineer deciding whether to adopt this, that is the part to read in the source before relying on it. The tile and provider plumbing is described concretely enough to evaluate from the README alone. The agent and memory layer is not.
There is also a question the README raises without answering: if memories and knowledge graphs are extracted from your conversations, and the whole pitch is owning your data, what exactly leaves the machine when the Cloud AI path is selected? The README says activity tracking is local only, and that keys live in `~/.incogniderc`, but it does not describe the data flow for memory extraction under a cloud provider. That is a gap worth closing yourself before putting sensitive material into a chat tile.
Alternatives and the difference in approach
The obvious comparison is VS Code with an AI extension. The difference is structural rather than feature-level. VS Code's extension model assumes the editor is the centre and everything else is a panel or a webview; Incognide assumes no single tile is the centre, and that a PDF, a browser and a chat deserve the same independent state as an editor. That is why the README can list DOCX, XLSX and PPTX editing, 3D STL viewing, LaTeX compilation and dashboards alongside terminals and code. VS Code can reach some of that through extensions, but the state model is different: a webview panel is not a first-class tile with its own session.
The second comparison is a chat client such as a local Ollama front end. Those tools do one thing and do it against a model endpoint. Incognide wraps the same endpoints but adds the workspace, the agents, the scheduling and the memory layer. The cost is that you inherit a much larger surface, and the parts of that surface the README does not document are the parts most likely to change between releases.
A third comparison is a notebook environment. Notebooks keep code, output and prose in one document with a linear execution model. Incognide keeps them in separate tiles with independent state and no shared execution order. If your work is exploratory and sequential, a notebook matches it better. If your work is a standing arrangement of tools you return to, the tile model fits.
Maintenance, releases and what the MIT licence does and does not settle
The release history shows a steady cadence: v0.2.28 in late August 2026, v0.2.29 a week later, v0.2.31 in early September, with the last push to main on 2026-09-10. Version numbers in the 0.2.x range signal that the project is still pre-1.0, and the features listed in the highlights (knowledge graph evolution, fine-tuning from curated conversation data) are the kind that tend to move between releases. Budget for reading release notes before upgrading, particularly if you have built workflows around agents or scheduled jobs.
Upgrade cost has two parts. The application itself is an installer, so upgrading is a download and a reinstall. The Python environment for fine-tuning is separate and does not upgrade with the app: packages are installed into a venv you chose in the Python Env tab, and the README's bundles (PyTorch CPU or CUDA, Diffusers, Transformers, Whisper) pull from upstream indexes. A torch upgrade can break a working fine-tune setup independently of anything Incognide does.
The licence is MIT, which permits commercial use, modification and redistribution provided the copyright notice and permission notice are included. That is the extent of what can be said here; the repository's LICENSE file is the authoritative text, and questions about your specific distribution or patent situation belong with a lawyer, not with a review. One practical note that follows from MIT plus a desktop app: nothing in the licence obliges anyone to keep publishing installers, so a fork is always the fallback if the upstream releases stop.
Editorial conclusion
Adopt Incognide if you already run Ollama, LM Studio or llama.cpp and want a single auto-saving workspace where chats, editors, terminals and documents share a path-based layout. Do not adopt it if you expect the installer to give you a working model, or if you need a headless server component, since the material describes a desktop app with no CLI. Before committing, verify three things on your own machine: that the Model Manager reports your provider as Running rather than Installed, that `~/.incogniderc` lands where you expect, and that the Python Env tab detects the interpreter you intend to use for fine-tuning.
Community notes