RailGPU

Let your favorite agent generate validated, WebGPU-accelerated simulations over MCP. A tiny typed language and a deterministic compiler make the code safer and the model more token-efficient

Comment

Inspiration

I spent a lot of time building with wgpu/WGSL. From headless simulation platforms in Rust + wgpu to statistics shaders/kernels in a Tauri app. But there was always the problem of boilerplate with GPU code. AI agents often hallucinate stuff, mess up bindings and other stuff leading to silent bugs or weird behavior. So I aimed to abstract that boilerplate away from the AI agents and want to allow them to generate portable GPU code easily and safely within WebGPU bounds. The aim is to make GPU programming a little more accessible. And as I've got a bit of experience with DSLs, I thought this would be a very fitting thing to attempt at this hackathon, while also stress testing what Codex can do while we focus on goals and architecture.

Also there is a separate premise here. Can LLM agents get more efficient, correct and effective when reducing the implementation surface and validating the constraints with a deterministic compiler + giving them access to a clean compiler with clear error messages that sits on top of (in this case WGSL) and maybe other project goals/languages? The benchmarks indicate yes, but I wouldn't trust the current methodology as a clear result. Especially against the no separate compiler but clear WGSL-check arm. Also I didn't have the time for statistical significance testing.

Beyond GPU programming, the broader hypothesis is that compiler-checked intermediate languages could make agent output safer in constrained domains such as databases, infrastructure, or robotics by separating model proposals from deterministic execution gates.

What it does

RailGPU lets coding agents turn a prompt into a small typed GPU program that is checked by a deterministic compiler before it runs in the browser. Instead of spending tokens and time generating, debugging and repairing WGSL, bindings, dispatches and WebGPU boilerplate, the agent writes a much smaller Spark program, gets clear compiler errors when something is wrong and returns a runnable share link. The idea is to make GPU programming cheaper, safer and more accessible by reducing how much code the model has to get right.

Today, one generic viewer supports particle systems, cellular automata, stencil simulations, and small N-body systems without program-specific host code.

How we built it

I defined the constraints, what I wanted, how the benchmarks should look and the overall goal and feedback-loop/MCP architecture. For the most part, the implementation work was done by GPT-5.6 inside the Codex harness or using GPT 5.6 within Claude Code.

Challenges we ran into

Choosing the right performance primitives and evaluating what scope is best suited for a hackathon with a timeline like this. Which features should be implemented to best showcase the vision/idea. How to prove/benchmark the effectiveness of this approach. Selecting how to implement the overarching goal of constraining an LLM to write code within portable WebGPU budgets and the compiler's safety rules. How to structure the feedback loop, what should be allowed by the compiler in v1 and which primitives to add, e.g. ping-pong buffers and SoA, in the limited time I had.

Accomplishments that we're proud of

The early efficiency results are promising, even though the current benchmark results are not conclusive.

Across two models (gpt-5.6-luna, gpt-5.3-codex-spark) on 20 frozen prompts, the typed-Spark arm reached equal-or-better validity while emitting ~2–3× fewer output tokens than raw-WGSL baselines. These are exploratory, generated-stage numbers. Every per-prompt prompt, source, repair, and token count is retained in the Repo. You can see the results in the evidence section on the webpage linked below.

The idea of a compiler deterministically gating LLM output before it is run as a tool to make LLMs more reliable in certain settings.

What we learned

  • How to better structure feedback loops for LLMs, and where LLMs fail in complex, fast-paced projects.
  • How to orchestrate Codex more effectively.
  • How a compiler can help models be more effective and safe and where it might be worth the effort to actually write such a compiler.
  • How difficult it is to benchmark LLM tool effectiveness reliably.

What's next for RailGPU

Add support for speed controls and maybe fields so users can interact with the simulation via the webpage to easily test and visualize models. Expand compiler capabilities, including 3D, definable functions and more.

Built With

Share this project:

Updates