Can your AI model survive its own mistakes?

Model releases lead with their highest achievements, but almost none document how a model performs when a prompt is incomplete or ambiguous, or what it does once its own errors start piling up. Tapoo is a behaviour profiler built for exactly that: it puts a model under structured uncertainty, records every decision it makes, and builds a profile - a fingerprint of observed capabilities and violations - of how it copes.

Survival is computed - Every turn is charged against a fixed budget; batching several correct moves into one turn earns part of that budget back; and a model survives its own mistakes exactly when what its batching earns covers what its errors cost. When it does not, the run is already unwinnable at any pace ever observed, with budget still in hand

• and Tapoo names the turn.

Try it live, in your browser - nothing to install:

• Tapoo - dmigwi.github.io/tapoo: configure a model on the agents page, let it run, and download its log. Every prompt it receives is published on the prompts page.
• Tapoo Oracle - dmigwi.github.io/tapoo-oracle: load a log and get its profile against the Tapoo Agentic Behavior Rubric (source).

Tapoo runs entirely in your browser, with no Tapoo server behind it. Logs stay on your device: what leaves it is the context each turn sends to the model endpoint you configure, and a credential goes only to the endpoint it was entered for.

How it works

The uncertainty

The model is given a navigation challenge: find a target cell in a randomly generated maze. The maze has no cycles, exactly one success path that never changes once generated, and a variable number of dead-end branches. The model is never handed the full maze layout at once: each turn describes only the neighbourhood around it, so any wider map is one the model pieces together across turns. Alongside its current position, the target's position, the maze's dimensions and its traversal speed (below), each prediction request provides:

• its cell visit history, capped to within a Manhattan distance of 4 (the manhattanDistance setting)
• the outcome of its previous prediction
• the open exits from its current cell to the connected neighbouring cells

From that, it must derive its next moves: at least 1, with 2-4 suggested and no upper limit. Moves are applied in order until the first invalid one - a wall or out of bounds. There is no judge model and no self-reported success; every move is checked against the maze.

The open exits make the first move certain, while each one after it has to be deduced from context, and the odds of simply guessing right collapse - 33.33% for the second, 11.11% for the third, 3.70% for the fourth, and so on. The only way to improve those odds is to build a correct map of the surroundings from the context information available via the tool calls.

Why playing safe doesn't work

Playing safe means submitting one move per turn - the only move the model can be certain of. It never needs to guess, so it never hits a wall. It also never covers more than one cell for the decay unit that turn costs, which leaves no margin for error.

• The model starts with a budget of decay units equal to the number of cells in the maze. If the budget runs out before the target is located, the challenge is failed.
• A dead-end branch usually gives itself away only at its end, and walking back out costs as much as walking in - so every branch explored spends units the route itself will still need.

Each model is told its traversal speed - the new cells it was first to reach, divided by the decay units it was charged - and what it says about its chances of finishing: below 1.0000x is a backtracker, exactly 1.0000x a navigator, and above 1.0000x a trailblazer - the class with the strongest margin for surviving its own mistakes.

The Oracle decomposes that rate into three factors: route efficiency (new cells per applied move), batching (applied moves per turn), and accuracy (turns per decay unit). Their product is the rate the counted turns give, which is why a report shows it as an approximation of the stated speed. Route efficiency and accuracy can only be lost, never gained, so batching is the one factor that can carry the rate above 1.0000x: a flawless single-move agent cannot pass it.

Speed is the rate view of a run. Quantifying survival, below, is the budget view of the same turns - and the batching factor there is the same b, so the two decompositions share their middle term rather than competing.

The profile

