What is Nodea?

How Nodea actually works

The rest of this page is the long version — what Nodea looks like under the hood, how the tree is stored, how branches are computed, and the engineering decisions behind every node on the canvas. If you want to evaluate Nodea for your team, or you’re a developer curious about the architecture, this is the page to read.

1. Three-panel architecture

The Nodea app is a single Next.js route (/app) that renders three resizable panels:

• Sidebar— collapsible left panel (220 px ↔ 54 px) listing every conversation (“project”) the user has created. Search, new-project, and account controls live here.
• Chat panel — the linear view of the currently selected branch. New user messages stream a Claude response into this panel via Server-Sent Events.
• Tree panel — the canvas. A free pan-and-zoom XYFlow surface rendering the entire conversation as a directed tree. Clicking any node selects that branch and rewrites the chat panel to the path from root to that node.

The panels share a React context (AppContext) that holds the current project, the selected node, the layout positions, and the streaming state. Layout is recomputed in pure JS whenever the tree changes — no layout engine, just a deterministic breadth-first walk that places parents above children with horizontal spread per subtree width.

2. The tree, stored as two tables

The branching structure lives in Postgres (Supabase) as two tables:

projects (
  id          uuid primary key,
  user_id     uuid references auth.users,
  name        text,
  created_at  timestamptz
)

nodes (
  id          uuid primary key,
  project_id  uuid references projects,
  parent_id   uuid references nodes,   -- null = root
  role        text check (role in ('user','assistant')),
  content     text,
  position_x  real,
  position_y  real,
  created_at  timestamptz
)

That’s it. A conversation is a project. Every message — user or assistant — is a node with a single parent_id. Branching is just inserting a new node whose parent_id points to some existing node. The chat panel for a given selected node is the chain you get by walking parent_id back to null.

Row-level security policies (auth.uid() = user_id) ensure a user can only read and write their own projects and nodes.

3. What “branching” actually means

In linear chat (ChatGPT, Claude.ai), the conversation is a list. Each new message is appended; if you want a different answer to an earlier question, you either rewind (destroying history) or open a new chat (losing context).

In Nodea, the conversation is a directed acyclic tree. The system prompt and message history sent to Claude on each turn is the path from root to the currently selected node, not the entire project. Clicking a different node re-selects a different path and rebuilds the prompt accordingly. Every branch is completely independent — no “memory” from a sibling branch bleeds in.

This is what makes Nodea useful for non-linear thinking: comparing two different framings of the same question, A/B testing prompts, or exploring three different plans from the same starting point without losing any of them.

4. Model routing

Nodea uses three Claude models via the Vercel AI SDK and the Anthropic provider:

• claude-haiku-4-5-20251001 — fastest, lowest cost, used by default on free plans for short / simple prompts.
• claude-sonnet-4-6 — balanced reasoning quality, supports web search, used for complex prompts on free plans and default on Pro.
• claude-opus-4-7 — heaviest reasoning, Pro-only, automatically selected for complex prompts.

The routing rule is intentionally simple: if the user’s last message is longer than 100 words or matches a regex of reasoning-heavy verbs (analyze, compare, refactor, explain, design,…), it’s “complex” and upgrades a tier. Otherwise it stays at the cheaper tier. Pro users skip Haiku entirely.

5. Streaming and token accounting

The chat endpoint (/api/chat) is a streaming POST that calls streamTextfrom the Vercel AI SDK. Tokens are estimated up front (using a 4 chars-per-token approximation), checked against the user’s daily budget, and the actual usage is recorded after the stream completes — so a runaway response can’t silently drain a quota past the cap.

Daily limits are enforced in Postgres via a daily_token_usage table keyed on (user_id, date). Admin users (flagged via user_profiles.is_admin) bypass limits. Plan tiers (free, pro) come from user_profiles.plan, which is written by the Stripe webhook on subscription create / update / cancel events.

6. Search — keyword and semantic

The search modal supports two modes:

• Keyword search — live, client-side substring match across project names and node content. Instant; no network round-trip.
• Concept search— sends the query plus a compacted index of the user’s nodes to Claude (Haiku for free, Sonnet for Pro) and asks it to return the most semantically relevant matches with reasoning. Slower, network-dependent, but finds “the conversation where I was thinking about pricing” even if you never used the word “pricing.”

7. Authentication and anonymous mode

Auth runs entirely through Supabase. Two flows are supported:

• Email + password — standard sign-up with email verification and a password-reset flow at /login/update-password.
• Anonymous sign-in— Supabase’s anonymous user feature creates a real auth.usersrow without requiring an email. Anonymous users can chat, branch, and save projects exactly like signed-up users. They can later “claim” their data by linking an email — no data migration required.

8. Privacy and data flow

Nodea sends only the path from root to the selected node to Claude on each turn — never the entire tree, never sibling branches. The user’s data lives in their own Supabase row, isolated by RLS. Anthropic’s API terms prohibit training on the data sent through their commercial endpoints, so nothing you write in a Nodea conversation enters a model training set.

Anonymous analytics (page views, session duration, custom events) are captured via Vercel Analytics plus a self-hosted page_views table for the admin dashboard. No third-party trackers, no ads, no cross-site identifiers.

9. The full stack

10. Design philosophy

Three principles shape every product decision:

• Branching is a thinking pattern, not a feature. The tree isn’t a sidebar on top of a chat — it’s the data model. Everything else (the chat panel, the sidebar) is just a view onto the tree.
• Friction kills exploration.Anonymous sign-in, no credit card, no waitlist. If you have to think about whether opening a canvas is “worth it,” you’ll never see the second branch.
• The user’s data is theirs. Two-table schema, exportable, isolated by RLS. No vendor lock-in beyond Claude itself.