It Started with Pickleball

I had a dumb, specific goal: prompt my AI from the pickleball court.

Not "build the perfect remote IDE." Not "redefine human-AI collaboration." I just wanted to answer agent questions, course-correct tasks, and keep momentum between matches so I could still feel productive while I was out.

That was it. A tiny itch.

Then I Realized What "Shared Machine" Actually Means

While digging into OpenCode, I realized sessions are machine-scoped.

Which means if multiple people land on the same machine, they are not just sharing compute. They are effectively sharing context:

• same filesystem
• same session pool
• same prompt history visibility

I will not go deep on the mechanics, but that discovery raised an interesting question in my head:

What happens if you intentionally expose this setup to the public?

So I Said "Fuck It" and Shipped It

OpenCode was easy enough to dockerize. Cloudflare Containers could run it. I had a domain. I had curiosity.

So I spun up one container, put a custom domain on it, and let people in.

No long launch plan. No polished onboarding. Just an open door and a strong suspicion that this might get weird.

It got weird fast.

If you want to look at the setup, the repo is here: swalker326/opencode-remote.

And the original post that kicked this off is here: original tweet.

The First Version Fell Over

I underestimated how many people would show up and start prompting at the same time.

With one instance, traffic stacked up immediately. Sessions collided. The container started falling over hard.

So I patched the architecture in real time:

• ran six container instances instead of one
• added worker logic to assign visitors a sticky cookie
• kept each user routed to the same backend instance
• increased instance resources so each box could absorb more load

It was still multiplayer, just partitioned multiplayer.

89k Requests in 12 Hours

I do not have exact visitor counts because I killed the experiment, but before shutdown we saw roughly 89,000 requests in about 12 hours across the six instances.

For a "what if" weekend deployment, that was more than enough signal.

People will show up. People will poke at everything. And people will turn your little experiment into a stress test immediately.

Collaborative? Technically. Good? Not Really.

Could strangers build together in this setup? Technically, yes.

Was it a good collaborative experience? Not even close.

It was chaotic, fragile, and confusing once concurrency climbed. Shared state without strong boundaries is less "multiplayer creativity" and more "everyone grabbing the same keyboard."

Still, there was something interesting there. You could feel the shape of a real collaborative model, even though this version absolutely was not it.

Why This Was Worth Doing

This experiment was not polished, but it was useful.

It surfaced problems I am going to face very soon in a work project:

• tenant/session isolation
• safe shared execution boundaries
• sticky routing strategies
• scaling behavior under unpredictable prompt traffic
• what "public by default" actually implies

I learned more in 12 chaotic hours than I would have learned from another week of architecture diagrams.

We Are Early, and That Is the Fun Part

This started with me wanting to prompt an agent from the pickleball court.

It ended with a live-fire reminder that AI tooling gets weird the second you add real users, real concurrency, and real network edges.

Messy? Yes. A little reckless? Also yes. Worth it? Absolutely.

---

If you had to design multiplayer AI terminals for real, what would you lock down first: session isolation, filesystem isolation, or prompt visibility?