The TSK-1 Benchmark: Nine AI Models Built the Same App in One Day (2026)

Every AI model launch comes with a benchmark chart, and every chart stops separating models within a couple of years. We decided to stop shopping for leaderboards and start grading the one thing a customer actually receives: a complete, running app. This is the methodology behind the TSK-1 benchmark hub: seven benchmarked model families, two fixed prompts, one setup, and an evidence trail behind every claim.

TL;DR: Every build test runs the same two fixed prompts. On Aug 1, 2026 nine AI models built the same app from the same prompt and three of the nine builds never opened; the cheapest made the best-looking app. Graded builds are written up per model with the day it was measured on the TSK-1 benchmark hub.

What Is the TSK-1 Benchmark?

The TSK-1 benchmark is the public evidence layer for TSK-1, the Taskade System Kernel: AI models build the same two real apps inside Taskade Genesis, and every build is graded on whether it opens, runs, and saves data correctly. TSK-1 is the kernel that coordinates models, memory, agents, and workflows; the benchmark shows what each model actually does under it. The methodology has its own wiki entry if you want the short reference version.

Most model comparisons are chart-shaped, which is exactly why they saturate. The full history of that cycle is in our history of AI benchmarks. TSK-1 takes the opposite shape: the evidence comes first. Every graded build is written up on its model page — what opened, what ran, what saved — with every claim linked to the day it was measured, and the hub's matrix distills those tiers into a plain 0-100 Intelligence Index. The full dataset lives on the hub, which also links live app kits built in Taskade Genesis you can open and clone.

We have run 19 recorded tests so far, between late July and late August 2026, published on the hub as 12 dated entries because several tests can land on the same day. Tests are not evenly sized. Some put a whole field of models through the same prompt on the same day, some are two-model re-runs on a single edit, and some exist purely to see whether a build that did not finish the first time would finish on a second pass. That last kind matters more than it sounds, and we come back to it below.

Why Build Real Apps Instead of Fixing Bugs

Most benchmarks grade narrow work: SWE-bench grades bug-fix patches on existing code, Terminal-Bench grades command-line puzzle tasks, and Aider-style tests grade code edits. TSK-1 grades the full product: a complete app that opens, runs, and accepts a real form submission that lands field by field in your workspace.

That distinction matters because a model that fixes a bug has changed one function, while a model that builds an app has shipped a product. Products fail in ways patches never can: they do not open, they save the wrong fields, or they silently build the wrong app entirely. The grading follows the same spirit as evals and agent evaluation: judge the finished app, not the demonstration.

The last column is the honest one. TSK-1 is not better than SWE-bench at what SWE-bench does; a patch benchmark is the right instrument for patch work. It is a different instrument for a different question, and the question got commercially urgent the moment "describe an app and get one" became a normal way to work.

The Fixed Prompts: A Tracker and a 32-Question Client Sign-Up Form

Every test runs the same two never-reworded prompts: a tracker for match statistics, and a real customer's 32-question client sign-up form, with instructions not to shorten it. Models may not shorten, reorder, or reword it, and we grade how faithfully each question survives into the finished app.

The prompts never change because a benchmark only measures what is held constant. The tracker exercises real app structure: entities, relationships, filters, and views. The sign-up form exercises how closely a model sticks to what it was given: 32 questions that all have to survive into the finished app, and an instruction the models are not allowed to dodge. If you want to start from a close shape, clone a form template or a gaming tracker template and describe your own version to Taskade Genesis.

A note on the second prompt. It comes from a real customer, and the prompt text is not published. The customer stays anonymous, and the wording stays private. Two reasons. The first is consent: somebody's real sign-up form is evidence of how they work, not something to reprint. The second is methodological. A published prompt is a prompt that leaks into training data, and a benchmark whose hardest task can be memorised has a shelf life measured in weeks. What we publish instead is the shape: 32 questions, the instruction not to shorten, and the field-by-field check the submitted answers have to survive. That is enough to write an equivalent prompt of your own, and it is what the "built what was asked for" score is actually measuring.

Nine Models, One Prompt, Same Day

