Skip to main content
Chat-Modelle können über folgende Schnittstellen bereitgestellt werden:
  • /v1/chat/completions
  • /v1/messages
  • /v1beta/models/{model}:generateContent
Die Preisgestaltung kann Folgendes umfassen:
  • Input-Tokens.
  • Output-Tokens.
  • Zwischengespeicherte Input-Tokens.
  • Mindest-Credits pro Anfrage.
Kontextfenster und maximale Output-Grenzen sind Capability-Metadaten auf Modellebene.

Verfügbare Modelle

Reasoning-Stärke

Verwende reasoning_effort in Chat Completions und reasoning: { "effort": "high" } in Responses. Beide Endpoints akzeptieren die jeweils andere Form als Kompatibilitätsalias. Werden beide angegeben, müssen die Werte übereinstimmen; Konflikte ergeben 400. Ohne Angabe von effort bleibt der Modellstandard erhalten. Die Syntax akzeptiert none, minimal, low, medium, high, xhigh, max und ultra. Das ist keine Zusicherung, dass jedes Modell jeden Wert unterstützt. Ungültige Werte und Werte außerhalb des dokumentierten Modellumfangs ergeben 400. Reasoning ist bei kimi-k3, glm-5.3-flash, gpt-6-astra, der Grok-4.5-Familie und der Gemini-3-Familie immer aktiv; ein Wert, der Reasoning deaktiviert, ergibt 400. gpt-5.4 und seine Varianten mini und nano nutzen Reasoning nur, wenn du low oder höher anforderst. minimax-m3 und gpt-4o-mini akzeptieren überhaupt keinen effort-Parameter; minimax-m3 stellt stattdessen das thinking-Objekt bereit. Einige Modelle akzeptieren außerdem die Kompatibilitätsschreibweisen, die ältere Integrationen verwendet haben: grok-4.5, grok-4.5-latest, grok-4.6 und grok-4.7 akzeptieren max (ausgeführt als xhigh) und minimal (ausgeführt als low), und gemini-3.1-pro akzeptiert minimal (ausgeführt als low). Sie werden vor der Ausführung der Anfrage normalisiert, sodass das Modell stets eine offizielle Stufe erhält. capability_metadata.reasoning.compatEfforts veröffentlicht diese Zuordnungen; neue Integrationen sollten die Werte in efforts verwenden. Verwende bei Anthropic Messages output_config.effort. Natives thinking bleibt unabhängig: effort aktiviert Thinking nicht und setzt keine budget_tokens. Native Gemini-3-Anfragen verwenden generationConfig.thinkingConfig.thinkingLevel; die unterstützten Level hängen vom Modell ab. Gemini 2.5 verwendet thinkingBudget. Im OpenAI-kompatiblen Format entsprechen bei Gemini 2.5 minimal/low dem Budget 1024, medium dem Budget 8192, high dem Budget 24576 und none dem Budget 0 (außer Pro). Expliziter effort darf nicht zusammen mit nativem thinkingLevel oder thinkingBudget angegeben werden: Auch bei gleichwertigen Einstellungen wird 400 zurückgegeben. includeThoughts allein kann mit effort kombiniert werden. Andere OpenAI-kompatible Modelle akzeptieren syntaktisch gültige efforts für die Modellausführung, jedoch ohne zugesicherte Unterstützung. Prüfe die Modellfähigkeiten, bevor du dich auf einen Wert verlässt. Ausgabelimits wie max_completion_tokens, max_output_tokens und native Entsprechungen zählen Reasoning- und Antwort-Tokens gemeinsam. Effort ist kein Ausgabetokenlimit. Das Budget kann weiterhin erschöpft werden (finish_reason: "length" in Chat Completions), sodass die endgültige Antwort unvollständig oder leer bleibt. Übermittle Bilder mit Chat image_url oder Responses input_image. glm-5.3-flash akzeptiert zusätzlich Dokumente (file / input_file) und Video; für deepseek-v4.1-flash und deepseek-v4-flash werden Dokumente, Audio und Video nicht akzeptiert.

Offizielle Modell-IDs

deepseek-flash und deepseek-v4-pro werden als gleichwertige IDs für deepseek-v4.1-flash und deepseek-v4 akzeptiert, sodass ein für diese offiziellen Namen geschriebener Client unverändert funktioniert. Nutzung und Abrechnung werden einmalig unter der APIAny.AI-Modell-ID erfasst. GET /v1/models listet beide IDs auf und kennzeichnet den gleichwertigen Eintrag mit alias_of.

Modell-Fähigkeitsmetadaten

GET /v1/models gibt für jedes Modell, das seine Fähigkeiten deklariert, ein capability_metadata-Objekt zurück. Lies es, um ein Modell ohne Rätselraten zu konfigurieren:
  • input listet die akzeptierten Eingabetypen: text, image, video, audio, file.
  • output listet die erzeugten Typen.
  • features meldet stream, tools, vision, jsonMode und ob das Modell überhaupt Reasoning nutzt (thinking).
  • reasoning beschreibt die Reasoning-Steuerung: mode (always-on, optional oder none), die akzeptierten efforts, den defaultEffort, der gilt, wenn effort weggelassen wird, sowie disableWith für Modelle, deren Reasoning deaktiviert werden kann.
  • limits meldet contextWindow und maxOutputTokens.
Prüfe reasoning.mode, bevor du einen effort-Wert sendest: always-on bedeutet, dass Reasoning nicht deaktiviert werden kann, optional bedeutet, dass disableWith gilt, und none bedeutet, dass das Modell keinen Reasoning-Modus hat.
Referenzen zu API-Formaten: OpenAI, Anthropic Messages, Gemini, Gemini OpenAI.