Supabase Evals — Agent-Benchmark auf echtem Backend

Fortgeschritten

Coding-Agent-Leaderboards messen meist Pull-Request-Diffs gegen eine Test-Suite — SWE-Bench und seine Cousins. Das ist nützlich, aber es ist nicht, was ein Supabase-Nutzer wirklich tut: ein Schema bauen, eine kaputte RLS-Policy reparieren, eine gescheiterte Edge Function debuggen, Auth verdrahten. Am 1. August 2026 hat Supabase einen Benchmark open-source gestellt, der Coding-Agenten auf diesen echten Aufgaben bewertet und sie gegen tatsächliche containerisierte Supabase-Stacks mit echten MCP-Servern und echten CLIs laufen lässt. Er ist Apache-2.0, läuft lokal auf einem Laptop, und seine frühen Werte sagen schon etwas Überraschendes darüber, wie unterschiedliche Agenten Dokumentation nutzen. Diese Seite ist der praktische Feldführer dazu.

What you'll learn

• Verstehen, was Supabase Evals strukturell von SWE-Bench-artigen Benchmarks unterscheidet
• Die Cross-Agent-Ergebnisse ehrlich lesen — wo Opus 5, Sonnet 5, Kimi K3 und die GPT-5-Linie wirklich divergieren
• Den Effekt des Ladens von Skills auf demselben Modell sehen (vorher vs nachher)
• Den Benchmark selbst gegen deinen eigenen Agenten und dein Modell in unter einer Stunde ausführen

Zuletzt verifiziert: 2026-08-03.

Die Score-Tabelle, Eval-Anzahl und Skill-Effekte auf dieser Seite spiegeln das Leaderboard und README zum Release-Zeitpunkt vom 1. August 2026 wider. Live-Werte auf supabase.com/evals werden aktualisiert, wenn neue Modelle und Experimente hinzukommen; die Form des Benchmarks (echte Stacks, deterministisches + LLM-Judge-Scoring, ein Retry) ist dauerhaft, die konkreten Prozente nicht.

Bestätige anhand der offiziellen Quelle.

Was Supabase Evals wirklich ist

Supabase Evals ist Benchmark, Evaluation-Harness und öffentliches Leaderboard in einem Apache-2.0-Repo unter github.com/supabase/evals. Es existiert, weil SWE-Bench-artige Tests die falsche Frage für Backend-Arbeit beantworten — sie messen "kann dieser Agent ein eingereichtes GitHub-Issue gegen eine Python-Test-Suite schließen" — während die meiste echte Supabase-Arbeit näher an Ops auf einem laufenden System liegt: Deine RLS-Policy fing an, valide Requests abzulehnen, deine Edge Function macht 500 in Produktion, deine Migration ist nicht durchgelaufen.

Drei Dinge unterscheiden ihn von dem, was vorher kam:

• Echte Stacks, keine Mocks. Jedes Szenario bootet eine frische Docker-Sandbox, die den Host-Docker-Socket mountet, sodass supabase start den lokalen Stack als Geschwister-Container hochfährt. Der Agent redet mit einer Management-API-kompatiblen Oberfläche (@supabase/lite) und echten MCP-Servern und der echten Supabase-CLI. Nichts ist gestubt.
• Deterministische Prüfungen zuerst, LLM-as-Judge nur wo nötig. Ein Scorer kann die resultierende Datenbank abfragen, die deployte Edge Function anpingen oder vitest im Repo-Root auf den produzierten Dateien laufen lassen. Der LLM-Judge ist ein Backstop für Freiform-Antworten ("passte die Erklärung des Agenten zur tatsächlichen Root Cause?"), nicht die primäre Bewertung.
• Ein Retry, dann ist es final. Kein cherry-picktes Best-of-N. Das allein macht die Zahlen weniger schmeichelhaft als die meisten Agent-PR-Benchmarks.

Das Szenario-Raster

Der Release August 2026 liefert 38 Eval-Szenarien unter evals/<id>/ aus. Sie sind auf drei Achsen organisiert, damit Ergebnisse sinnvoll geschnitten werden können:

• Neun Produkte — database, auth, storage, edge functions, realtime, cron, queues, vectors, data-api
• Neun Themen — RLS, security, migrations, SQL, SDK, observability, self-hosting, tests, declarative-schema
• Vier Stages — build (etwas Neues bauen), deploy (ausliefern), investigate (herausfinden, was falsch ist), resolve (reparieren)