Aug 1, 2026 was the cleanest all-in test: nine models, the same prompt, and 3 of 9 builds never opened. The cheapest of the nine made the best-looking app — DeepSeek V4 Flash delivered a coherent light and dark theme, nothing broken on the page, and a clean layout at 390 pixels wide on a phone.

Three failure modes separated in that single test, and naming them is most of what the benchmark is for. Gemini 3.6 Flash did not place: the build it turned in would not open, because it referenced 3 pieces of code it never created, and it shipped with no theme and a hardcoded local address. GPT-5.6 Sol shipped an unrequested login screen — twice, on Jul 30 and again on Aug 1, 2026 — and never mentioned it. GLM-5.2 met the same ambiguity and went the other way: it thought it through, declined to add the screen, and offered "Add Login" as a suggestion instead (Jul 30, 2026). Same prompt, same gap in what was asked for, three different behaviours.

That test also produced its quietest result. Claude Opus 5 turned in the fullest write-up of its own work we have measured: the richest workspace integration of the nine, and the most complete agent knowledge loop. That is not a score, which is exactly why a scoreboard would have lost it. The full nine-model run, including the DeepSeek design story, is on the hub.

The Evidence Ladder: What Gets Graded

Every build climbs five gates in order: does the finished app open and run, do its colours hold up, does a form submission really save field by field, was it even the app that was asked for, and evidence-only grading on top. Sample sizes stay honest at 1-3 builds per model per test, so findings are directional.

The third gate is the piece no code-level benchmark can produce. It grades whether your data really saves into Workspace DNA rather than what the page happens to render. That is the LLM-as-a-judge idea applied to a real app: a rubric checked against a result you can verify, not a vibes score.

Gate three is also the one that changed our minds most. On Aug 3, 2026, DeepSeek V4 Flash got the whole path right: form submitted, values landed in the right fields, the project version bumped, and an AI assistant could then answer questions about the record that had just been saved. Four separate things had to be true for that to work, and only the last one is visible on screen.

Here is the same ladder as we actually run it, one build at a time:

  PROMPT (never reworded)
      |
      v
  [ BUILD ]  the model builds the app
      |
      +--> saved  ---------------------------> stored, hashed, linked
      |
      v
  [ OPEN ]   does the finished app open ?
      |                    \__ no  -> did not place (Aug 1: 3 of 9 builds)
      v
  [ COLOUR ] do light and dark both hold up ?
      |                    \__ no  -> capped   (Aug 2: 2 of 5 builds rejected)
      v
  [ PERSON ] fill 32 fields -> submit
      |
      v
  [ CHECK ]  what was typed in  ==  what got saved ?
      |        field 01 .. field 32     <-- the gate no screenshot can pass
      |                    \__ no  -> your data did not save
      v
  [ SCOPE ]  is this the app that was asked for ?
      |                    \__ no  -> wrong-app cap (Aug 3)
      v
  PUBLISHED  -> written up on the model page + dated evidence

What the Tests Found

Across every test from late July to late August 2026, no model won everything. GPT-5.6 Luna built what was asked for most closely, DeepSeek V4 Flash made the best-looking apps, Claude Sonnet 5 wrote the cleanest code, GPT-5.6 Terra was fastest, and DeepSeek V4 Pro wired up the most data. A different winner on every measure the benchmark grades.

The capsules, in order of what they teach:

