Don't you want to see how other people talk to AI? — So I built it

Ojyawamaru — Mon, 03 Aug 2026 07:31:07 +0000

"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.

🔗 https://www.sapiotree.app/

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_id and forked_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.

🔗 https://www.sapiotree.app/

Prevent Accidental Sends on Mac! How I Built "EnterGuard" with Gemini (Hold Enter to Send)

Ojyawamaru — Thu, 29 Jan 2026 12:29:35 +0000

Intro: Do You Fear the Enter Key? 😱

Do you ever find yourself accidentally hitting Enter and sending a message before you're finished typing on Slack, Discord, or LINE?

It happens to me all the time lol. I try to create a new line like I do on my smartphone, but—bam!—message sent.
The worst moment was during an important Zoom meeting, when I accidentally fired off a half-written message in the real-time chat. It was so awkward.

Also, as a heavy AI user, accidentally sending an incomplete prompt to ChatGPT or Gemini is a nightmare. It ruins the context, the AI starts answering a half-finished question, and it’s incredibly stressful.

I searched everywhere for a solution, but the only answer I found online was:

"Just get used to hitting Shift + Enter."

But I couldn't get used to it. That's just not how my brain works lol.
Since I couldn't find a tool that solved this, I thought, "If it doesn't exist, why not build it myself?"

I'm an architecture student, not a coder. I can't write a single line of code from scratch.
So, I teamed up with Gemini Pro, bounced ideas back and forth, and built this Mac app.

Meet "EnterGuard" 🛡️

Here is the menu bar app I built.

It's Simple

I changed the behavior of the Enter key:

Tap Enter = ↵ New Line (Confirm)
Hold Enter = ➤ Send

That's it.
But this simple change completely eliminated the fear of accidental sends.
It works globally on macOS, including Slack, Discord, LINE, Messenger, and browser-based chats (and of course, AI interfaces).

Download for Free 📥

It is completely free to use. If you share this frustration, please give it a try!

👉 Download EnterGuard on Gumroad

Behind the Scenes: Pair Programming with Gemini

Here’s a little backstory on how a non-engineer built this.

Prompt Engineering = Architectural Design?

I have zero coding knowledge, but I felt that the process of "prompting" Gemini was surprisingly similar to the architectural design process.

Requirement Definition: Verbalize exactly "what I want."
Structuring Conditions: Design the order in which necessary conditions are assembled to achieve that.
Correction: When an error occurs, feed the log directly to AI and say, "Fix it like this."
Implementation: Paste the generated code, check the behavior, provide feedback, and refine it step by step.

Initially, I tried to run it with Python, but based on Gemini's advice, we switched to Swift and made it a menu bar resident app. We shaped it together through dialogue.

About the Source Code

Since the code was generated with Gemini, I haven't open-sourced the code itself yet, but I've created a project home on GitHub to verify that this is a legitimate project (and not a suspicious app).

📂 GitHub Repository

Wrapping Up

I hope this small tool helps reduce the "accidental send" stress, even if just a little.

If you have any feedback or find any bugs, please let me know in the comments!

DEV Community: Ojyawamaru