| Ja. Das ist die richtige Frage. |
|
|
| Die eigentliche Kunst ist **nicht** “einen guten Prompt schreiben”. |
| Die eigentliche Kunst ist, **Task, Harness und Modell getrennt zu denken**. |
|
|
| Viele machen stillschweigend diesen Fehler: |
|
|
| * sie schreiben **einen** Prompt, |
| * werfen ihn in irgendein Harness, |
| * wechseln das Modell, |
| * und wundern sich, warum sich das Verhalten stark ändert. |
|
|
| Aber ein starker AI Engineer denkt in **drei Ebenen**: |
|
|
| ## 1. Die drei Ebenen, die du auseinanderhalten musst |
|
|
| ### Ebene A: Task Spec |
|
|
| Das ist die **objektive Arbeitsbeschreibung**. |
| Unabhängig von Modell und Harness. |
|
|
| Beispiel hier: |
|
|
| * lange PDF |
| * modularer Führungsleitfaden |
| * semantisches Chunking |
| * Subagents parallel |
| * lokale Summaries |
| * Cross-checks |
| * Konsolidierung |
| * finale Markdown-Datei |
| * Shell-Skript für PDF |
|
|
| Das ist der Teil, der **stabil** bleibt. |
|
|
| ### Ebene B: Harness Prompting |
|
|
| Das ist die Anpassung an die **Laufzeitumgebung**: |
|
|
| * Kann das Harness gut parallelisieren? |
| * Hat es echte Subagents oder nur sequentielle Tool-Loops? |
| * Kann es Dateien robust schreiben? |
| * Ist es eher chatty oder eher execution-first? |
| * Muss man Schreibzugriffe koordinieren? |
| * Ist es terminal-first, cloud sandbox, IDE-native? |
|
|
| Das ist **nicht** primär Modellprompting. |
| Das ist **Betriebssystem-/Orchestrierungs-Prompting**. |
|
|
| ### Ebene C: Model Prompting |
|
|
| Das ist die Anpassung an das **kognitive Profil des Modells**: |
|
|
| * Wie gut inferiert es fehlende Schritte? |
| * Wie stark halluziniert es elegante Übergänge? |
| * Wie viel Struktur muss man explizit vorgeben? |
| * Wie stark muss man Anti-Slop-Regeln setzen? |
| * Wie gut hält es lokale vs. globale Trennung? |
| * Wie gut kann es sich selbst verifizieren? |
|
|
| Das ist der Teil, der sich zwischen **Minimax**, **GPT-5.4** und **Opus 4.6** wirklich ändert. |
|
|
| --- |
|
|
| # 2. Was ist ein guter mentaler Frame? |
|
|
| Denk nicht: |
|
|
| > “Wie promptet man Modell X?” |
|
|
| Denk lieber: |
|
|
| > “Welche Fehler macht dieses Modell in diesem Harness auf diesem Task?” |
|
|
| Das ist viel näher an echter AI-Engineering-Arbeit. |
|
|
| Denn Prompting ist im Kern: |
| **Fehlerprävention durch Spezifikation.** |
|
|
| --- |
|
|
| # 3. Was sich beim Harness ändert |
|
|
| ## A. OpenCode |
|
|
| So wie du es beschreibst, nutzt du OpenCode als eher **ausführungsorientiertes Coding-Harness**, mit Möglichkeit, Arbeit in mehrere Subagents auszulagern und parallel laufen zu lassen. |
|
|
| Das heißt: |
|
|
| * du musst **Agent-Rollen sehr hart trennen** |
| * du musst **Artefakte** definieren |
| * du musst **Schreibkonflikte verhindern** |
| * du musst sagen, **wer was lesen darf** |
| * du musst sagen, **wer global synthetisieren darf und wer nicht** |
|
|
| OpenCode-Prompts sollten deshalb oft sein: |
|
|
| * stark workflow-orientiert |
| * datei- und artefaktzentriert |
| * explizit parallelisierbar |
| * mit klarer Ownership pro Agent |
|
|
| OpenCode ist also eher: |
| **“Agentenbetriebssystem prompten”** |
|
|
| als |
| **“schönen Text prompten”**. |
|
|
| ## B. Codex mit GPT-5.4 |
|
|
| OpenAI beschreibt Codex als Coding-Agent für Softwareentwicklung; es kann lokal oder in der Cloud arbeiten, und Codex ist explizit auf Software-Tasks, Codeverständnis und Delegation ausgelegt. OpenAI empfiehlt für die meisten Codex-Aufgaben mit `gpt-5.4` zu starten. ([OpenAI Entwickler][1]) |
|
|
| Für Codex ist der richtige Prompt meist: |
|
|
| * **weniger micromanaged** |
| * etwas mehr **outcome-oriented** |
| * trotzdem mit **klaren Deliverables** |
| * plus **Verification Loop** |
|
|
| Warum? |
| Weil GPT-5.4 stark in agentischen, coding-lastigen und professionellen Workflows ist und OpenAI für GPT-5.4 explizit Dinge wie Verifikationsschleifen, Structured Outputs und saubere Tool-Preambles empfiehlt. ([OpenAI Entwickler][2]) |
|
|
| Mit Codex musst du also weniger sagen: |
|
|
| * “bitte denke auch an Schritt 7b” |
|
|
| und mehr: |
|
|
| * “das sind die Deliverables, das sind die Qualitätsgates, das ist die erlaubte Arbeitsweise, das ist der Verifikationsrahmen”. |
|
|
| Codex/GPT-5.4 ist oft stärker, wenn du ihm: |
|
|
| * Zielzustand, |
| * Constraints, |
| * Prüfkriterien, |
| * Artefaktstruktur |
|
|
| klar gibst, aber nicht jede Mikroentscheidung erdrückst. |
|
|
| ## C. Claude Code mit Opus 4.6 |
|
|
| Hier spreche ich jetzt bewusst als Engineering-Inferenz, nicht als zitierte Produktspezifikation: |
|
|
| Ein Claude-Code-artiges Terminalharness wirkt typischerweise am besten, wenn du ihm: |
|
|
| * **grobe Richtung** |
| * **starke Prinzipien** |
| * **wenige, aber harte Qualitätsregeln** |
| * **klare Arbeitsphasen** |
| * **Review-/Plan-Disziplin** |
|
|
| gibst. |
|
|
| Warum? |
| Weil solche Modelle in terminalnahen Coding-Setups oft sehr gut sind in: |
|
|
| * Codebase lesen |
| * Plan bilden |
| * große semantische Bögen halten |
| * brauchbare Refactors und Synthesen formulieren |
|
|
| Aber sie neigen eher dazu, |
|
|
| * zu viel global zu denken, |
| * zu früh zu synthetisieren, |
| * Dinge elegant zu glätten, |
| * und lokale Grounding-Grenzen zu überschreiten. |
|
|
| Für Opus-artige Modelle ist daher oft wichtig: |
|
|
| * **weniger Prozessbürokratie als bei schwächeren Modellen** |
| * aber **starke epistemische Regeln** |
| * also: “erfinde nichts, markiere Unsicherheit, halte lokale und globale Ebenen getrennt”. |
|
|
| --- |
|
|
| # 4. Was sich beim Modell ändert |
|
|
| Jetzt zum Kern. |
|
|
| ## Minimax M2.7 |
|
|
| Aus deinem Experimentbild heraus würde ich Minimax so behandeln: |
|
|
| **Stärken** |
|
|
| * schnell |
| * produktiv |
| * kann gute Makrostruktur simulieren |
| * kann erstaunlich starke zusammenhängende Texte bauen |
|
|
| **Risiken** |
|
|
| * wirkt überzeugender als es geerdet ist |
| * füllt Lücken mit plausibler Prosa |
| * macht aggressive narrative Glättung |
| * braucht härtere lokale Begrenzung |
| * braucht stärkere Fact-Check-Schicht |
|
|
| Deshalb muss der Prompt für Minimax: |
|
|
| * **expliziter** |
| * **enger** |
| * **rollenstärker** |
| * **anti-hallucination-lastiger** |
| * **stärker datei- und formatgesteuert** |
|
|
| sein. |
|
|
| Mit Minimax promptest du mehr wie: |
|
|
| > “Hier ist das Geländer. Hier sind die Wände. Hier darfst du laufen. Hier nicht.” |
|
|
| ## GPT-5.4 |
|
|
| OpenAI beschreibt GPT-5.4 als stark für agentische, coding-lastige und professionelle Workflows; die offiziellen Prompt-Guides betonen Verifikationsschleifen, Structured Outputs und Tool-Persistence, und OpenAI sagt, dass `gpt-5.4` in Codex für die meisten Aufgaben der sinnvolle Startpunkt ist. ([OpenAI Entwickler][2]) |
|
|
| Was heißt das praktisch? |
|
|
| GPT-5.4 braucht oft: |
|
|
| * **klaren Endzustand** |
| * **klare Prüfkriterien** |
| * **saubere Phasen** |
| * **weniger redundante Wiederholung** |
| * **weniger defensive Überinstruktion** |
|
|
| Es verträgt eher: |
|
|
| * “hier ist der Job, hier sind die Artefakte, hier sind die Qualitätsgates, arbeite sauber” |
|
|
| als |
|
|
| * 200 Zeilen Micromanagement. |
|
|
| Wenn du GPT-5.4 wie ein kleines Modell behandelst, schadest du oft: |
|
|
| * es wird schwerfällig, |
| * formalistisch, |
| * manchmal unnötig rigid, |
| * und verbringt zu viel Energie mit dem Befolgen des Metaprozesses statt mit dem Kernproblem. |
|
|
| Mit GPT-5.4 promptest du mehr wie: |
|
|
| > “Hier ist die Mission, hier ist der Qualitätsrahmen, zeig mir robuste Execution.” |
|
|
| ## Opus 4.6 |
|
|
| Für Opus-artige große reasoning/stylistic Modelle würde ich sagen: |
|
|
| Sie profitieren oft von: |
|
|
| * **Prinzipien** |
| * **Review-Disziplin** |
| * **hochrangiger Zieldefinition** |
| * **epistemischen Grenzen** |
| * **klaren Stop-Regeln** |
|
|
| Sie brauchen nicht unbedingt jeden Formatcontainer ausbuchstabiert, |
| aber sie brauchen sehr wohl: |
|
|
| * “nicht ausschmücken” |
| * “nicht psychologisieren” |
| * “keine historischen Schlüsse ohne Deckung” |
| * “keine globale Synthese vor lokaler Extraktion” |
|
|
| Mit Opus promptest du oft mehr wie: |
|
|
| > “Arbeite wie ein guter Senior Analyst mit starker Selbstdisziplin.” |
|
|
| --- |
|
|
| # 5. Das Entscheidende: derselbe Task, drei verschiedene Prompt-Stile |
|
|
| Jetzt wird es konkret. |
|
|
| --- |
|
|
| ## Prompt-Stil für Codex + GPT-5.4 |
|
|
| Hier würde ich **Outcome-first + Verification-first** prompten. |
|
|
| ### Charakter |
|
|
| * klar |
| * knapp |
| * professionell |
| * deliverable-orientiert |
| * mit Qualitätsgates |
| * nicht zu überfrachtet |
|
|
| ### Beispiel |
|
|
| ```text |
| Task: |
| Summarize the uploaded Heidelberg Castle guide into a source-faithful Markdown document that can later be rendered into a ~15-page PDF. |
| |
| Context: |
| This is not a linear book. It is a modular guide for castle tours with four top-level modules: |
| 1. History |
| 2. Architecture |
| 3. Personalities |
| 4. Cultural history |
| |
| Required workflow: |
| 1. Read the document structure and create a semantic chunk plan. |
| 2. Summarize each chunk locally before attempting any global synthesis. |
| 3. Run verification passes for chronology, person/title consistency, and architecture/building attribution. |
| 4. Merge the verified local summaries into a single coherent Markdown summary. |
| 5. Create a shell script that renders the Markdown to PDF. |
| |
| Deliverables: |
| - work/document_map.md |
| - work/chunk_plan.md |
| - work/local_summaries/*.md |
| - work/checks/chronology.md |
| - work/checks/persons.md |
| - work/checks/architecture.md |
| - output/summary_15_pages.md |
| - output/render_pdf.sh |
| |
| Quality bar: |
| - Source-faithful |
| - No invented facts |
| - No decorative filler |
| - Preserve uncertainty where the source is ambiguous |
| - Prioritize “key facts” sections from the source |
| - Final summary should reflect the source’s didactic structure, not flatten it into generic prose |
| |
| Before finalizing: |
| - verify dates |
| - verify ruler/person mappings |
| - verify building-to-builder mappings |
| - remove claims that are plausible but not clearly grounded in the source |
| ``` |
|
|
| ### Warum so? |
|
|
| Weil GPT-5.4 stark genug ist, den Workflow zu tragen, wenn du ihm gibst: |
|
|
| * Ziel |
| * Arbeitsweise |
| * Prüfkriterien |
| * Artefakte. |
|
|
| Du musst es nicht so stark “einsargen” wie Minimax. |
|
|
| --- |
|
|
| ## Prompt-Stil für Claude Code + Opus 4.6 |
|
|
| Hier würde ich **Plan-first + Principle-first** prompten. |
|
|
| ### Charakter |
|
|
| * etwas semantischer |
| * etwas analytischer |
| * mehr Betonung auf Denkdisziplin |
| * weniger auf starre Formatbürokratie |
| * aber mit starken epistemischen Regeln |
|
|
| ### Beispiel |
|
|
| ```text |
| You are producing a source-faithful analytical summary of a long Heidelberg Castle guide. |
| |
| This source is modular, not linear. Treat it as a structured teaching document, not as a conventional narrative book. Its top-level modules are history, architecture, personalities, and cultural history. |
| |
| Working method: |
| - First map the document structure. |
| - Then produce local summaries for semantically coherent sections. |
| - Do not jump to global synthesis early. |
| - After local extraction, perform explicit review passes: |
| - chronology |
| - person/title consistency |
| - building/builder attribution |
| - source faithfulness |
| - Only then write the final consolidated summary. |
| |
| Important rules: |
| - Do not invent transitions or historical motives. |
| - Do not turn plausible inferences into assertions. |
| - Do not smooth over ambiguities. |
| - Respect the source’s didactic emphasis, especially explicit key facts. |
| - Keep architecture, political history, and reception history distinct until the consolidation phase. |
| |
| Outputs: |
| - a document map |
| - a chunk plan |
| - local section summaries |
| - review notes |
| - a final ~15-page Markdown summary |
| - a shell script to render it to PDF |
| |
| Write densely and clearly. Prefer precision over flourish. |
| ``` |
|
|
| ### Warum so? |
|
|
| Weil Opus-artige Modelle oft stark sind, wenn du ihnen: |
|
|
| * semantische Disziplin, |
| * epistemische Strenge, |
| * Review-Phasen, |
| * und klare High-Level-Prinzipien gibst. |
|
|
| --- |
|
|
| ## Prompt-Stil für OpenCode + Minimax M2.7 |
|
|
| Hier würde ich **Workflow-first + Guardrail-first + Subagent-first** prompten. |
|
|
| ### Charakter |
|
|
| * explizit |
| * streng modular |
| * harte Agententrennung |
| * formale Outputs |
| * Anti-Halluzinationsblock |
| * Anti-Slop-Block |
| * Parallelitätsregeln |
|
|
| ### Beispiel |
|
|
| ```text |
| You are running a multi-agent workflow. |
| |
| Goal: |
| Create a source-faithful 15-page Markdown summary of the Heidelberg Castle guide and a shell script to render it to PDF. |
| |
| This is a modular guide, not a linear book. |
| Primary modules: |
| 1. History |
| 2. Architecture |
| 3. Personalities |
| 4. Cultural history |
| |
| Agent roles: |
| - Orchestrator |
| - Structure agent |
| - Local content agents |
| - Chronology check agent |
| - Person/dynasty check agent |
| - Architecture check agent |
| - Merge agent |
| - Editor agent |
| - Build agent |
| |
| Hard rules: |
| - Local content agents may only use their assigned chunk. |
| - No agent may write to another agent’s file. |
| - Only merge/editor agents may create global synthesis. |
| - Any uncertain claim must be marked as uncertain. |
| - Any claim not clearly grounded in the source must be removed from the final summary. |
| |
| Required outputs: |
| - work/00_document_map.md |
| - work/01_chunk_plan.md |
| - work/02_local_summaries/chunk_*.md |
| - work/03_cross_checks/*.md |
| - work/04_global_outline.md |
| - output/summary_15_pages.md |
| - output/render_pdf.sh |
| |
| Anti-hallucination rules: |
| - no invented dates |
| - no invented motives |
| - no unsupported architectural labels |
| - no elegant filler |
| - no generic culture-language |
| - no importing facts across chunks during local summarization |
| |
| Parallel execution: |
| - run local content agents in parallel on independent semantic chunks |
| - run cross-check agents in parallel after all local summaries exist |
| - avoid shared write targets |
| ``` |
|
|
| ### Warum so? |
|
|
| Weil Minimax sonst mit hoher Wahrscheinlichkeit: |
|
|
| * zu früh global synthetisiert, |
| * zu viel selbst ergänzt, |
| * und dann sehr überzeugend falsch wird. |
|
|
| --- |
|
|
| # 6. Also: Wie muss der Prompt aussehen für welches Harness? |
|
|
| Hier ist die Faustregel: |
|
|
| ## Für Harnesses mit starker Agent-Orchestrierung |
|
|
| Prompt muss enthalten: |
|
|
| * Rollen |
| * Artefakte |
| * Zuständigkeiten |
| * Abhängigkeiten |
| * Parallelitätsregeln |
| * Merge-/Check-Phasen |
|
|
| ## Für Harnesses mit starkem Modell und guter Tool-Disziplin |
|
|
| Prompt muss enthalten: |
|
|
| * Ziel |
| * Constraints |
| * Deliverables |
| * Verification gates |
| * Stoppregeln |
|
|
| ## Für terminalnahe, planstarke Harnesses |
|
|
| Prompt muss enthalten: |
|
|
| * Zielbild |
| * epistemische Leitplanken |
| * Plan- und Review-Disziplin |
| * wenige harte Qualitätsregeln |
| * keine unnötige Prozessverstopfung |
|
|
| --- |
|
|
| # 7. Also: Wie muss der Prompt aussehen für welches Modell? |
|
|
| Noch kürzer: |
|
|
| ## Schwächer / glatter / riskanter schreibende Modelle |
|
|
| Mehr: |
|
|
| * Struktur |
| * Format |
| * Regelhaftigkeit |
| * Cross-checking |
| * harte Lokalität |
| * starke Negativregeln |
|
|
| ## Stärkere reasoning-heavy Modelle |
|
|
| Mehr: |
|
|
| * Zielklarheit |
| * Qualitätsgates |
| * epistemische Regeln |
| * weniger Mikromanagement |
| * mehr Verantwortung beim Modell |
|
|
| --- |
|
|
| # 8. Woher weiß man das? |
|
|
| Das ist die Kernfrage. |
|
|
| Nicht durch Magie. |
| Nicht durch “Prompting ist Kunst”. |
| Sondern durch **Eval-getriebene Modellierung**. |
|
|
| Du weißt es aus vier Quellen: |
|
|
| ## 1. Offizielle Dokumentation |
|
|
| Für GPT-5.4 und Codex ist das direkt nützlich: OpenAI dokumentiert, dass Codex ein Coding-Agent ist, für die meisten Codex-Aufgaben `gpt-5.4` der Startpunkt ist und GPT-5.4 gut mit Verifikationsschleifen, strukturierten Outputs und Tool-orientierten Arbeitsweisen harmoniert. ([OpenAI Entwickler][1]) |
|
|
| Das ist dein **Prior**. |
|
|
| ## 2. Harness-Verhalten beobachten |
|
|
| Du siehst in echten Läufen: |
|
|
| * wann das Modell zu früh synthetisiert |
| * wann es lokale Grenzen missachtet |
| * wann es Tool-Calls vergisst |
| * wann es in langen Tasks entgleist |
| * wann es zu chatty oder zu knapp wird |
|
|
| Das ist dein **Runtime-Profil**. |
|
|
| ## 3. Fehlerkataloge bauen |
|
|
| Für jedes Modell/Harness-Paar solltest du fast wie in einem Labor notieren: |
|
|
| * typische Halluzinationen |
| * typische Strukturfehler |
| * typische Tempo-/Kostenmuster |
| * typische Missverständnisse |
| * typische Stärken |
|
|
| Dann promptest du nicht mehr abstrakt, sondern gezielt gegen Fehler. |
|
|
| ## 4. Kleine kontrollierte Evals |
|
|
| Das ist der wichtigste Punkt. |
|
|
| Du machst nicht “große Gefühle”, sondern kleine Benchmarks: |
|
|
| * 5 ähnliche PDFs |
| * gleiche Task Spec |
| * drei Promptvarianten |
| * drei Modelle |
| * Score auf: |
|
|
| * Faithfulness |
| * Coverage |
| * Dedup |
| * Coherence |
| * Hallucination rate |
| * Time |
| * Cost |
|
|
| Dann siehst du: |
|
|
| * welches Modell mehr Freiheit verträgt |
| * welches Modell mehr Geländer braucht |
| * welches Harness welche Promptform am besten umsetzt |
|
|
| --- |
|
|
| # 9. Woher weiß *ich*, wie ich den Prompt schreiben muss? |
|
|
| Nicht sicher im absoluten Sinn. |
| Sondern durch eine Mischung aus: |
|
|
| * allgemeiner Agent-/Prompt-Engineering-Heuristik, |
| * beobachteten Fehlermustern, |
| * Dokumenttyp-Erkennung, |
| * und Anpassung an das wahrscheinliche Stärken-/Schwächenprofil von Modell + Harness. |
|
|
| Also nicht: |
|
|
| > “Ich kenne den perfekten Prompt.” |
|
|
| Sondern: |
|
|
| > “Ich versuche, die wahrscheinlichsten Failure Modes dieses Setups im Voraus zu neutralisieren.” |
|
|
| Das ist der professionelle Frame. |
|
|
| --- |
|
|
| # 10. Was ein AI Engineer daraus machen sollte |
|
|
| Wenn du das ernsthaft können willst, dann bau dir diese Arbeitsweise: |
|
|
| ## Immer drei Artefakte trennen |
|
|
| 1. **task_spec.md** |
| 2. **harness_policy.md** |
| 3. **model_adapter.md** |
| |
| Dann kombinierst du sie je nach Lauf. |
| |
| Beispiel: |
| |
| ### task_spec.md |
| |
| * PDF zusammenfassen |
| * semantische Chunks |
| * lokale Summaries |
| * globale Konsolidierung |
| * Markdown + PDF script |
| |
| ### harness_policy_opencode.md |
| |
| * Subagents |
| * Parallelität |
| * Dateibesitz |
| * Merge-Phase |
| * Check-Phase |
| |
| ### model_adapter_minimax.md |
| |
| * stärker explizit |
| * Anti-Halluzination |
| * harte Formatdisziplin |
| |
| ### model_adapter_gpt54.md |
| |
| * outcome-first |
| * verification-first |
| * weniger Micromanagement |
| |
| ### model_adapter_opus46.md |
| |
| * principle-first |
| * review-first |
| * epistemische Strenge |
| |
| Dann hast du echte **Prompt-Architektur**, nicht nur einzelne Texte. |
| |
| --- |
| |
| # 11. Meine verdichtete Theorie in einem Satz |
| |
| **Der richtige Prompt ist nicht nur eine Eigenschaft des Modells, sondern die Schnittstelle zwischen Taskstruktur, Harnessmechanik und Fehlertyp des Modells.** |
|
|
| Das ist der Übergang von “gut prompten” zu **AI Engineering**. |
|
|
| --- |
|
|
| # 12. Mein praktischer Rat für dich |
|
|
| Wenn du in diese Richtung willst, dann fang an, für jede Agent-Aufgabe systematisch zu dokumentieren: |
|
|
| * Dokumenttyp |
| * Task Spec |
| * Harness |
| * Modell |
| * Promptversion |
| * Fehlerbilder |
| * Kosten |
| * Dauer |
| * Ergebnisqualität |
| * nächste Hypothese |
|
|
| Dann baust du dir dein eigenes internes **Prompt- und Harness-Wissenssystem**. |
| Genau daraus entsteht später dein echter Vorteil gegenüber Leuten, die nur “ein bisschen mit Modellen rumspielen”. |
|
|
| Wenn du willst, mache ich dir als Nächstes daraus ein **konkretes AI-Engineer-Template-Set**: |
|
|
| * `task_spec.md` |
| * `harness_policy_opencode.md` |
| * `harness_policy_codex.md` |
| * `harness_policy_claudecode.md` |
| * `model_adapter_minimax.md` |
| * `model_adapter_gpt54.md` |
| * `model_adapter_opus46.md` |
| * plus eine kleine Eval-Rubric. |
|
|
| [1]: https://developers.openai.com/codex/?utm_source=chatgpt.com "Codex" |
| [2]: https://developers.openai.com/api/docs/models/gpt-5.4?utm_source=chatgpt.com "GPT-5.4 Model | OpenAI API" |
|
|
|
|