• GPT-5.6 Luna builds what was asked for more closely than anything else we have measured: it echoed all 32 questions of the customer's sign-up form word for word from Aug 3 to Aug 19, 2026, and it is the only model that builds a real scoring grid into its output — a 33-by-5 grid that writes its scores back into your workspace (Aug 7, 2026). On Aug 8, 2026 it was also the only model to write its own design rationale, at 32 of 32 questions word for word on both builds. On Aug 4, 2026 it produced the best sign-up-form build we have measured: it ran straight through, and a human judge called it "beautiful."
• GPT-5.6 Terra is the fastest: quickest finish in nearly every test it entered, 8 minutes 26 seconds on Aug 7, 2026, and the first build where every stage worked — build, form submit, data saved and read back, automation run, and a chatbot answering from it, 5 of 5 stages. It also carries the best comeback we have measured: 0 of 4 builds word for word across three tests running (Aug 3 to Aug 6, 2026), then 32 of 32 questions on both builds on Aug 8, 2026 with a setting that carried its context forward. Speed without accuracy is worth nothing, and Terra spent three tests proving it before fixing it.
• DeepSeek V4 Pro holds the record for the most data wired into one build: 8 automations and 60 fields, at 4 of 4 builds word for word (Aug 6, 2026). On Aug 5, 2026 it won the tracker test outright as the cheapest app that actually opened, after the opening check overturned what the raw numbers said. On Aug 2, 2026 it posted the biggest single-test improvement we have measured, going from 0 of 4 builds to 4 of 4 builds word for word on the minimal setting. Like its Flash sibling, it is an open-weight model.
• DeepSeek V4 Flash is the value finding, and it keeps re-winning. Best-looking app on Aug 1, 2026 at a fraction of the field's cost. Best-looking app again on Aug 2, 2026, this time with the data really saving: 11 files, colours holding up throughout. Cheapest, fastest, and cleanest run on the real customer sign-up form on Aug 3, 2026, finishing in 12.6 minutes. Cheapest 32-field sign-up form by a wide margin on Aug 7, 2026.
• Claude Sonnet 5 writes the cleanest code we have measured (Aug 3, 2026) and was the only model to check its own generated agent by asking it questions (Jul 30, 2026) — a self-check nothing else in the field performed. The honest note: on Aug 3, 2026 one of its builds lost the customer's wording partway through and delivered a customer database instead of the sign-up form, and on Aug 6, 2026 its sign-up form did not finish at all. That is why we grade whether a build survives to the end, not only whether it is correct when it does.
• Claude Opus 5 made the best-looking build of any test we have run (Jul 30, 2026), and the fullest write-up of its own work among the nine models tested on Aug 1, 2026.
• Claude Haiku 4.5 caught a fatal display error during its own build and fixed it before declaring done (Jul 31, 2026) — the only model in that test to repair something that would have stopped the app opening. Exactly the signal the opening check is designed to surface.
• Kimi K3 had the fewest failed steps of that test at 7.2% (Jul 31, 2026), with the fewest steps overall and the most accurate closing summary of the day: honest claims about what it did and did not build, in an in-world voice. When AI is driving tools in a loop, how often those steps fail is the closest thing there is to a reliability floor.
• GLM-5.2 is the behavioural finding: on Jul 30, 2026 it thought it through and declined the unrequested login screen, offering it as a suggestion instead. The right behaviour under ambiguity. Its app first really saved data on Aug 1, 2026, where nothing had saved on Jul 30, with a cosmetic colour problem left as the open issue.
• MiniMax M3 is the reason reliability is a gate: on Jul 31, 2026, 47.2% of its steps failed, and it still summarised its work as "built and live" over its own record of what had gone wrong. The check that now compares what a model says it did against what it actually did was written because of that test.

The Four Measures: Who Leads What

The hub grades four things across the tested families: Design (does the finished app look right), Asked for (how closely it built what you described), Your data (whether the finished app really saves what people type into it), and Changes (can the model edit its own app afterwards without breaking it). Positions are directional across tests, not absolute scores.

Two families sit in the picker with tests pending rather than positions: Qwen and Grok. Their pages publish what the public record says instead, naming where each line came from and how recent it is, until TSK-1 evidence replaces it. A blank cell is more honest than a borrowed one.

Read down a column instead of across a row and the point of the whole thing appears. There is no column where one family wins by enough to justify standardising on it, and there is no family that wins every column. That is not a hedge — it is the measured result across 19 tests, and it is precisely why routing per task beats picking a favourite.

The Failure Classes the Benchmark Screens For

A finding is only useful if it repeats. Five failure classes have now recurred across tests, and each one earned a gate.

The last class is the uncomfortable one. A model that fails loudly costs you one more go. A model that reports success over its own record of what went wrong costs you the assumption that reports mean anything, which is the assumption every automated workflow is built on. Once you have seen it once, checking the work stops being optional — the same lesson the wider agent evaluation literature keeps arriving at from the other direction.

When a Build Does Not Finish