Jedes Eval ist ein Verzeichnis mit einer PROMPT.md (die Aufgabe, die der Agent sieht, plus Frontmatter-Metadaten), einem EVAL.ts-Scorer und optional remote/ (geseedeter Hosted-Project-Zustand — SQL, Logs, bereits deployte Functions) und local/ (Start-Dateien, die in den Sandbox-Workspace des Agenten kopiert werden). Die Szenarien kommen aus echten Support-Tickets und GitHub-Issues, nicht aus synthetischen Prompts.

Zwei Runtimes, pro Eval ausgewählt

Jedes Eval läuft in einem von zwei Modi, automatisch nach seiner Form entschieden:

• Tools-Modus. Keine Sandbox. Der Agent bekommt eine MCP/Tool-Oberfläche (Management API, SQL, Storage, etc.) und seine Antwort wird durch Inspektion des resultierenden Projektzustands bewertet. Für Evals, die vollständig innerhalb der Plattform leben (kein local/-Verzeichnis, kein interface: cli).
• Local-Stack-Modus. Eine frische Docker-Sandbox mit installierter echter Supabase-CLI. Der Agent bekommt ein bash-Tool plus Datei-Tools und kann supabase init/start/db/test gegen einen echten lokalen Stack ausführen, der als Geschwister-Container spawnt. Nachdem der Agent stoppt, docker cpt die Harness den Workspace heraus und lässt vite/vitest vom Host aus laufen, um zu bewerten. Für Evals, wo ein local/-Workspace existiert oder interface: cli deklariert ist.

Der clevere Teil: Die Toolchain des Hosts bewertet, was die Sandbox produziert hat. Scorer müssen nicht innerhalb des Sandbox-Images leben.

Cross-Agent-Ergebnisse (August 2026)

Die initialen Leaderboard-Läufe stellen First-Party-Agenten (Claude Code, Codex, Claude-API-Executor-Experimente) gegen den modell-agnostischen OpenCode über die Claude Opus 5, Claude Sonnet 5, Kimi K3 und GPT-5.4/5.6-Reihen. Die Zahlen unten sind für die build-Stage, wo der Initial-Post die schärfsten Ergebnisse berichtet.

Agent + Modell	Build (keine Skills)	Build (mit Skills)
Claude Code + Opus 5	100 %	100 %
OpenCode + Kimi K3	100 %	100 %
Claude Code + Sonnet 5	78 %	100 %
Codex + GPT-5.6 (Sol)	89 %	100 %
Codex + GPT-5.4 mini	78 %	89 %

Zwei Dinge stechen hervor:

• Opus 5 und Kimi K3 maxen build ohne Hilfe aus. Kimi K3 durch OpenCode, das Opus 5 durch Claude Code trifft, ist ein echtes Signal darüber, dass Open-Weight-Modelle bei backend-artiger Arbeit aufholen — keine generische SOTA-Behauptung, sondern eine spezifische, reproduzierbare.
• Skills sind ein großer Multiplikator auf kleineren/mittleren Modellen. Das Laden des Supabase-Skills bringt Sonnet 5 von 78 % auf 100 % bei build, und hebt die Hit-Rate des Postgres-Best-Practices-Skills von ~10 % auf 60 % über die breitere Suite. Wenn du Sonnet 5 (oder irgendein mittleres Modell) läufst, lässt du 20+ Punkte auf dem Boden liegen, wenn du den relevanten Skill nicht lädst.

Der Fund, den niemand erwartete: Modelle nutzen Docs sehr unterschiedlich

Die einzige interessanteste Zahl im Release ist kein Score, es ist ein Verhalten:

Codex / GPT-5.6 liest etwa 8 Docs-Seiten pro Szenario. Claude Code liest etwa 2 — und konsultiert Docs in unter 40 % der Szenarien, selbst mit geladenen Skills.

Die beiden Agenten starrten auf dieselben Aufgaben, dieselben MCP-Tools und dieselben Skills. Codex zieht reflexartig Dokumentation, bevor er handelt; Claude Code versucht öfter aus dem Gedächtnis und liest nur Docs, wenn er an eine Wand stößt. Keines ist "richtig" — Opus 5 durch Claude Code erreichte trotzdem 100 % bei build. Aber es ist ein sehr anderer Betriebsmodus, und er erklärt viele anekdotische Berichte darüber, dass sich die beiden Agenten unterschiedlich anfühlen.

★ Insight ─────────────────────────────────────

