Wenn Sie Prompts über mehr als ein Modell testen, bricht die Kostenprognose in dem Moment zusammen, in dem Sie jede Anfrage wie einfache Chat-Token behandeln. Ein Team führt vielleicht kurze Text-Prompts auf gpt-5-mini aus, längere Evaluationsläufe auf claude-sonnet-4-6, Bildvarianten auf gpt-image-2 und dann vor dem Launch noch einige Video-Tests. Das ist nicht eine einzige Rechnungsform. Es ist ein Stapel aus unterschiedlichen Einheitentypen, Wiederholungsmustern und Freigabeschleifen.
Dieser Leitfaden gibt Ihnen einen praktischen Multi-Model-Prompt-Testing-Workflow für die Ausgabenprognose für AI-API-Nutzung, bevor der Traffic anzieht. Das Ziel ist am ersten Tag nicht perfekte finanzielle Genauigkeit. Das Ziel ist, Überraschungen in der Launch-Woche zu vermeiden, indem Prompt-Tests in ein kleines Prognose-Arbeitsblatt verwandelt werden, das Gründer, Operatoren und Engineering-Leads gleichermaßen lesen können.
Am Sonntag, dem 19. Juli 2026 beschrieb Flatkeys öffentliche Homepage das Produkt weiterhin als ausschließlich offizielle APIs, stündlich verifiziert, mit 160+ Frontier-Modellen hinter einem Schlüssel und einer OpenAI-kompatiblen Basis-URL unter https://router.flatkey.ai/v1. Auf der öffentlichen Preisseite stand außerdem weiterhin:
- jede Aufladung bringt Bonusguthaben:
+$3bei$10,+$8bei$20und+$100bei$200 - ein Guthaben kann über GPT-, Claude-, Gemini-, DeepSeek-, Bild-, Audio- und Video-Modelle hinweg routen
- die Nutzung wird nach Modell, Tokentyp und Anforderungsprotokollen gemessen
Diese Produktform ist wichtig, weil ein guter Prognose-Workflow nicht nur eine Preistabelle ist. Er braucht eine Live-Quelle für Modellzeilen, eine gemeinsame Guthabenansicht und Protokolle, die zeigen, wo Prompt-Tests tatsächlich Geld verbrennen.
The short answer
Verwenden Sie diese Reihenfolge:
- Teilen Sie die Prognose vor dem Preisvergleich in Text-, Bild- und Video-Lanes auf.
- Schätzen Sie den Prompt-Testing-Traffic getrennt vom echten Nutzungs-Traffic.
- Prognostizieren Sie pro Lane ein Baseline-Modell, ein Fallback-Modell und einen Multiplikator für die Freigabeschleife.
- Fügen Sie einen Puffer für Retries, Cache-Misses und abgelehnte kreative Inhalte hinzu, bevor Sie aufladen.
- Prüfen Sie die Live-Preisseite vor dem Launch erneut und setzen Sie dann Kontingentgrenzen fest, während Sie nach Traffic-Start die Anforderungsprotokolle überwachen.
Das ist der Kern des Multi-Model-Prompt-Testing-Workflows. Die meisten Teams überspringen Schritt zwei oder vier und sind dann überrascht, wenn ein scheinbar günstiger Benchmark in eine teure Freigabeschleife umschlägt.
Why most prompt testing forecasts fail
Gründer stellen meist eine einfache Frage: „Wie viel kostet dieses Modell, wenn wir es zum Launch einsetzen?“
Diese Frage ist zu allgemein. Eine nützliche Prognose muss fünf kleinere Fragen beantworten:
| Frage | Was sich dadurch ändert |
|---|---|
| Handelt es sich um interne Prompt-Tests oder um Anfragen echter Nutzer? | Das Testvolumen ist meist sprunghaft und wiederholend; Launch-Traffic ist gleichmäßiger und schwerer vorherzusagen. |
| Ist der Kanal Text, Bild oder Video? | Die Abrechnungseinheit ändert sich, sodass ein einziges gemischtes Sheet schnell irreführend wird. |
| Wie viele Varianten geben Sie frei, bevor eine Ausgabe live geht? | Kreative Review-Schleifen können die Ausgaben schneller vervielfachen als allein das Token-Wachstum. |
| Welches Modell ist der Standard und welches ist der Fallback? | Die Zuverlässigkeitsrichtlinie kann Ihre gemischten Kosten verändern, selbst wenn der Traffic konstant bleibt. |
| Welcher Prozentsatz der Anfragen wird voraussichtlich Retries, Cache-Misses oder Ablehnungen sein? | Hier bricht saubere Demo-Mathematik meist auseinander. |
Wenn Sie diese Fragen überspringen, haben Sie keine Prognose. Sie haben einen hoffnungsvollen Durchschnitt.
Der Quell-Snapshot vom Veröffentlichungstag
Der folgende Workflow verwendet nur öffentliche Flatkey-Oberflächen, erneut überprüft am Sonntag, 19. Juli 2026.
| Quelle | Geprüft am | Nützliche Tatsache |
|---|---|---|
https://flatkey.ai/ |
19. Juli 2026 | Die öffentliche Startseite sagt weiterhin nur offizielle APIs, stündlich verifiziert, einen Key und 160+ Frontier-Modelle. |
https://flatkey.ai/pricing |
19. Juli 2026 | Die öffentliche Preisseite sagt weiterhin, dass Top-up-Bonusguthaben dauerhaft ist, ein Guthaben Text/Bild/Audio/Video abdeckt und die Nutzung nach Modell, Token-Typ und Request-Logs gemessen wird. |
https://router.flatkey.ai/api/pricing |
19. Juli 2026 | Die öffentliche Pricing-API gab pricing_version: group-model-ratio-v1, 176 Zeilen, 175 Token-ähnliche Zeilen, 1 Festpreis-Zeile und unterstützte Endpoint-Familien für openai, anthropic, gemini, image-generation, openai-response, openai-video und video zurück. |
Die Live-Tafel der Homepage am 19. Juli 2026 zeigte außerdem Beispielpreise auf Eingabeseite, die für grobe Budgetierung im Textkanal nützlich sind:
| Modell | Öffentlicher Eingabepreis auf der Homepage |
|---|---|
gpt-5.5 |
$3.33 / M in |
claude-sonnet-4-6 |
$2.00 / M in |
gpt-5.4 |
$1.67 / M in |
claude-opus-4-8 |
$3.33 / M in |
deepseek-v4-flash |
$0.056 / M in |
Behandeln Sie diese als Beispiele vom Veröffentlichungstag, nicht als ewige Konstanten. Dies ist ein Forecasting-Artikel, daher ist der Prozess wichtiger als ein einzelner Preis-Tag.
Der Multi-Model Prompt-Testing-Workflow
Schritt 1: Test-Traffic vom Launch-Traffic trennen
Vermischen Sie interne Tests nicht mit öffentlichem Traffic. Ihr Prompt-Labor hat oft:
- mehr wiederholte Prompts
- mehr manuelle Wiederholungen
- mehr lange Prompts
- mehr abgelehnte Ausgaben
Launch-Traffic hat oft:
- kürzere oder stärker standardisierte Prompts
- gleichmäßigeres Volumen
- weniger manuelle Wiederholungen
- höhere Kontingentanforderungen
Beginnen Sie mit zwei separaten Tabellenblättern:
| Tabellenblatt | Zweck | Typischer Verantwortlicher |
|---|---|---|
| Forecast für Prompt-Tests | Experimente vor dem Launch, Modellvergleiche, Freigabeschleifen | Produkt, Ops, KI-Ingenieur |
| Forecast für Launch-Traffic | Erwartetes Nutzervolumen nach dem Release | Gründer, Finanzen, Engineering Lead |
Wenn Sie nur ein Tabellenblatt erstellen, wird Ihr Testbudget meist in Ihrem Produktionsbudget versteckt.
Schritt 2: Nach Modalität aufteilen, bevor Sie irgendeine Rechnung machen
Hier machen viele Teams den ersten echten Fehler. Text-, Bild- und Video-Workflows sollten nicht eine einzige einfache Spalte „Kosten pro Anfrage“ teilen.
| Lane | Primäre Einheit | Forecast-Treiber |
|---|---|---|
| Text-Prompts | Eingabe-Token, Ausgabe-Token, zwischengespeicherte Token | Prompt-Länge, Antwortlänge, Fallback-Rate |
| Bildgenerierung | modellspezifische Bildpreise plus Anzahl der erneuten Renderings | Konzepte pro freigegebenem Bild, Bearbeitungsschleifen, Auflösungsoptionen |
| Videogenerierung | Sekunden oder anbieterspezifische Generierungseinheiten | Cliplänge, erneute Renderings, Warteschlangenfehler, Freigabeschleifen |
Flatkeys eigene öffentliche Seiten unterstreichen diese Trennung. Die Preisseite sagt, dass ein Kontostand über Text, Bild, Audio und Video hinweg routen kann, aber das bedeutet nicht, dass eine einzige Forecast-Formel all diese Bereiche abdecken sollte.
Schritt 3: Die Testmatrix definieren, bevor die Kosten geschätzt werden
Ein echter Multi-Model Prompt-Testing-Workflow beginnt mit einer Testmatrix, nicht mit einer Preistabelle.
Verwenden Sie eine Tabelle wie diese:
| Lane | Ziel | Standardmodell | Fallback-Modell | Tägliche Tests | Freigabe- oder Wiederholungsfaktor |
|---|---|---|---|---|---|
| Text | Instruktionsqualität vergleichen | claude-sonnet-4-6 |
gpt-5.4 |
500 | 1.10 |
| Text | kostengünstiger Massen-Eval-Sweep | deepseek-v4-flash |
gpt-5-mini |
2,000 | 1.05 |
| Bild | kreative Konzepttests | gpt-image-2 |
zweites Bildmodell von der Live-Preisseite | 80 | 2.50 |
| Video | Prompt-Sweep für Launch-Trailer | Live-Videozeile von /pricing |
Backup-Videozeile von /pricing |
12 | 1.80 |
Der Punkt ist einfach: Prognostizieren Sie den tatsächlichen Workflow, den Sie ausführen werden, nicht eine Fantasie, in der jedes Modell genau einmal aufgerufen und immer akzeptiert wird.
Schritt 4: Zuerst mit der Basismathematik für die Text-Lane arbeiten
Bei Text-Prompts sollten Sie mit einer konservativen Schätzung auf Eingabeseite beginnen. Das ist schneller und reicht meist aus, um offensichtliche Budgetprobleme zu erkennen, bevor Sie ein vollständig detailliertes Token-Modell erstellen.
Baseline-Textformel
Baseline-Textausgaben
= Anfragen
× durchschnittliche Eingabe-Token
× Preis pro 1M auf Eingabeseite
÷ 1,000,000
× Freigabe- oder Wiederholungsfaktor
Beispiel 1: 500 tägliche Test-Prompts auf Claude Sonnet 4.6
500 Anfragen
× 1.800 Eingabetoken
× $2.00 / 1 Mio. Eingabe
÷ 1.000.000
× 1.10 Wiederholungsfaktor
= $1.98 Baseline-Eingabekosten pro Tag
Beispiel 2: 2.000 tägliche Low-Cost-Eval-Prompts auf DeepSeek V4 Flash
2.000 Anfragen
× 1.800 Eingabetoken
× $0.056 / 1 Mio. Eingabe
÷ 1.000.000
× 1.05 Wiederholungsfaktor
= etwa $0.21 Baseline-Eingabekosten pro Tag
Das ersetzt nicht die vollständige Token-Buchhaltung. Es dient als schneller Filter. Wenn die Baseline bereits zu hoch aussieht, wird auch die vollständige Prognose Ihnen nicht helfen.
Schritt 5: Fügen Sie die vollständige Textprognose erst hinzu, nachdem die Baseline bestanden hat
Sobald die Baseline akzeptabel aussieht, wechseln Sie zum vollständigen Token-Blatt.
| Variable | Bedeutung |
|---|---|
| uncached input tokens | Prompt-Token, die zum normalen Eingabesatz berechnet werden |
| cached input tokens | wiederverwendbarer Prompt-Kontext, der bei Unterstützung zum Cache-Satz berechnet wird |
| output tokens | generierte Token |
| fallback share | Prozentsatz der Anfragen, die an das Backup-Modell gesendet werden |
| retry factor | zusätzliche Durchläufe, verursacht durch Fehler, QA-Wiederholungen oder Prompt-Überarbeitungen |
Vollständige Textformel
tägliche Textausgaben
= Anfragen
× (
uncached input tokens × uncached input rate
+ cached input tokens × cache rate
+ output tokens × output rate
)
÷ 1.000.000
× retry factor
Flatkeys öffentliche Pricing-API ist hier nützlich, weil die Zeilenstruktur bereits separate Felder für tokenartige Kostenkomponenten offenlegt. Am 19. Juli 2026 zum Beispiel:
| Modell | Eingabeseitiges Feld | Ausgabeseitiges Feld | Cache-Feld |
|---|---|---|---|
gpt-5-mini |
0.02 |
8 |
0.12 |
claude-sonnet-4-6 |
1.5 |
5 |
0.1 |
gpt-image-2 |
3.325 |
6 |
0.251127819549 |
Verwenden Sie die Live-Zeile für das genaue Modell, das Sie testen. Leihen Sie sich nicht eine benachbarte Zeile aus, nur weil sie "nah genug aussieht".
Schritt 6: Prognostizieren Sie Bildtests als Freigabeschleifen, nicht als Einzeloutputs
Bildkosten sind der Bereich, in dem viele Betreiber zu knapp kalkulieren. Ein fertiges Bild kann mehrere abgelehnte Versuche verbergen.
Verwenden Sie dieses Arbeitsblatt:
| Eingabe | Beispiel |
|---|---|
| zu testende Konzepte | 20 |
| durchschnittliche Renderings pro Konzept | 3 |
| durchschnittliche Bearbeitungen pro genehmigtem Konzept | 2 |
| gesamte Bildoperationen | 100 |
| Live-Preiszeile | am Veröffentlichungstag aus /pricing abrufen |
| Puffer für abgelehnte Läufe | 15% |
Bildprognoseformel
Ausgaben für Bildtests
= gesamte Bildoperationen
× aktueller Preis des Bildmodells
× Ablehnungspuffer
Die wichtige Betriebsregel lautet: Fassen Sie Bildprognosen nicht in die Text-Token-Tabelle zusammen. Flatkeys öffentliche Seiten machen deutlich, dass ein Guthaben sowohl Text als auch Bild abdecken kann, Ihre interne Budgetplanung braucht jedoch weiterhin separate Approval-Loop-Mathematik.
Schritt 7: Video-Tests nach Dauer und Re-Render-Faktor prognostizieren
Beim Testen von Videoprompts wird das Unterschätzen noch leichter, weil jeder freigegebene Clip oft auf mehreren fehlgeschlagenen oder überarbeiteten Generierungen aufbaut.
Auf der öffentlichen Homepage, die am 19. Juli 2026 geprüft wurde, beschrieb Flatkey die Videogenerierung weiterhin als Abrechnung pro Sekunde über dasselbe Prepaid-Guthaben wie Textmodelle. Das bedeutet, Ihr Video-Arbeitsblatt sollte so aussehen:
| Eingabe | Beispiel |
|---|---|
| zu testende Konzepte | 6 |
| durchschnittliche Clips pro Konzept | 2 |
| durchschnittliche Dauer | 8 Sek. |
| Re-Render-Faktor | 1.8 |
| aktueller Preis pro Sekunde | in der Launch-Woche von /pricing abrufen |
Formel zur Video-Prognose
video test spend
= concepts
× clips per concept
× seconds per clip
× live per-second price
× rerender factor
Auch hier gilt: Video separat halten. Geben Sie nicht vor, ein Clip sei einfach nur eine weitere Anfrage in einem Textmodell-Blatt.
Schritt 8: Den Launch-Puffer vor dem Aufladen hinzufügen
Nachdem Sie die Testausgaben für Text, Bild und Video zusammengezählt haben, fügen Sie einen Launch-Puffer hinzu. Die am 19. Juli 2026 geprüfte Preisseite macht ausdrücklich klar, dass Flatkey im Voraus bezahlt wird und die Nutzung über Request-Logs gemessen wird. Das macht einen Puffer operativ nützlich und nicht nur finanziell ordentlich.
Verwenden Sie eine Puffertabelle wie diese:
| Risiko | Empfohlener Puffer |
|---|---|
| Text-Retries und Cache-Misses | 10% |
| Bildablehnungen oder zusätzliche Bearbeitungen | 15% bis 30% |
| Video-Re-Renders | 20% bis 40% |
| Unbekannte Faktoren in der Launch-Woche | 10% |
Wählen Sie dann einen Aufladebetrag, der zum Gesamtbetrag passt:
| Aufladeoption | Wert auf der öffentlichen Preisseite am 19. Juli 2026 |
|---|---|
$10 |
$10 zahlen, $13 Guthaben erhalten |
$20 |
$20 zahlen, $28 Guthaben erhalten |
$200 |
$200 zahlen, $300 Guthaben erhalten |
Für kleine Prompt-Labs lautet die richtige Frage nicht „was ist die günstigste Aufladung?“. Sie lautet: „Welche Aufladung hält die Testschleife in Bewegung, ohne mitten in der Launch-Vorbereitung einen Betriebsstopp zu erzwingen?“
Eine einfache Rechner-Tabelle, die Sie wiederverwenden können
Kopieren Sie dies vor jedem ernsthaften Prompt-Testzyklus in ein Sheet.
| Spur | Modell | Testvolumen | Einheitseinsatz | Preisquelle | Wiederholungsfaktor | Geschätzte Ausgaben |
|---|---|---|---|---|---|---|
| Text | Primärmodell | durchschnittliche Eingabe-/Ausgabetokens | Live-Preiszeile | |||
| Text | Fallback-Modell | durchschnittliche Eingabe-/Ausgabetokens | Live-Preiszeile | |||
| Bild | primäres Bildmodell | Operationen pro freigegebenem Asset | /pricing |
|||
| Video | primäres Videomodell | Sekunden pro freigegebenem Clip | /pricing |
|||
| Puffer | alle Spuren | Zwischensumme × Risikofaktor | interne Regel |
Wenn diese Tabelle unvollständig ist, ist auch Ihre Launch-Prognose unvollständig.
Was nach dem ersten Tag mit Live-Traffic geprüft werden sollte
Die Preisseite sagt, dass die Nutzung nach Modell, Tokentyp und Request-Logs gemessen wird. Das bedeutet, dass Ihre Überprüfung am ersten Tag folgende Fragen beantworten sollte:
- Welches Modell hat tatsächlich die meisten Anfragen verarbeitet?
- Entsprach der Fallback-Traffic dem erwarteten Anteil?
- Waren die Ausgabe-Tokens deutlich größer als die Testannahme?
- Welche Prompt-Familie erzeugte die meisten Wiederholungen?
- Waren die Freigabeschleifen für Bild oder Video teurer als die Textspur?
Genau diese Rückkopplungsschleife macht einen Multi-Model Prompt-Testing-Workflow zu einer wiederholbaren Praxis der Kostensteuerung statt zu einer einmaligen Tabellenkalkulation.
Häufige Fehler
| Fehler | Warum er schadet |
|---|---|
| Text und Medien zu einem einzigen Durchschnittspreis pro Anfrage zusammenzufassen | verschleiert die echten Treiber der Ausgaben für Bild und Video |
| nur das Standardmodell zu prognostizieren | ignoriert, was der Fallback mit der Rechnung macht |
| das Testvolumen so zu verwenden, als wäre es das Launch-Volumen | mischt internes Burst-Verhalten mit echtem Nutzerverhalten |
| Freigabeschleifen zu ignorieren | unterschätzt Bild- und Videokosten am schnellsten |
| ohne Risikopuffer aufzufüllen | führt zu vermeidbaren Unterbrechungen in der Launch-Woche |
FAQ
Sollte ich mit dem günstigsten Modell beginnen?
Nicht automatisch. Beginnen Sie mit dem Modell, das am besten zur Aufgabe passt, und testen Sie dann, ob ein günstigeres Modell einen Teil des Traffics übernehmen kann, ohne dass sich Wiederholungen, QA-Aufwand oder das Fallback-Volumen erhöhen.
Warum Medienkosten außerhalb des Token-Arbeitsblatts halten?
Weil Bild- und Video-Freigaben sich unterschiedlich vervielfachen. Ein Text-Prompt benötigt möglicherweise nur einen erneuten Versuch. Ein Videokonzept kann mehrere Renderings brauchen, bevor es jemand freigibt.
Wann ist die Prognose gut genug für den Launch?
Wenn Sie Folgendes haben:
- eine Baseline und eine vollständige Textschätzung
- separate Bild- und Video-Arbeitsblätter, wo relevant
- ein benanntes Fallback-Modell für jede wichtige Spur
- eine Entscheidung über das Guthaben im Voraus
- eine Quoten- und Nutzungslog-Prüfung für Tag eins vorbereitet
Wo sollte ich Modellzeilen vor der endgültigen Entscheidung vergleichen?
Nutzen Sie die aktuelle Flatkey-Preisseite für den aktuellen Routing- und Abrechnungskontext und vergleichen Sie dann benachbarte Optionen im bestehenden Leitfaden zum Vergleich der Preise von KI-Modellen. Die erste Seite hilft Ihnen beim Start. Die zweite hilft Ihnen zu entscheiden, welche Zeilen getestet werden sollten.