The single most instructive result we have is not a win. On Aug 3, 2026, Claude Sonnet 5's build lost the 32-question wording partway through and finished as a customer database instead of a sign-up form. On Aug 6, 2026 the same model's sign-up form did not finish at all. Neither result is a statement about Claude's capability. Both are statements about what a build looks like when it loses the thread halfway.

That is why the log carries entries most benchmarks would never publish. On Aug 19, 2026 a build that had not finished the first time went straight through on the re-run, in 280 seconds with no extra prompting. On Aug 20, 2026 we asked apps to make a change based on something said earlier, and none of the 31 attempts finished.

A benchmark that quietly drops the builds that did not finish reports a cleaner number and a less true one. Publishing them is how the wrong-app penalty came to exist in the first place — a build that loses the wording and carries on anyway is capped on customer impact no matter how polished the wrong app is, because from the customer's chair a beautiful customer database they did not ask for is a failed build.

Why This Matters for You

These findings are not academic, because automatic model routing uses exactly this kind of evidence to pick the model per task inside Taskade Genesis. You get 15+ frontier models from OpenAI, Anthropic, Google, and open-weight providers, and the benchmark shows which one wins which kind of work.

The practical translation is short. If your work is a customer-facing form whose wording has to survive word for word, read the Asked for column. If it is a pile of data with automations hanging off it, read Your data. If it is a design pass that has to look right on a phone, the Aug 1 and Aug 2, 2026 evidence says the cheapest option in the field is a serious candidate and not a compromise. And if your work is an agent driving tools in a loop, how often those steps fail is the number that decides whether the loop finishes.

Start from a prompt and the kernel routes the work. The same evidence you just read is what informs the route. Want to inspect it per family? Read the evidence pages for GPT, Claude, and DeepSeek on the hub, or let your AI agents handle it. Building an agent takes a prompt, wiring an automation takes another, and pricing starts free.

How We Keep It Honest

We publish 1-3 builds per model per test, directional evidence only, and every claim carries the day it was measured. Cost comparisons use relative ratios from comparable tests only, never per-model credit counts or dollar anchors. There are no fabricated aggregate ratings.

Three rules hold it together.

1. Honest sample sizes. Positions are evidence-graded across tests, not absolute rankings, and one strong test never becomes a title. The Aug 2, 2026 result — Pro going from 0 of 4 builds to 4 of 4 builds word for word in a single test — is exactly why: models move, and a snapshot presented as a final answer ages badly.
2. Dated claims. Every evidence claim on a model page carries the day it was measured, and the page will not publish if one of them points at a test that is not in the record. The rule is narrower than it sounds and we would rather say so: it binds the evidence cards, which is where the specific findings live. The summary lines above them are ordinary prose.
3. Cost discipline. Only comparable tests feed cost comparisons, and only as relative ratios. Early tests predate a billing change, so a cost average across all of them would be arithmetic on incompatible units.

Two things follow that are worth stating plainly. First, the order on the hub is deliberately coarse: each of the four measures is rated on four steps, and nothing finer. Models that come out level share a position rather than being separated by a decimal that would not mean anything, because averaging a design finding against an app that would not open produces false precision. Second, a model that does not place is not judged forever: Gemini's Aug 1, 2026 result and its Aug 3, 2026 result are both published, in that order, because the recovery is as much a finding as the failure was. The full log is on the hub.

Frequently Asked Questions

Related Reading

• TSK-1 (Taskade System Kernel) — the kernel the benchmark evidences
• TSK-1 Benchmark — the short reference version of this methodology
• The History of AI Benchmarks — why every leaderboard eventually saturates
• Agent Evals, Explained — grading agents on outcomes instead of transcripts
• 10 Best Open-Source LLMs — where the open-weight families in this test sit
• Evals and LLM-as-a-Judge — the two ideas the ladder is built on
• Workspace DNA — where the field-by-field check actually lands

Stop reading leaderboards. Read the evidence. Every model page, every test, and every dated claim is on the TSK-1 benchmark hub. Then describe your own app and watch it get built. No code. No setup.

See the evidence → · Build your next app → · Clone a live one →

▲ Memory feeds Intelligence. ■ Intelligence triggers Execution. ● Execution creates Memory. Nine models, one prompt, one loop, and an app at the end of it that keeps running after the build does.