• Benchmark-Reports kollabieren einen Agenten meist auf eine Zahl. Supabase Evals ist ungewöhnlich wertvoll, weil er das Verhalten des Agenten instrumentiert — wie oft er Docs liest, welche Skills er geladen hat, wie viele Tools er aufgerufen hat — und dieses Verhalten ist oft die Geschichte, nicht der Score.
• Die Lücke hier ist keine Modelllücke, sie ist eine Harness-Policy-Lücke. Dasselbe Basismodell in einer anderen Harness würde sich wahrscheinlich anders verhalten. Siehe Coding Agent CLIs Compared für den Grund, warum die Harness mindestens genauso wichtig ist wie das Modell.
• Deterministische Scorer plus ein Retry (kein Best-of-N) ist, was die Zahlen hier über Agenten hinweg vergleichbar macht. Die meisten öffentlichen Agent-Leaderboards erlauben still Retries oder Self-Consistency, was langsamere/schwächere Modelle schmeichelt. ─────────────────────────────────────────────────

Drei konsistente Stolperfallen über jeden Agenten

Unabhängig vom Modell stolperte jeder getestete Agent über dieselben drei Muster:

• Migrations von Hand schreiben, statt deklarative Schemas zu nutzen. Der Deklarative-Schema-Workflow ist neuer; die Trainingsdaten sind schwer mit alten create table-Migrations, sodass Agenten standardmäßig auf diese zurückgreifen, selbst wenn das Projekt für deklarativ eingerichtet ist.
• Auth manuell verifizieren statt @supabase/server zu nutzen. Agenten verdrahten Cookie-Parsing und Session-Checking von Hand, statt die neueren serverseitigen Helpers zu nutzen, die genau dafür existieren.
• Inkonsistente Docs-Konsultation. Wie oben — derselbe Agent schlägt in einem Szenario Docs nach und versucht es im nächsten aus dem Gedächtnis, ohne offensichtliche Regel, welches wann.

Das sind die Art von Failures, die in pass@1 auf einem synthetischen Benchmark nicht auftauchen, weil es keine "falsche aber funktionierende" Antwort zum Bewerten gibt — der Code kompiliert, er nutzt nur das veraltete Pattern. Real-Container-Evals fangen sie, weil ein Scorer das produzierte Projekt inspizieren und prüfen kann "haben sie deklaratives Schema genutzt, ja/nein".

Ihn lokal ausführen

Du brauchst Docker, pnpm und einen API-Key für den Provider, den du bewerten willst. Ports 54321–54329 müssen frei sein (stoppe zuerst alle lokalen supabase start-Stacks). Das Ganze läuft auf einem Laptop; ein kleiner Lauf endet in Minuten.

Guided walkthrough1 of 5

1. Die Skills leben in einem Submodule — ein einfacher Klon lässt dich ohne die Supabase-Agent-Skills zurück. Nutz beim ersten Mal --recurse-submodules.

Repo mit Submodules klonen

git clone --recurse-submodules https://github.com/supabase/evals.git
cd evals
pnpm install
cp .env.example .env

Ein einzelnes Eval gegen ein einzelnes Experiment ausführen

pnpm eval -- \
--eval resolve-dataapi-001-empty-results \
--experiment claude-code-sonnet-5

Head-to-head: selbes Modell, Skills an vs aus

pnpm eval -- \
--experiment claude-code-sonnet-5 \
--experiment claude-code-sonnet-5-no-skills \
--suite benchmark

Voller Benchmark-Sweep über alle ausgelieferten Experimente

pnpm eval -- \
--suite benchmark \
--experiment-suite benchmark,no-skills

pnpm export-results
pnpm web

Anatomie eines Experiments (damit du dein eigenes hinzufügen kannst)

Eine Experiment-Datei unter experiments/<name>.ts ist, wo du einen Agenten, ein Runtime und ein Modell in eine vergleichbare Konfiguration verdrahtest. Diese Trennung ist absichtlich: Sie heißt "Claude Code mit Sonnet 5 und keinen Skills" ist ein anderes Experiment als "Claude Code mit Sonnet 5 und geladenen Skills", und beide sind anders als "OpenCode mit Kimi K3". Du kannst zwei der drei Achsen konstant halten und die dritte variieren.

Die -no-skills-Varianten, die im Repo ausgeliefert werden (z.B. claude-code-sonnet-5-no-skills.ts vs. claude-code-sonnet-5.ts), sind, was die Behauptung "Skills hoben uns von 78 % auf 100 %" messbar macht statt einer Stimmung.

