Command Palette

Search for a command to run...

Live, still measuring06.2025 – today

From 12 failed generations in every 100 to fewer than 1

AI generation fails for boring reasons: providers time out, jobs vanish, finished files never reach the user. We built a reliability layer that catches those failures, retries what can be retried, and refunds what cannot. At this volume, roughly 44,000 more generations reached the user instead of ending in failure.

Listen to the summary
Failures per 100 generations
12 → under 1
88.2% → 99.4% delivered
Failures avoided
~44,000
at measured volume
Generations scored
962,376
every run since Jun 2025, one classifier

Out of every 100 generation attempts

Each square is one generation. The dark ones failed to deliver a file to the user: a provider timed out, a job vanished, or a finished result never made it back.

12failed in every 100Old stack
1fails in every 100With the engine

The old stack lost about 12 in every 100. With the engine it is under 1. The engine does not make the models themselves better. It changes what happens when a provider fails, stalls, or loses a result.

Growth exposed how fragile the old stack was

Generation is a chain of things that can each go wrong independently: a provider queue backs up, a webhook never arrives, a file finishes but the app is never told. To the user, every one of those looks the same: nothing happened. The worst month on the old stack was February 2026, at 83.5% delivered, right in the middle of a growth spike.

Providers fail in different ways

Timeouts, refusals, malformed responses, and silent hangs each need a different recovery strategy. The old stack treated most of them the same way: stop and refund.

Completed work can disappear

Providers work asynchronously. If the completion signal is lost, the file may exist even though the app still thinks the job is running.

There was no shared definition of failure

Video, image, workflow, and voice recorded outcomes differently, so there was no honest baseline to argue from.

What the reliability engine actually does

It sits between the app and the providers, and it has one job: make sure every generation ends in a known state.

  1. Detects

    Notices when a generation has failed or simply stopped moving, instead of waiting for a user to complain.

  2. Classifies

    Decides what kind of failure it was: infrastructure, provider, or a deliberate moderation block. Each one deserves a different answer.

  3. Recovers

    Retries what is worth retrying, reroutes to another provider when one is having a bad day, and reclaims results that finished but never reported back.

  4. Resolves

    Refunds what cannot be recovered and records every final outcome the same way, so the number on this page means something.

What I left out of the headline number, and why

Every one of these is a switch in the explorer below, so you can put them back and watch the number move.

Moderation blocks are excluded
If a prompt is refused for content, the system did its job. Counting that as a failure would make safety look like breakage. Including them lowers both eras, and the gap barely moves.
Onboarding demos are not counted at all
They replay a fixed template instead of running a model, so they are not generations. They are out of the dataset entirely, not just filtered off.
Deleted videos still count as successes
If a generation produced a file, it worked. Deleting your own video afterwards is a preference, not a system failure.

What is still not good enough

The remaining failures are not spread evenly. They cluster in a small number of legacy providers and older model configurations that have not been migrated yet. That is the next piece of work, and the explorer below will show it the moment it improves, or does not.

A note on the numbers: the headline compares the eras before and after launch, and skips May 2026 because the engine launched partway through that month. The large figure below summarises the full selected range, transition included, so the two will differ.

93.5%

962,376 generations in this view · 5 Jun 2025 → 31 Aug 2026

88.2%

Before the engine
Jun 2025 – Apr 2026

99.4%

With the engine
Jun 2026 – today

+11.2 pts18.7× fewer failures~43,881 failures avoided

Loading the interactive report: filters, chart views, and the full breakdown appear here.

Share of generations that delivered a file, by month, over all time. It started at 90.0% in Jun 2025 and sits at 99.4% in Aug 2026, a move of +9.4 points.

Method, so you can argue with it

  • One rule for all of history. Every row, old and new, goes through the exact failure classifier production uses today. Nothing is graded on a curve.
  • What counts as a generation. Every finished row across video, image, workflow, and voice: delivered, failed, or deleted. Runs still in flight are skipped.
  • What counts as success. The generation delivered a file to the user.
  • May 2026 is a transition month. The engine launched on 5 May, so May is excluded from the before/after headline. It still appears in every chart.
  • Failed videos are stored as deleted. The platform marks a failed video deleted after refunding it, so rows with no output plus an error breadcrumb are counted as failures, the same way the live dashboard counts them.

Generation health

Window
Jun 2025 – Aug 2026
Generations scored
962,376
Formats
4
Providers
11
Classifier
production's own

Sanitized by design. Product, repository, and PR names are removed on purpose. Every number on this page is real and was measured in production. Argue with the method below.