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, netcode, maps, weapons, art, audio, persistence, and a working 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.
Let's walk through how it went.
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. We had listed everything an FPS needs to do, but said nothing about how it should look or feel, so the system had no reason to care.
Over the 72 hours after the original telos apply, we made a series of updates to the Goal. The ones that mattered:
| Goal version | What changed |
|---|---|
1.0.0 | The original game and deployment contract, with a harsh 1-4 visual scale. Some checks still accepted crude proxies |
1.1.0 | We added a release gate that judged the worst ordinary frame and explicitly rejected unfinished blockouts |
1.2.0 | We gave visual quality, performance, and gunfeel their own versioned bars, tied evidence to the build, and defined a gold slice |
1.3.0-1.3.1 | We stopped rewarding more features. Only visible polish in fresh, ordinary play counted |
1.3.2 | We calibrated against references and capped the score if ordinary scenes still looked thin, no matter how good the hero frame appeared |
None of these updates carried implementation details (after all, the implementation was a black box to us). We only changed what had to be true, and what counted as proof.
The agent was wearing blinders
For a while, sharper rubrics produced a better game. The mechanics held up and I could play full matches. Gameplay was roughly where the spec said it should be, but the visuals had stopped improving.
Reading the agent traces with telos logs, we found out why. The verifier was watching Breachpoint in CPU-rendered Chrome, at about 4 frames per second.
It could see the game, just barely. Screenshots were slow and unreliable, and they missed most of what a real GPU would have drawn. We had asked it to judge a shooter from a slideshow.
We've written before about why adversarial verification matters (after all, quality comes through friction). Here, the verifier could barely see what it was judging.
Through Telos integrations, we gave the Goal access to Modal and attached a starred gpu-evaluation skill. Starred skills serve as required rubrics in Telos, so the skill defined the GPU evaluation loop the verifier had to run:
- Launch an ephemeral NVIDIA T4-backed Sandbox on Modal.
- Open the current Breachpoint build in hardware-backed Chromium.
- Save screenshots and telemetry, tagged with the Goal revision and build they came from.
- Shut the Sandbox down when the pass finishes.
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! The agent could finally see what it had built.
The verifier's own findings from that morning:
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, HUD collisions, and plenty more.
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. The 357 T4 Sandboxes it launched on Modal added up to just 11.9 Sandbox-hours.
The Goal kept going until the game met our bar, and it's still alive in case we want to steer it further.
Here's where it ended up:
We were pleased with the output, and I've personally logged dozens of matches on the game.
Looking back
We ran this through our managed inference gateway's Max tier, 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.
The code was the cheap part. Most of our time went into deciding what we wanted and checking whether we got it.
As code gets cheaper, we think that's all that's left: saying what you want, and saying what done looks like. Telos is built so those two things are the whole job.
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.
