"I wish I could share this AI chat with someone, live."
"How do other people actually talk to AI?"
Have you ever felt this?
I couldn't stop thinking about it. Whether it's ChatGPT or Claude, your conversations with AI happen in a sealed room — just you and the model. You have a fascinating exchange, and then... nobody ever sees it. You have no idea what questions the person next to you is asking, or how deep their threads go.
That felt like a waste. So I built Sapio Tree — a platform for sharing conversations with AI.
The idea is simple
One sentence:
Take your conversation with an AI, and place it in a shared space where everyone brings theirs.
You publish an exchange you had with an AI. Others can read it.
And — they can branch off from any point in it.
"I'd continue that question differently."
"I want to attack that from another angle."
Fork from any card in someone else's conversation, and grow your own continuation. And it's not one fork per person: multiple people can branch in multiple directions from a single conversation — each using a different AI model.
That's why I call it Multifork. One question, passing through many minds and many models, branching as it grows.
Hence the name: Sapio Tree.
So why didn't this exist already?
"This idea is so simple — why has nobody built it?" I asked myself the same thing. The answer isn't "nobody thought of it." It's that the idea was structurally blocked — on three layers.
① Revenue: AI companies make money from individual (or per-org) subscriptions. "Sharing conversations with everyone" doesn't fit that model. There's no structural incentive to build it.
② Habit: We've spent decades not showing anyone our search history. AI chat inherited that default — locked in a private room — and nobody ever questioned it.
③ Competition — honestly, this is the big one. Imagine a major AI company builds a sharing platform. It would only run their model. Mixing competitors' models onto the same surface is a data risk and a business risk — you'd be presenting your own customers to your rivals. But the whole point of Multifork is that multiple AIs get mixed on the same tree. A Claude branch growing right next to a GPT branch. A model vendor structurally cannot build this: no revenue, pure risk, and it breaks their walled garden. It will never be a priority for them.
So it was never a technical problem. What blocked it was revenue structure, habit, and competitive position. Which is exactly why an individual with no allegiance to any model — me — could build it.
Why I wanted this to exist
Two root motives.
① Conversations with AI die on a single track.
Chat is linear. Thinking isn't. Every question has other possible continuations — "what if I'd asked it this way instead?" Current tools throw all those branches away. Every step forward deletes the paths not taken.
And beyond that: nobody has ever seen how the rest of the world talks to AI — where they dig deeper, where they change angles. In the AI era, I believe the real value isn't in the answers. It's in how questions get asked, and how thinking unfolds. There was no place to share that.
② I wanted to turn "disposable knowledge" into open collective intelligence.
Each private conversation is, in a sense, disposable knowledge: it serves its purpose, then gets thrown away. But bring those conversations together, connect them, let them branch — and someone else can regenerate them from a different angle. Link enough minds, and you can venture to places no single person could ever reach alone.
(I wrote more about this bigger idea — concentrating distributed intelligence — here: An orca is about to appear in this ocean of data.)
Try it — reading is free, forking is BYOK
Reading requires nothing. No account, no API key. Just look around and see how questions branch.
Forking — growing your own branch — needs your own API key (sign up, and you'll get the input screen plus links to obtain keys). That's the house rule here: your key, your thinking. BYOK — Bring Your Own Key.
One more design choice: the platform is English-first, but there's a built-in translation feature — running on your own Gemini key — so you can read any tree in your native language, and non-English speakers can connect their questions to the world. The goal is a place where thinking crosses language walls and gathers on one tree.
How I built it
Full honesty up front. Nearly all of the implementation was written through AI coding (Cursor). I come from architecture — the buildings kind — and I didn't produce this codebase line by line myself. What I did: decide what to build, decide the structure, review what the AI produced, and make it fix what was wrong. So this section isn't "how I wrote the code." It's "what design decisions I made." I may not be able to answer every implementation detail — but I can explain every structural choice in my own words.
Stack: Next.js / Vercel / Supabase (Postgres). Data lives in an EU region for GDPR (I'm currently studying in the EU). AI runs through each provider's API, BYOK-style. Translation also runs on the user's own Gemini key (more below).
Holding the tree: not "parent cards" but "branches and cards"
The heart of Multifork is the data structure. The naive version is "each message stores its parent message ID." Sapio Tree instead uses two layers:
-
branches — the skeleton. Each branch has
parent_branch_idandforked_from_card_id(which card it split from). -
cards — conversation units (a question + AI answer pair), belonging to a branch via
branch_id.
So cards don't point at parent cards. Cards belong to branches, and branches record the fork points.
A fork is almost nothing: create one new branch, INSERT one new card. Ancestors are never copied — at render time, we walk forked_from_card_id back to the root and assemble the "root → current" path by reference.
I learned this the hard way. The first implementation copied all ancestor cards into the new branch on the frontend. Result: the same card ID existed in multiple branches, and rendering kept breaking. Root cause: the DB's shape and the frontend's shape had diverged. The moment I made them isomorphic — "one fork = one new card" — that entire class of bugs died. Data structure design is bug prevention. Good lesson.
Multiple AIs on one tree — Gemini inherits Claude's words
Sounds complex; the DB side is almost embarrassingly simple: cards have a single model column (e.g. gemini-3.6-flash). Each card records who was asked; the UI renders the provider's icon and label from it.
The multi-AI complexity lives in the API relay layer (/api/chat), which reads the model prefix and dispatches to each provider's format. It's BYOK, so keys are passed per-request from the user's browser and never stored on the server.
And here's my favorite part of the whole product.
When you grow a branch, the answer isn't generated from nothing. The frontend's buildChatHistory assembles every card on the path from the root to the current card into the conversation history.
And it does not distinguish whose question a card was — or which model answered it.
- Another user's question on the path → goes into the history
- Another model's answer on the path → goes in too
Which means: Gemini reads Claude's answer as its own previous message, and continues the thought. The baton of context passes between models.
Fork the same card with different models, and the sibling branches become a natural model comparison — no "comparison feature" needed; the tree itself is the comparison device. And beyond comparison: GPT sets a premise, Claude carries it, Gemini extends it — a relay of thought across models. Not just side by side. Connected, inherited, growing.
(Only two exceptions never enter the history: deleted cards — tombstones, excluded per our terms — and the system root card. Everything else is inherited.)
In one sentence: a single lineage of thought, grown in relay by multiple humans and multiple AIs. That experience structurally cannot exist in a one-on-one chat. And it's the real answer to "why the big vendors can't build this": inheriting a rival model's words as your own context is simply not on the table when your business is a walled garden.
Translation: per card, ephemeral
Translation is per-card, on view, on demand. Hit translate on a card, and the question + answer get bundled into one prompt through the same /api/chat, using the viewer's own Gemini key (BYOK all the way down).
The key decision: translations are never stored (memory only; gone on reload). Persisting them creates an ugly question — "whose key paid for the translation that someone else is now reading?" — so they're deliberately ephemeral.
The target language is navigator.language, not the UI setting. This pairs with the platform's core design: post in English, read in your own language.
Why BYOK
Three reasons Sapio Tree runs on your own keys:
- Cost transparency — you pay for what you use. I don't need ads or subscriptions to recoup anything.
- User sovereignty — I never hold your keys or your generations.
- Early purity — honestly, BYOK is a barrier. But whoever crosses it is serious about AI conversations. The design itself curates the early community.
What's next — and an ask
Sapio Tree has just been planted. There are only a handful of trees so far.
Which is exactly why I'd love these people to try it:
- People who genuinely enjoy deep conversations with AI
- People who find how a question is asked more interesting than the answer itself
- People curious about their thinking connecting to someone else's branch
If you try it and feel anything — good or bad — I'd really appreciate the feedback. Comments here, or on the platform.
Back to the opening question.
Until now, our conversations with AI have been consumed one person at a time, in sealed rooms. But bring them together, in a form others can regenerate — and disposable knowledge becomes collective intelligence. Down branches other people grew, you might reach places you never could alone.
Sapio — wise.
Tree — well, tree.
That's the place I want to grow.
Top comments (0)