Unsere KI-Content-Pipeline läuft auf GPT-5.6 — und erzeugt weniger Bilder als früher
Jeder Text-Prompt in der Green Yoga Inc Content-Pipeline zielt jetzt auf GPT-5.6 ab. Dieser Teil ist eine Änderung pro Datei in einer Zeile. Der erwähnenswerte Teil ist das, was mit der Bildgenerierung passiert ist, die wir vollständig aus der Pipeline entfernt haben.
Wo das Modell tatsächlich ausgewählt wird
Prompts liegen in ai-prompts/ als einfache Textdateien mit einem Header vor, niemals als String-Literale im Lambda-Quellcode. Es gibt heute 19 davon, plus ein JSON-Manifest für einmalige Bild-Batches. Fünfzehn tragen MODEL: gpt-5.6.
Zwei tun das absichtlich nicht:
21-content-translation.txtbleibt aufgpt-5.4-mini. Es übersetzt die Website in acht Sprachen, und es ist der eine Arbeitsbereich, bei dem Volumen wichtiger ist als der letzte Qualitätszuwachs. Eine vollständige Neuübersetzung von allem kostet etwa zehn Cent.- Die drei
gptimage-*-Promptdateien tragen überhaupt keinenMODEL:-Header, weil die Lambda sie inzwischen an nichts mehr an OpenAI sendet. Mehr dazu weiter unten.
Beide Lambdas — ai-content-engine und yoga-script — lösen alles, was der Header sagt, über normalizeModel() auf:
function normalizeModel(raw?: string): string {
if (!raw) return "gpt-5.6";
// Legacy GPT-5.x ids -> current flagship
if (m === "gpt-5" || m === "gpt-5.1" || ... || m === "gpt-5.5" || m === "gpt-image-1.5") {
return "gpt-5.6";
}
if (m === "gpt-4o" || m === "gpt4o") return "gpt-4o";
return m;
}
Jede ältere ID — gpt-5 bis gpt-5.5 und das alte gpt-image-1.5 — wird zu gpt-5.6 zusammengezogen. Eine Promptdatei, die seit sechs Monaten niemand angerührt hat, kann keinen veralteten Endpoint aufrufen; sie erhält stillschweigend stattdessen das aktuelle Flaggschiff. gpt-4o und gpt-4o-mini werden unverändert durchgereicht, weil ein Codepfad gpt-4o weiterhin bewusst benötigt.
Beide Lambdas sprechen mit Chat Completions
Die Textgenerierung geht von beiden Lambdas an POST /v1/chat/completions. Wenn Sie unseren Beitrag von April lesen, ist das eine Umkehr: Wir hatten auf die Responses API konsolidiert. Wir sind zurückgewechselt. Chat Completions ist die langweilige, gut verstandene Oberfläche für das, was diese beiden Funktionen tatsächlich tun: einen System-Prompt und einen User-Prompt entgegennehmen und Prosa zurückgeben.
Das Einzige, was noch POST /v1/responses aufruft, ist scripts/generate-pose-images.mjs, ein von Hand von einem Arbeitsplatzrechner ausgeführtes Entwickler-Skript. Es verwendet das image_generation-Tool auf gpt-5.6 mit 1024x1024. Das ist ein lokaler Batch-Job, kein Browser-Traffic, und er ruft OpenAI absichtlich direkt auf.
Der Yoga Sequence Builder kalkuliert seine eigene Zeit
Der Yoga Sequence Builder erzeugt Lehrskripte über die yoga-script-Lambda, gesteuert von 05-yoga-script-generator.txt auf GPT-5.6. Die Skripterzeugung ist langsam und schwankt, also verbringt die Lambda den größten Teil ihrer Logik mit Arithmetik statt mit Prompting:
- ein einzelner Hauptversuch ist auf sieben Minuten begrenzt, damit ein langsamer Aufruf nicht die gesamte Ausführung auffrisst
- 25 Sekunden werden am Ende reserviert, um eine Antwort zu serialisieren und zurückzugeben
- ein
gpt-4o-Fallback existiert, wird aber nur ausgeführt, wenn noch mindestens zwei Minuten Puffer verbleiben
Diese letzte Regel ist die, die zählt. Wenn der Hauptversuch spät fehlschlägt und nicht mehr genug Zeit bleibt, verweigert die Lambda den Start des Fallbacks und gibt stattdessen einen expliziten Fehler zurück — Skipping gpt-4o fallback: insufficient Lambda time remaining. Einen Aufruf zu starten, den man nicht beenden kann, verwandelt nur einen klaren Fehler in ein Timeout, und das ist beim Debuggen eindeutig schlechter.
Wir haben aufgehört, Bilder automatisch zu erzeugen
Das ist die eigentliche Änderung seit April.
generateImage() in ai-content-engine ist jetzt ein No-op-Stummel. Die Funktion nimmt ihre Argumente entgegen, ignoriert sie und gibt das Fallback-Cover zurück:
/** Kept as a no-op stub for callers that still reference it directly. */
async function generateImage(imagePrompt: string, s3Key: string): Promise<string> {
void imagePrompt;
void s3Key;
return FALLBACK_COVER_IMAGE;
}
Was es ersetzt hat, ist kein anderes Modell. Es ist eine Person. generateOrReuseImage() schreibt den Bild-Prompt mit einem leeren S3-Key in DynamoDB und gibt das Fallback zurück, und die Freigabe-E-Mail leitet diesen Prompt an einen Menschen weiter. Wenn die Antwort mit angehängtem Bild zurückkommt, füllt eine separate media-receiver-Lambda das echte Asset aus.
Der Prompt wird als drei separate Felder gespeichert — clipL, t5xxl und negative — statt als ein einzelner Blob, weil die Person, die ihn rendert, in der Regel nicht OpenAI verwendet. Das sind Prompt-Slots für Diffusionsmodelle, und sie getrennt zu halten bedeutet, dass der Bediener jedes Feld direkt in das richtige Eingabefeld einfügen kann, statt einen zusammengefügten String auseinanderzunehmen.
Warum eine langsamere Pipeline die richtige Pipeline ist
Die automatische Cover-Generierung war die Funktion, die am ehesten etwas Peinliches auf die Website bringen konnte, ohne dass es vorher jemand sieht. Text läuft bereits durch eine Freigabe-E-Mail. Bilder taten das nicht — sie wurden generiert, hochgeladen und in einem unbeaufsichtigten Durchlauf veröffentlicht.
Das Entfernen dieses Schritts hat das Publizieren zwar langsamer gemacht. Es bedeutet auch, dass jedes Bild auf dieser Website vor der Veröffentlichung von einem Menschen angesehen wurde, und genau das war die Eigenschaft, die wir eigentlich wollten. Das Modell wurde besser und wir haben ihm weniger zu tun gegeben, ohne Aufsicht. Das steht nicht im Widerspruch.
Prompts liegen in ai-prompts/; die Lambdas befinden sich in lambda/ai-content-engine und lambda/yoga-script. Wenn Sie Hilfe beim Entwerfen eines Freigabe-Workflows für Ihre eigene KI-Content-Pipeline möchten, melden Sie sich.