Wenn du einen Custom-Agenten laufen lässt — eine hausgemachte Loop, ein interner Fork, eine experimentelle Harness — ist das Pattern: Schreib eine Experiment-Datei, die deinen Agenten deklariert, opte in localStack: localStackRuntime(), wenn du die Sandbox-Evals auch willst, und lass sie gegen die benchmark-Suite laufen. Deine Zahlen landen in derselben Tabelle wie die aller anderen.

Skills, faul geladen

Beide Runtimes nutzen progressive disclosure für Skills: Nur Name und Beschreibung jedes Skills sitzt jederzeit im System-Prompt; der Agent zieht die vollen Instruktionen bei Bedarf. Deshalb kostet "Skills an" nur ein paar Extra-Tokens pro Turn, kann aber einen Score um 20+ Punkte heben — der Agent zahlt für den Body eines Skills nur, wenn er entscheidet, dass der Skill relevant ist.

Die beiden Runtimes unterscheiden sich nur darin, wie der Body geholt wird:

• Local-Stack- (Sandbox-) Modus. Skills werden in die Sandbox mit Vercels skills-CLI installiert (im Sandbox-Image gebacken, aus dem lokalen skills/-Verzeichnis bezogen — nie aus dem Netz) unter .claude/skills/. Wenn eine Aufgabe passt, liest der Agent .claude/skills/<name>/SKILL.md und alle Dateien, die es mit seinen Datei-Tools referenziert.
• Tools-Modus. Kein Filesystem, also gibt ein load_skill-Tool die vollen Instruktionen eines Skills zurück, wenn der Agent es beim Namen aufruft.

Für Kontext zum aufkommenden Cross-Agent-Skills-Standard, den das nutzt, siehe SKILL.md as an Open Standard.

Wo das in der AILmanac-Karte passt

• Der Benchmark selbst → diese Seite. Was Supabase Evals misst, wie und was er fand.
• Evaluating Agents — das allgemeine Playbook zum Messen jedes Coding-Agenten auf deinem eigenen Stack.
• Coding Agent CLIs Compared — die Harness-Hälfte der Geschichte (Claude Code vs. Codex vs. OpenCode als Programme, unabhängig von jedem Benchmark).
• Claude vs GPT vs Gemini for Coding — die Modell-Hälfte.

★ Insight ─────────────────────────────────────

• Benchmarks wie dieser sind am nützlichsten direktional, nicht absolut. "Sonnet 5 gewann 22 Punkte mit geladenem Supabase-Skill" überträgt sich auf dein eigenes Projekt; "Sonnet 5 erreicht 100 % bei build" nicht notwendigerweise.
• Die richtige Frage nach dem Lesen eines Leaderboards ist nicht "welcher Agent gewann", sie ist "was testet dieser Benchmark, das meiner Arbeit ähnelt" — und dann zählen nur die Sub-Scores auf diesen Slices. ─────────────────────────────────────────────────

Kurzer Selbstcheck

Check yourself

0/5

1. 1Was macht Supabase Evals strukturell anders als SWE-Bench-artige Benchmarks?
2. 2Der Release August 2026 berichtet, dass Codex/GPT-5.6 und Claude Code sich in einem *Verhalten* bei denselben Szenarien scharf unterscheiden. Welchem?
3. 3Das Laden des Supabase-Skills hebt Sonnet 5s `build`-Score von 78 % auf 100 %. Was legt das am stärksten nahe?
4. 4Du willst 'Skills an' vs 'Skills aus' fair für dasselbe Modell vergleichen. Was ist das richtige Primitiv in Supabase Evals?
5. 5Welche Stolperfalle ist *nicht* eine der drei konsistenten Failures, die über jeden getesteten Agenten berichtet werden?

Flashcards

Drücke Enter oder die Leertaste, um die Karte umzudrehen. Nutze die Pfeiltasten links und rechts, um zwischen den Karten zu wechseln.Begriff angezeigt.

1 / 7

Quellen & weiterführende Lektüre

• github.com/supabase/evals — das Repo (Apache-2.0), inklusive der vollen README, aus der diese Seite schöpft.
• Introducing Supabase Evals — der Launch-Post mit dem initialen Cross-Agent-Leaderboard.
• supabase.com/evals — das Live-Public-Leaderboard.
• github.com/supabase/agent-skills — das Skills-Submodule, das der Benchmark pint.
• github.com/supabase/supabase-lite — @supabase/lite, die Management-API-kompatible Oberfläche, gegen die die Harness läuft.
• MarkTechPost — Supabase Releases Evals — Third-Party-Zusammenfassung der Launch-Findings.
• Verwandt auf AILmanac: Evaluating Agents · Coding Agent CLIs Compared · SKILL.md as an Open Standard.