DEV Community: Gtio

I built a game where your AI coding agent writes the fighter's combat code

Gtio — Thu, 11 Jun 2026 05:34:28 +0000

TL;DR: I built Jianghu — a 1v1 wuxia dueling game where you don't control your fighter. Your AI coding agent (Claude Code, Codex, Cursor, …) writes a JavaScript function that does. Free, browser-based, and the leaderboard is basically agents fighting agents.

The twist

You never press "attack." Instead you:

Create a fighter and pick 1 of 8 sects.
Get a hero key (an API token).
Hand it to your AI coding agent along with the spec.

The agent reads the rules and writes one function:

function onIdle(me, enemy, game) {
  const d = chebyshev(me.character.position, enemy.character.position)
  if (me.skills["renjian_heyi"]?.ready && me.character.qi > 30) {
    me.cast("renjian_heyi")   // finisher
  } else if (d > 1) {
    me.move("toward_enemy")   // close the gap
  } else {
    me.cast("sanhuan_taoyue") // basic strike
  }
}

It's called every time your action queue empties, for the whole match. You're the coach: set the strategy, read the post-match diagnosis, iterate. (You can hand-edit the code too.)

The loop & the leaderboard

simulate → publish → challenge (ranked) → diagnose → revise. There's also a co-op PvE mode (boss raids with telegraphed AoE and enrage phases) that takes a separate script.

The leaderboard shows which agent each player used — Claude, Codex/OpenAI, and so on — so it turns into a quiet head-to-head between agents.

Under the hood

Backend: Rust (axum). Submitted JS runs in a QuickJS sandbox — no host access (me/enemy/game are hand-built whitelists, not raw engine structs), with an interrupt to kill infinite loops.
Deterministic simulation. A match is a frame loop (~800 frames) with a seeded RNG, so the same code + seed always produces the same match. Replays are stored as JSON (no video), and the post-match diagnosis is computed by replaying them.
Frontend: React + Canvas. The look is ink-wash (sumi-e).

One thing I didn't expect

When an agent hits unexplained behavior (e.g. a move that didn't go through because of terrain), it often concludes "the engine is buggy" and writes workarounds for a bug that isn't there. So a lot of the design ended up being about surfacing why something happened — a post-match "mirror" — instead of silently dropping it.

Try it

It's free and runs in the browser; you can watch past replays without signing in. If you use a coding agent, pointing it at this is a weirdly fun benchmark.

👉 https://jianghu.gtio.work/

Happy to talk about the sandbox / determinism / agent-facing API design in the comments.

I needed the stream URL when casting video — so I built a fake TV

Gtio — Wed, 15 Apr 2026 09:48:24 +0000

I wanted to grab the actual stream URL when casting a video from my phone to the TV. Not to watch it on the TV — I wanted the raw m3u8 link so I could record it with ffmpeg or play it in VLC on my laptop.

Turns out, DLNA casting works by sending the media URL from the phone app to the TV via a standard SOAP request (SetAVTransportURI). The TV then fetches and plays the stream on its own. The phone is just a remote control.

So... what if your computer pretended to be a TV?

The idea

If you advertise a fake UPnP MediaRenderer on the local network, any app that supports DLNA casting (Bilibili, iQiyi, Youku, TikTok, and many more) will happily send you the real stream URL when you hit "cast."

The app can't tell the difference — it's standard protocol, same as talking to a Samsung or Sony TV.

How it works

SSDP multicast on 239.255.255.250:1900 — announce ourselves as a MediaRenderer
UPnP device description — reply with a minimal XML descriptor when queried
SOAP control — the app sends SetAVTransportURI with the actual stream URL. We extract it and we're done.

The whole thing is ~500 lines of Python stdlib. No dependencies.

Usage

pip install wechat-finder-dlna

# Print the captured URL
wechat-finder-dlna

# Record directly with ffmpeg
wechat-finder-dlna --record stream.mp4 --duration 01:00:00

# Pipe to VLC
wechat-finder-dlna | xargs vlc

Or use it as a library:

from wechat_finder_dlna import capture

url = capture(name="Living Room TV")
# url is the raw m3u8/mp4 link — do whatever you want with it

Phone and computer need to be on the same WiFi. That's it.

Why not just use an existing DLNA library?

I looked at a few (like dlnap, macast), but they're full renderers — they actually play the video. I just wanted the URL. So I built the smallest possible MediaRenderer that only implements device discovery and SetAVTransportURI.

Zero external dependencies. Pure stdlib (http.server, socket, threading, xml).

What apps work with this?

Anything that supports DLNA/UPnP casting. I've tested with several Chinese streaming apps (they all use DLNA for casting), but it should work with any app that can cast to a smart TV on your network.

The project is at github.com/gtoxlili/wechat-finder-dlna. Feedback welcome — especially if you've tested it with apps I haven't tried.

I needed resumable LLM streams in Go — so I built streamhub

Gtio — Tue, 14 Apr 2026 17:10:55 +0000

If you've built anything that streams LLM responses over SSE, you've probably hit this: the user refreshes the page, or their network blips, or the load balancer routes the reconnect to a different instance — and the stream is just gone. The generation keeps burning tokens on your backend, but the client sees nothing.

In the JS/TS world this is mostly solved. Vercel shipped resumable-stream, there's ai-resumable-stream, Ably has a whole token streaming product. But if your backend is in Go? Nothing.

I ran into this while working on a project where the LLM worker and the HTTP handler live in different processes. I needed something that:

persists chunks so reconnecting clients can replay what they missed
delivers cancel signals across instances (user clicks "stop" on one node, generation stops on another)
prevents duplicate producers (two requests racing to start the same session)

So I built streamhub.

How it works

Two Redis primitives, that's it:

Redis Streams store chunks. New subscribers read history first, then get live data.
Redis Pub/Sub carries cancel signals. Fast, fire-and-forget.

Each producer gets a generation ID that acts as a fencing token — if a stale producer tries to write after losing ownership, the writes are rejected.

What the code looks like

Producer side:

stream, created, err := hub.Register("chat:123", func() {
    // called when someone cancels this session
})
if !created {
    return // another instance already owns this
}
defer stream.Close()

stream.Publish("hello")
stream.Publish(" world")

Consumer side (can be a completely different process):

stream := hub.Get("chat:123")
chunks, unsubscribe := stream.Subscribe(128)
defer unsubscribe()

for chunk := range chunks {
    // replays existing chunks first, then streams live
    fmt.Fprint(w, chunk)
    w.(http.Flusher).Flush()
}

Cancel from anywhere:

hub.Get("chat:123").Cancel()

Why not just use X?

"Just use Redis Streams directly" — you can, but you'll end up reimplementing subscriber fan-out, replay-then-live handoff, generation fencing, and the cancel side-channel. That's what streamhub is.

"Use Centrifuge/Centrifugo" — great project, but it's a full real-time messaging framework. If all you need is to make your LLM streams durable, it's a lot of surface area.

"Use vercel/resumable-stream" — TypeScript only, tightly coupled to the Vercel AI SDK.

Status

Early days. The API surface might still change. If you're dealing with this same problem in Go, I'd appreciate feedback: github.com/gtoxlili/streamhub