Batching forces every model to act on its own reading of an uncertain maze map. Some build an accurate picture and batch confidently; some hallucinate walls or openings and act on them; some become so conservative they run out of budget. [Tapoo Oracle](https://dmigwi.github.io/tapoo- oracle/) scores the exported log against a rubric of capabilities and violations, kept separate rather than collapsed into a single scalar. A "no" means "not observed in this run", not "incapable". Runs are stochastic and every maze is unique, so a profile is a pattern across many attempts, not a verdict from one run.

Quantifying survival

Every turn ends in exactly one state. The model chooses the moves, the maze decides which apply, and the charge follows from that outcome:

Two consequences drive everything else. A no-progress turn charges exactly what clean progress charges, so standing still is invisible to every other check: not a violation, no error debt, and it looks like success. And a clean turn charges 1 decay unit however far it travels, which is what makes batching valuable and retreating out of a dead end affordable.

One charge, two opposite meanings. A no-progress turn is a retreat when every cell it entered reads backtracking or explored - legitimate, and required by the prompt once a dead end is confirmed - and an oscillation when a cell reads oscillating, which is a rubric violation. The budget cannot tell them apart; visitStatus can, and any rate that pools them reports a violation where there was compliance.

The split separates runs that a pooled rate would call identical. Of DeepSeek's 301 no-progress turns, 294 are oscillations and 7 retreats. The earlier level 1 loss is the mirror image: 59 retreats, not one oscillation - it lost while doing exactly what the prompt asks of it.

The survival identity

Six figures, all read from one run's own log:

Three more are recomputed every turn:

A run finishes exactly when the budget covers what it spent:

moves / b  +  p  <=  A

headroom(b)  =  A - moves/b - p        decay units left when the run ends

Headroom is not a property of the run alone: the same route and the same errors give a different figure at every batch depth, so it means nothing quoted without its b. Subtracting D from A at the achieved depth splits it into three terms that each name a different cause:

headroom  =  (A - moves)   +   (moves - turns)   -      p
              route slack       batch credit       error debt

A model survives its own mistakes when route slack plus batch credit covers its error debt.

Required batch depth

Setting headroom(b) = 0 gives the depth a run needed to survive what its route cost and its errors spent:

b_min  =  moves / (A - p)

Applied moves are counted from the replay, including each run's deciding turn - which the log never reports directly, since a turn's outcome arrives with the next turn's tool calls and a winning turn has no successor. It is recovered by replaying that last prediction against the maze.

b_min < 1 means batching was never needed. That is true only of the level 1 run, whose 70-unit budget covered a 69-move route. Both level 54 winners had to batch. Holding each run's route and errors fixed and sweeping b:

                route slack   batch credit   error debt   headroom
GLM-5.3 L54         -15           258           117         +126   won
  at b = 1          -15             0           117         -132   would have lost

Gemma4 L54           -2           119             9         +108   won
  at b = 1           -2             0             9          -11   would have lost

Gemma4 L1             2             1             0           +3   won
  at b = 1            2             0             0           +2   would still have won

GLM-5.3 spent 117 decay units on mistakes and earned 258 of batch credit that paid for them. Gemma4 at level 54 spent 9 and still needed 119, because its route cost two units more than the maze has cells. Only at level 1, on a corridor with no branches to explore, did a model finish without batching at all. That is the claim stated per run, in decay units, and falsifiable: not "batching is good", but this model's errors cost this much and its batching earned that much, so it survived by the difference.

Route slack is negative on every level 54 run: each walked more steps than the maze has cells, because a dead end costs two steps per cell - one in, one out - and batching is what buys those steps back.

The point of no return

Batching into new ground and batching a retreat are bounded by different things. Pooled across all 2,184 turns of the eight runs profiled so far, new cells entered per turn:

new cells   0      1     2    3   4   >4
turns     562   1409   189   21   3    0

The first new cell is free - the current cell's openMoves names it. A second requires knowing the exits of a cell the model has never stood in, and those are never stated; they can only be deduced. A visited neighbour's openMoves says which walls that neighbour does not have, and the gaps narrow what the unvisited cell can be. Each further new cell pushes that elimination one cell deeper, and the only evidence for it is visited cells inside the history window

• so the chain of certain moves cannot outrun the window's reach. At a Manhattan distance of 4 it runs out after about four layers, which is where the distribution stops.

A retreat has no such bound: the window can hold 25 visited cells whose exits are already known, so Kimi K3 applied 7 moves in one turn to enter a single new cell.

Two constants follow, both observations with dates on them rather than properties of the game:

Neither is structural. The response schema sets minItems: 1 with no maximum, so a longer batch is permitted, and a chain forced by boundary walls could in principle deduce a fifth new cell.

So a verdict must count new route cells, never distance travelled. At turn t:

U > 4u   =>   unwinnable

U falls by at most 4 per turn and u falls by at least 1, so U/4 - u can never decrease. Once true, always true - monotone by construction rather than by luck, and verified on every turn of all eight runs.

Everything that fires earlier is a warning, because none of it is monotone:

The per-run pace fires earliest on DeepSeek, at turn 105 with 70% of its budget unspent, and flags no winner. It stays a warning because b is a running mean that can rise.

Eight runs is an observation, not a threshold, and both losses were 70-cell corridor mazes with zero route slack while three of the wins were level 54 - maze shape is confounded with outcome. The verdict also needs the decoded maze, so it is available to a reader after the run, never to the model during it.

Sampled Profiles

Every run behind the figures above. Each model name opens its live Oracle report; error debt is D - turns and decay left is A - D, both exact from the log. The app version and maze are listed because the same model under a different build or maze area is a different experiment - three Gemma4 runs appear here across three versions. Rows are ordered by app version.

* position at the halt; the run had not ended.

The error-debt column is where the framework earns its keep. DeepSeek and Kimi K3 carried debts of 16 and 22 decay units, lower than either GLM run, and neither finished; GLM-5.3 carried 117, the highest of any run, and finished first, because its batch credit of 187 more than covered them. What ended the two stalled runs was not mistakes but turns that bought no new ground. Every model that completed level 54 was still a backtracker; none reached 1.0000x.

Only the Apertus run carries an entries checksum, which exports gained in v2.6.2. The five level 54 logs (v2.5.1) and the two earlier level 1 runs (v2.4.8 and v2.6.1) predate it, so the Oracle verifies nothing on them.

Run it yourself

The live site above is the quickest way in. Tapoo also runs locally, and ships a Go terminal build of the maze without agent profiling - profiling is browser-only.

Terminal

go install github.com/dmigwi/tapoo@latest
tapoo

Run from source

go run .

Browser

make frontend-install
make frontend-build

Then serve public/ and open /index.html.

Docker

make docker-build
make docker-run

Then open http://localhost:5500/.

Gameplay Preview

make docker-build            # build the tapoo image
make docker-run              # serve it on http://localhost:5500
make docker-shell            # open a shell in the Docker build image

docker build -t tapoo .
docker run --rm -it -p 5500:80 tapoo

git submodule update --init --recursive

make help
make frontend-install
make frontend-quality
make frontend-build
make test
make ci
make docker-build
make docker-run

make go-bench        # Go maze generation only
make frontend-bench  # TypeScript maze generation only
make ci-bench        # both, with the cross-port parity check

make frontend-install

./scripts/install-hooks.sh

golangci-lint run

make ci

go test ./...
go test -race -covermode=atomic -coverprofile=coverage.out ./...
golangci-lint run

pnpm run typecheck:frontend
pnpm run lint:frontend
pnpm run test:frontend
pnpm run coverage:frontend

Project Layout

maze/          Go gameplay, rendering, persistence, and tests
frontend/app/  TypeScript SPA logic and tests
public/        Static site assets, HTML, CSS, images, and built JS
scripts/       Frontend build and hook helpers
tapoo-oracle/  Companion agent-log analyzer (git submodule)

License

This project is licensed under the Apache License 2.0. See LICENSE. Tapoo is distributed on an AS IS basis, without warranties or guaranteed support.