How Orchid works.

Three layers, one window — the IDE, the local kernel, and the cloud.

The three layers

Most data tools collapse this into one thing — a cloud notebook with a kernel attached and a sharing modal grafted on. Orchid keeps them separate so each can have the right shape.

Diagram with three horizontal layers: IDE on top (your window), Kernel in the middle (Python + SQL on your machine), Cloud on the bottom (auth + publish endpoints). Arrows show kernel <-> IDE high bandwidth, IDE <-> cloud thin and intermittent./docs-images/concepts/three-layers.png
The IDE is your window. The kernel runs locally. The cloud handles auth and publishing — nothing more.

The IDE — what you see

A native desktop app built on Eclipse Theia inside Electron. The layout is familiar to anyone who's used a code editor: file tree on the left, editor in the middle, panels on the right and bottom. Tabs hold notebooks, dashboards, schema browsers, and the agent chat. Everything is local — when you drag a panel, no network call happens.

The IDE is the source of truth for your project while you're working in it. When the agent proposes a change, it's a diff against what the IDE already has. When you save, you're writing a file on your disk.

The kernel — where code runs

Each project gets its own Python interpreter — bundled with Orchid, so no separate install — plus its own virtual environment for packages. Cells run against that interpreter; variables persist across cells the way you'd expect from a Jupyter session. SQL cells run too, but they don't go through Python — they connect directly to your database from your machine using your local credentials.

The kernel is yours. It has filesystem access, network access, and whatever else the OS gives it. There is no sandbox in the cloud-VM sense, because there is no cloud VM. If your laptop can reach a host, the kernel can reach it; if it can't, it can't.

Why no Docker

We considered containerizing the kernel. We ran the math: a bundled interpreter plus a per-project venv is faster to start, easier to debug, plays nicely with your IDE's file watchers, and removes a whole class of "why isn't my package available" problems. Containers buy you isolation we don't need on a single-user desktop.

The cloud — auth and publish

Orchid's backend is small on purpose. It handles two jobs: signing you in (Supabase Auth) and accepting published artifacts (a snapshot of a notebook or dashboard, plus its metadata). That's it. It does not run your code. It does not hold your credentials. It does not stream your data through anything it owns.

Agent traffic does flow through the cloud — your prompt goes to a model provider (Gemini on the free tier; Anthropic or OpenAI if you bring a key), and the response comes back to your IDE. But the kernel still executes locally; the model just drafts what to run.

How they talk

Two communication channels carry almost all the traffic. The IDE-to-kernel channel is fat — it streams stdout, stderr, plot frames, DataFrame previews, and variable inspection at interactive speeds, over a local socket. The IDE-to-cloud channel is thin — short HTTPS calls for auth tokens, model requests, and publish operations.

Sequence diagram: User edits a Python cell in the IDE; the IDE sends the cell source to the kernel; kernel executes locally against your warehouse over the user's network; results stream back to the IDE; the file on disk gets the new output./docs-images/concepts/data-flow.png
A normal cell run never leaves your machine. The cloud only sees traffic on auth, agent calls, and publish.

That asymmetry is what makes Orchid feel fast. The hot path — edit-run-see-output — is local-only, so latency is bounded by your CPU and your DB's response time, not by a round-trip to a multi-tenant cloud kernel that's probably warming up.

Why the cost model is different

Cloud notebooks meter compute. Every minute your kernel is awake costs someone money, so you pay for it — directly, via seat pricing, or indirectly, via aggressive idle timeouts that murder your session mid-thought. The compute is the product.

Orchid's compute runs on your laptop. There is no bill for a kernel because there is no kernel to bill for. The product is the IDE, the format, and the agents on top — and the agents are what we'll eventually charge for, in the form of premium model credits or BYO key. The free tier uses Gemini and stays free.

This means three things in practice. Your kernel is never "cold." You can leave Orchid open all day with a 4 GB DataFrame loaded and the only cost is RAM you were going to use anyway. And the bill — if there ever is one — is honest: you pay for the thing that's expensive (LLM tokens) and not for the thing that's cheap (cycles on your own CPU).

The seams matter

Keeping the IDE, the kernel, and the cloud as separate things — instead of one fused service — has knock-on effects across the product.

  • Credentials never leave your machine. They live in your OS keychain, the kernel reads them, and nothing else touches them. See Local-first for why this matters.
  • Notebooks are real files in real folders. Git works on them. Spotlight finds them. Backup tools see them. See Projects on disk.
  • Offline is just a connectivity state. If the model provider is unreachable, agents are unavailable; everything else still works. SQL against a local PostgreSQL works on a plane.
  • Publishing is an explicit boundary, not a default. Nothing leaves until you decide it should — and what leaves is a snapshot, not a live link to your machine.

Where to read next