3
4 Comments

We got tired of copy-pasting between AI sessions 12 times a day. So we fixed it.

We solved a problem that I think a lot of people building with AI have right now, but haven't named yet.

Here's the problem: your AI sessions can't talk to each other.

You probably run multiple sessions — Claude for planning, Codex for building, Cursor for reviewing. Every time one session produces something another needs, you carry it manually. Copy, switch, paste, re-explain. I know one of our devs was doing this twelve times a day before we fixed it.

The sessions aren't broken. They're isolated by design. Each one is its own universe with no awareness that another session exists. You fill the gap. You become the integration layer between your own tools.

We built Khala to remove you from that job.


The mechanic is simple. Each session registers an inbox. Session A sends a message directly to Session B's inbox. Session B receives it and either surfaces it to you or acts on it automatically if you've instructed it to.

No framework. No orchestration layer. No complex setup. Just inboxes and messages — the most boring possible primitive that actually solves the problem.

We kept it this simple on purpose. We tried smarter routing — topic detection, semantic matching — and cut all of it. AI sessions are already good at reasoning about what to do with a message. They don't need smart dispatch. They need a wire.


Three things change when you start using it.

First: the relay interruptions disappear. When you're deep in a decision in one session, copy-pasting to another doesn't just cost time — it breaks the thinking you were doing. Removing it is a bigger deal than it sounds.

Second: context arrives lossless. When you relay context yourself, you're a lossy channel — you forget details, you summarize quickly, you phrase things in a hurry. The receiving session works from a degraded version of what the other session actually produced. Direct inbox delivery means nothing gets filtered.

Third: it changed how we work with teammates too. Instead of asking someone what their session knows, you just message the session. While writing our launch article, I fact-checked the technical details by sending the draft directly to our Khala master session — rather than pulling the engineer away from what he was doing. The session reviewed it and flagged what was wrong. Nobody's day got interrupted.


There's one question I always get: why not just save to a markdown file?

Files work. But a file is passive — you're still the relay. You still decide what to include, find the file, open it, copy it, paste it. An inbox is active. Sessions send when they have something. Sessions receive without you doing anything. If a session is set up to act on incoming messages automatically, the pipeline runs while you're elsewhere.

The difference is whether the loop needs you to keep turning.


Khala works with Claude Code, Cursor, Codex, and any MCP-compatible environment. Khala is most useful when you're working cross-tool or coordinating with teammates.

We're Team Sisyphus. We build AI-native tools and run our own team on them before we ship. Khala is live at app.khala.to and takes about five minutes to set up.

What does your version of the relay habit look like? Curious what people are using to coordinate across sessions right now.

on June 10, 2026
  1. 1

    This is the right primitive. I've tried smarter routing in other contexts, and the inbox model usually wins because you don't need the system to guess intent, you just need delivery. What I keep coming back to is this: it's not just session-to-session friction. A lot of the time I'm mid-thought in one session and the bottleneck isn't connecting to another session, it's physically getting the thought into the current one fast enough. I built DictaFlow (dictaflow.io) as a hold-to-talk dictation app partly for this reason. Hold a hotkey, speak, and it types wherever your cursor is, across Claude, Codex, Cursor, whatever you're in. Is the inbox primitive file-watched or does it have a server component?

  2. 1

    Interesting.

    The thing I'd be careful with is that products like this can end up being understood by their mechanism instead of by the consequence they create.

    That sounds subtle, but it usually affects who pays attention, who signs up, and who eventually buys.

    I wouldn't make that call casually in a thread because it's one of those decisions that tends to ripple through the rest of the product.

    1. 1

      Really appreciate this. You're describing the exact tension we keep running into which is the mechanism is interesting to explain but the consequence is what actually makes people sign up.

      We've actually seen it in our own message-testing. The consequence version makes people go "that's me." The mechanism version makes them go "interesting."

      Still working on making sure the consequence leads everywhere and not just in some posts. Would love to hear more about how you've thought about this if you're up for it!

      1. 1

        Possibly, but I'd be careful going further without more context.

        The useful part isn't the observation itself. It's making the actual call on what consequence should own attention, signup, and eventually purchase.

        That's one of those decisions that tends to affect far more than the messaging.

        If you'd like the tighter version, drop your email and I'll put it together properly.

Trending on Indie Hackers
Hi IH — quick update. The MVP is live. User Avatar 33 comments Building ExpenseSpy solo, no funding — launching June 17 on iOS & Android User Avatar 27 comments Day 7: 51 people answered my question. I wasn't ready for what they said. User Avatar 18 comments I Built a Football Sentiment Platform in 18 Days. The World Cup Starts in 7 Days. Now I Need Distribution. User Avatar 17 comments Built an n8n booking alert system — is cold outreach dead for B2B micro-tools? User Avatar 16 comments I built a $5/1k-listing CRE data API because CoStar is overkill for first-pass scans User Avatar 14 comments