Yesterday we introduced Telos Cloud and teased one of the services we built on it. This post is the technical deep dive on Breachpoint, an original multiplayer browser FPS, built and operated on Telos Cloud for over 26 days.
Why build a game?
We wanted to prove a few things:
- We could build sufficiently complex software from goals, and have agents evolve it autonomously against our rubrics.
- Telos could run effectively forever, and steering a Goal declaratively was actually useful.
- We could produce something we thought passed the 80/20 quality bar, and that we liked using.
In short, we wanted to go beyond chat-based "vibe coding", and a Call of Duty-inspired FPS felt like the right test:
-
It is stateful, networked, interactive, and immediately legible.
-
It needs an engine, maps, 3D art, and a persistent backend deployment. That's a lot of code to generate from scratch!
For reference: comparable multiplayer FPS prototypes have taken six months of active development by a dedicated team.
-
It also has to feel good. We didn't want to ship another sloppy one-shot AI game.
Early iteration
To write the first version of our Goal, I worked with my coding agents to identify the important features of an FPS and drafted an early spec, which we launched on August 4, 2026.
About 12 hours later we checked in. The first version was far from the mark.
Parts of the game worked mechanically (like shooting), but I could barely move around. The camera POV was flaky, assets minimal, and within a couple keystrokes the game froze.

The game also didn't look or feel great.
The problem, as it turned out, was our spec. While we had covered the basic game mechanics of a first-person shooter, we hadn't set a real quality bar, so the system had an easier stopping point than intended.
Over the 72 hours after the original telos apply, we made a series of updates to the Goal:
| Goal version | What changed |
|---|---|
1.0.0 | The original game goal specification, semi-rigorous rubric. |
1.1.0 | More visual quality evidence gates. |
1.2.0 | Explicit additional performance, gun feel, and quality gates. |
1.3.0-1.3.2 | Attempted incremental rubric patches, ultimately futile. |
Importantly, we didn't add any implementation details to any of these updates - just externally observable outcomes.
The system had been flying blind
Over a few rounds of spec iteration, we got better results for the actual game. We saw mechanics starting to form and I was able to play full matches. Gameplay was largely functional, but visuals had stopped getting better.
After inspection with telos logs, we realized why: the verifier was rendering Breachpoint in CPU-backed Chrome, at ~4 frames per second.
It could see the game, but more as a slideshow than a live process. Screenshots were slow and unreliable, and they missed most of what a real GPU would have drawn.
We've written before about why adversarial verification matters (after all, quality comes through friction).
Through Telos integrations, we gave the Goal access to Modal and attached a starred gpu-evaluation skill (in v1.3.3). Starred skills serve as required rubrics in Telos, so the skill defined the GPU evaluation loop the verifier had to run:
- Launch a Modal Sandbox with an NVIDIA T4 GPU attached.
- Run Breachpoint in a Chromium instance on the Sandbox.
- Save screenshots and other observability data, associated with the Goal revision.
- Terminate the Sandbox.
Here's what wiring that up looked like:
The first evaluation on a real T4 reported 60 frames per second and immediately showed a giant rotated weapon with no hands visible.
From the logs:
I independently read the accepted frames: untextured slab architecture on saltline, a floating hand-less rifle in every first-person frame, capsule-blob combatants, and per-texel speckle standing in for ground material.
The home stretch
From there, the run picked up. The system found and fixed capsule-shaped opponents, boxy buildings, flat windows, noisy terrain, and HUD collisions.
Now that the system could see what it was building, we stepped away and let it work for two weeks.
By the end of the run, the workspace held ~22K lines of first-party code (~14K game and server, ~8K tests and evaluation tooling) across 1,260 agent passes and 357 T4 Sandboxes.
The Goal kept going until the game met our bar, and it's still alive in case we want to steer it further. I've personally logged dozens of matches on the game.
Looking back
We ran this through our managed inference gateway, which routed to a mix of Claude Opus 5 and Kimi K3 served through Modal. Both were capable, but our impression from the run was that the verification environment and test-time compute mattered more than which model we used.
As code gets cheaper, we think that's all that's left: saying what you want, and saying what done looks like. We spent 3–4 hours writing and iterating on the goal spec, while the system ran for 26 whole days.
Try it out
Give this to your coding agent:
Set up Telos with your agent.
- Install it with
curl -fsSL https://usetelos.ai/install.sh | sh. - Run
telos loginto sign in to Telos Cloud. - Read the installed
telos-cliskill to get started.
