Skip to main content
FIM One ist anbieteragnostisch — jeder OpenAI-kompatible Endpunkt funktioniert. Diese Seite hilft Ihnen, die beste Modellkombination für Ihren Anwendungsfall auszuwählen. Konfigurationsdetails finden Sie unter Umgebungsvariablen.

​
Wie FIM One Modelle nutzt

FIM One hat drei Modellrollen: Fast und Reasoning fallen auf General zurück, falls nicht konfiguriert. Für Produktionsbereitstellungen bietet die Aufteilung in mindestens zwei Modelle (General + Fast) das beste Kosten-/Qualitätsverhältnis. Diese Rollen können über Umgebungsvariablen oder über die Funktion Model Groups der Admin-Benutzeroberfläche konfiguriert werden, die Ein-Klick-Umschaltung zwischen Modellsätzen ermöglicht. Siehe Model Management für das vollständige Admin-UI-Handbuch.

​
Quick Selection Matrix

Vision indicates whether the model accepts image input. This is required for Intelligent Document Processing (IDP) — if your model doesn’t support vision, IDP will fall back to text-only extraction. Providers marked ⚠️ have vision on some models but not others; check the specific model you’re using.Chat attachments follow the same flag: with a text-only model an attached image is not sent, and the model receives its file name only. The chat composer says so before you send, based on the model the turn would actually use (agent setting, then the active model group, then the system default). Document text is unaffected — a PDF or DOCX still has its content extracted and injected.
This table lists the combinations we recommend, not the full set of providers FIM One supports. xAI (Grok), ByteDance Doubao, Mistral and any OpenAI-compatible relay all work; see the Provider Capability Matrix for the complete list and how each one is routed.

​
Strukturierte Ausgabekompatibilität

FIM Ones DAG-Planer benötigt, dass das Modell gültiges strukturiertes JSON zurückgibt. Intern versucht es drei Extraktionsebenen in dieser Reihenfolge:
  1. Native Function Calling — zwingt das Modell, JSON auszugeben, das einem Schema über die Tool-Call-API entspricht. Am zuverlässigsten.
  2. JSON Mode — fordert response_format: json_object an. Garantiert gültiges JSON, erzwingt aber keine Schemakonformität.
  3. Plain Text Extraction — analysiert JSON aus Freitext als letzten Ausweg.
Modelle, die Level 1 (natives FC mit erzwungenem tool_choice) unterstützen, bieten die beste Planungszuverlässigkeit. Wenn ein Modell nur Level 2 erreicht, hängt seine Ausgabequalität davon ab, wie gut es den Anweisungen folgt — schwächere Modelle können gültiges JSON produzieren, das nicht der erwarteten Struktur entspricht. Diese Tabelle ist eine Entscheidungshilfe. Die autoritative, codegebundene Version, einschließlich welche tool_choice-Zustände jeder Anbieter akzeptiert und was FIM One tut, wenn einer abgelehnt wird, ist die Provider Capability Matrix.
Wenn Sie den Fehler „failed to generate a valid task plan” sehen, ist die strukturierte Ausgabefähigkeit des Modells für DAG-Planung unzureichend. Wechseln Sie Ihr Main LLM zu einem Modell mit einer Bewertung von ⭐⭐⭐ oder ⭐⭐ oder höher, oder deaktivieren Sie den DAG-Modus und verwenden Sie stattdessen den einfacheren ReAct-Agenten.

​
Thinking / Reasoning Kompatibilität

Verschiedene Anbieter implementieren “Thinking” (Chain-of-Thought-Reasoning) auf grundlegend unterschiedliche Weise. Dies ist wichtig, da der Thinking-Modus mit Tool-Aufrufen in Konflikt geraten kann und die Ausgabe je nach Anbieter an verschiedenen Stellen erscheint. FIM One handhabt all dies transparent — diese Tabelle hilft dir zu verstehen, was unter der Haube passiert.

​
Schlüsselkonzepte

  • Opt-in — Denken ist standardmäßig deaktiviert; Sie aktivieren es über einen API-Parameter (z. B. reasoning_effort). Kann selektiv pro Aufruf deaktiviert werden.
  • Always-on — das Modell denkt immer; es gibt keinen API-Parameter, um es auszuschalten. Sie müssten zu einer Modellvariante ohne Denken wechseln, um es zu vermeiden.
  • Modell-Ebene — Denken wird durch die Modell-ID bestimmt, die Sie wählen (z. B. deepseek-reasoner vs deepseek-chat), nicht durch einen Parameter.

​
Kompatibilitätsmatrix

Die anbieterorientierte Detailinformation hinter dieser Tabelle, einschließlich der Übersetzung jeder effort-Stufe und ob Reasoning in späteren Durchläufen wiedergegeben wird, befindet sich in Tabelle C der Provider-Capability-Matrix.

​
Wie FIM One jeden Fall handhabt

API-Level reasoning_content (Claude, DeepSeek): Das Reasoning-Feld wird direkt aus der API-Antwort gelesen und im UI Reasoning-Panel angezeigt. Keine Nachbearbeitung erforderlich. <think> Tags im Content (MiniMax, Qwen, QwQ und andere Open-Source-Derivate): FIM One entfernt automatisch <think>...</think> Tags aus dem Content-Feld und leitet den Thinking-Text zum Reasoning-Panel um. Dies funktioniert sowohl für Streaming- als auch für Non-Streaming-Antworten. Erzwungene FC + Thinking-Konflikte sind pro Provider, nicht eine Eigenschaft von Thinking-Modellen im Allgemeinen. Claude lehnt die Kombination ab, aber sein Thinking ist optional, daher deaktiviert FIM One das Thinking für diesen einen Aufruf, indem es reasoning_effort=None übergibt und das native Function Calling fortgesetzt wird. Kimi lehnt es ebenfalls ab, und sein Thinking wird durch die Modell-ID statt durch einen Parameter ausgewählt, daher besteht die Lösung darin, Native Function Calling für die Thinking-Modelle zu deaktivieren. MiniMax denkt bei jedem Aufruf und akzeptiert erzwungenes Function Calling trotzdem, weshalb keine Problemumgehung darauf anwendbar ist. Fallback-Kette: Wenn erzwungenes Function Calling aus irgendeinem Grund fehlschlägt, fällt FIM One automatisch zurück: Native FC → JSON-Modus → Plain-Text-Extraktion. Dieser dreistufige Ansatz stellt sicher, dass die Planung auch bei Providern mit teilweiser Tool-Calling-Unterstützung funktioniert.
Wenn Sie ein Modell verwenden, das immer denkt (MiniMax M2.7, deepseek-reasoner) als Ihr Main LLM, wird die Thinking-Ausgabe in jedem Reasoning-Panel der Agent-Iteration angezeigt. Dies ist normal — es beeinträchtigt die Funktionalität nicht, und Sie können den Reasoning-Prozess des Modells sehen.

​
Anbieterdetails

​
OpenAI

Die am meisten bewährte Option. OpenAI-Modelle haben die beste native Unterstützung für Funktionsaufrufe (Tool-Calling), was sich direkt auf die Zuverlässigkeit von Agenten auswirkt. Die GPT-5-Familie (August 2025+) stellt einen großen generationalen Sprung gegenüber GPT-4 dar. Empfohlene Modelle:
  • Main: gpt-5.4 (neuestes Flaggschiff, März 2026 — 1M+ Kontext, Computer Use) oder o3 (beste Reasoning-Genauigkeit)
  • Fast: gpt-5.4-mini (0,75/0,75/4,50 pro MTok) oder gpt-5.4-nano (günstigste mit 0,20/0,20/1,25 pro MTok)
  • Budget Fast: gpt-5-mini (0,25/0,25/2,00) und gpt-5-nano (0,05/0,05/0,40) bleiben zu niedrigeren Preisen verfügbar
  • Legacy: gpt-4.1 (noch in der API, 1M Kontext, gut für Coding)
Reasoning: Setzen Sie LLM_REASONING_EFFORT=medium — funktioniert nativ mit o-Series und GPT-5.x-Modellen. GPT-5.4 unterstützt reasoning_effort mit den Stufen none, low, medium, high, xhigh. Die o-Series erfordert max_completion_tokens statt max_tokens, was LiteLLM automatisch handhabt. Hinweis: /v1/chat/completions lehnt GPT-5.x-Anfragen ab, die Tools mit Reasoning kombinieren, daher spricht FIM One direkt die Responses API für GPT-5.x an, wo beide zusammen funktionieren. Dieser Pfad trägt auch das verschlüsselte Reasoning jeder Runde in die nächste, sodass ein Agent, der eine mehrstufige Antwort aufbaut, das bereits Erarbeitete behält, statt es bei jedem Tool-Aufruf neu herzuleiten. Endpunkte ohne /v1/responses-Route fallen auf Chat Completions mit explizitem reasoning_effort: "none" während der Agent-Tool-Use-Schritte zurück, und FIM_GPT5_RESPONSES_MODE kann entweder Fallback manuell erzwingen. Andere Modellfamilien auf OpenAI-kompatiblen Endpunkten bleiben bei Chat Completions: Sie gewinnen nichts von Responses, und Proxy-Shims dafür können das Streaming schlecht puffern. GPT-5.4 erfordert temperature=1, was FIM One automatisch über LiteLLMs Parameterfilterung (drop_params) handhabt.

​
Anthropic (Claude)

Claude zeichnet sich durch differenzierte Argumentation und komplexe mehrstufige Aufgaben aus. FIM One verbindet sich über LiteLLM, das Anthropic-Modelle automatisch über deren native API weiterleitet. Die aktuelle Generation ist Claude 4.6 (Februar 2026). Empfohlene Modelle:
  • Main: claude-sonnet-4-6 (beste Balance zwischen Leistung und Kosten — 3/3/15 pro MTok)
  • Fast: claude-haiku-4-5 (schnell und günstig — 1/1/5 pro MTok)
  • Premium: claude-opus-4-6 (am leistungsfähigsten, 128K maximale Ausgabe — 5/5/25 pro MTok)
Basis-URL: https://api.anthropic.com/v1/ Opus 4.6 und Sonnet 4.6 haben ein 1M-Kontextfenster (GA seit 13. März 2026 — kein Beta-Header erforderlich). Haiku 4.5 hat ein 200K-Kontextfenster. Reasoning: Setzen Sie LLM_REASONING_EFFORT=medium. LiteLLM leitet Anthropic-Modelle über die native API weiter, sodass reasoning_content (erweitertes Denken) vollständig zurückgegeben und im UI-Schritt „thinking” sichtbar ist. Claude 4.6 und neuer verwenden Adaptive Thinking (thinking: {type: "adaptive"} plus output_config.effort) anstelle eines manuellen budget_tokens, das FIM One direkt ausgibt, anstatt sich auf LiteLLMs Zuordnung zu verlassen. Anthropic erfordert temperature=1 während das Denken aktiv ist, und das System erzwingt das für Sie: der Request Builder fixiert den Wert auf Anthropic-Routen, und bei Modellen, die Sampling-Parameter ablehnen, entfernt er temperature vollständig. Setzen Sie nicht manuell LLM_TEMPERATURE=1. Weitere Informationen finden Sie unter Extended Thinking.

​
Google Gemini

Gemini-Modelle bieten starke Leistung zu wettbewerbsfähigen Preisen über Googles OpenAI-kompatiblen Endpunkt. Die 3.x-Generation (Ende 2025+) ist ein großer Sprung — Gemini 3 Flash übertrifft 2.5 Pro und ist dabei 3x schneller. Hinweis: gemini-3-pro-preview wurde am 9. März 2026 abgeschaltet — verwenden Sie stattdessen gemini-3.1-pro-preview. Empfohlene Modelle:
  • Stabil (GA): gemini-2.5-pro (Hauptmodell) + gemini-2.5-flash (schnell) — produktionsreif
  • Neueste (Vorschau): gemini-3.1-pro-preview (Hauptmodell) + gemini-3-flash-preview (schnell) + gemini-3.1-flash-lite-preview (Budget schnell) — beste Leistung, aber Vorschaustatus
Basis-URL: https://generativelanguage.googleapis.com/v1beta/openai/ Reasoning: reasoning_effort wird auf dem Kompatibilitäts-Endpunkt unterstützt — setzen Sie LLM_REASONING_EFFORT=medium und es funktioniert sofort.

​
DeepSeek

DeepSeek bietet das beste Kosten-Leistungs-Verhältnis auf dem Markt. V3.2 (Dezember 2025) vereinigte die Chat- und Reasoning-Linien in einem einzigen Modell mit unglaublich niedrigen Preisen. Modell-IDs (beide unterstützt durch V3.2):
  • deepseek-chat — Allzweck (Non-Thinking-Modus)
  • deepseek-reasoner — Chain-of-Thought-Reasoning-Modus, gibt reasoning_content zurück
Basis-URL: https://api.deepseek.com Preise: 0,28/0,28/0,42 pro MTok (Cache-Hit: $0,028) — bei weitem die günstigste Frontier-Klasse-API. Ausgabelimits: deepseek-chat maximale Ausgabe beträgt 8K Token (muss explizit über max_tokens gesetzt werden). deepseek-reasoner maximale Ausgabe beträgt 64K Token (einschließlich Chain-of-Thought).
V4 erwartet April 2026: Billionen-Parameter-Multimodal-Modell mit 1M-Kontextfenster. Erwarten Sie neue Modell-IDs bei der Veröffentlichung.

​
Chinesische Inlandsmodelle

Alle großen chinesischen Modellanbieter stellen OpenAI-kompatible Endpunkte bereit. Diese sind besonders stark für chinesischsprachige Aufgaben und bieten wettbewerbsfähige lokale Preise.

​
Qwen / 通义千问 (Alibaba Cloud)

Qwen 3.5 (Februar 2026) ist die neueste Generation — das 397B MoE Flaggschiff übertrifft GPT-5.2 bei MMLU-Pro. Stärkste Unterstützung für chinesische Sprache und günstigste Frontier-Class-Preisgestaltung (~$0,11/MTok Input).
  • Base URL (China): https://dashscope.aliyuncs.com/compatible-mode/v1
  • Base URL (Global): https://dashscope-intl.aliyuncs.com/compatible-mode/v1
  • Main: qwen3.5-plus (Flaggschiff, 1M Kontext, 0,11/0,11/0,66 pro MTok) oder qwen3-max (256K, stärkste)
  • Fast: qwen3.5-flash (0,055/0,055/0,22 pro MTok) oder qwen-turbo (0,04/0,04/0,08 pro MTok)
  • Reasoning: qwen3-max mit enable_thinking: true Parameter (es gibt keine separate qwen3-max-thinking Modell-ID)

​
ChatGLM / 智谱

GLM-4.7 und GLM-5 (2026) sind die neuesten Modelle. GLM-5 ist das 745B MoE Flaggschiff, das sich Claude Opus-Niveau bei Coding-/Agent-Aufgaben nähert.
  • Basis-URL (Inland): https://open.bigmodel.cn/api/paas/v4
  • Basis-URL (Z.AI International): https://api.z.ai/api/paas/v4
  • Hauptmodell: glm-4.7 (starkes Coding, 0.60/0.60/2.20 auf Z.AI)
  • Schnell: glm-4.7-flash (kostenlos!) oder glm-4.7-flashx (0.07/0.07/0.40, höherer Durchsatz)
  • Reasoning: glm-5 (745B MoE Flaggschiff, 1.00/1.00/3.20)
Erzwungenes tool_choice wird nicht unterstützt — nur "auto" funktioniert.
Einige HTTP-Clients hängen automatisch /v1 an Basis-URLs an. Zhipu verwendet /v4 — stellen Sie sicher, dass Ihr Client keinen OpenAI-ähnlichen Pfad-Suffix erzwingt, sonst erhalten Sie 404-Fehler.

​
MiniMax

MiniMax M2.7 (18. März 2026) ist das neueste Modell mit offenen Gewichten und erreicht 80,2% auf SWE-Bench. M2.5 bleibt als schnelle/Budget-Option verfügbar. MiniMax bietet zwei separate API-Endpunkte für verschiedene Regionen:
  • Basis-URL (Global/海外版): https://api.minimax.io/v1 — für Benutzer außerhalb des chinesischen Festlands
  • Basis-URL (China/国内版): https://api.minimaxi.com/v1 — für Benutzer im chinesischen Festland (beachten Sie das zusätzliche i in minimaxi)
  • Main: MiniMax-M2.7
  • Fast: MiniMax-M2.5
  • Speed: MiniMax-M2.7-highspeed (2x Kosten, niedrigere Latenz)

​
Kimi / 月之暗面 (Moonshot)

Kimi K2.5 (Januar 2026) hat 256K Kontext und starke Codierungsleistung (76,8% SWE-Bench unter Open-Source-Modellen).
  • Basis-URL (Global): https://api.moonshot.ai/v1
  • Basis-URL (China): https://api.moonshot.cn/v1
  • Hauptmodell: kimi-k2.5
  • Schnell: kimi-k2 (kein Denken, Funktionsaufrufe funktionieren)
  • Reasoning: kimi-k2-thinking (0,47/0,47/2,00 pro MTok)
Erzwungene tool_choice funktioniert nur, wenn der Thinking-Modus ausgeschaltet ist. Wenn Thinking aktiviert ist, wird nur "auto" unterstützt.

​
Lokale Modelle (Ollama)

Führen Sie Modelle vollständig auf Ihrer eigenen Hardware aus — kein API-Schlüssel erforderlich, vollständig offline. Ollama stellt standardmäßig einen OpenAI-kompatiblen Endpunkt bereit. Die Open-Source-Landschaft hat sich dramatisch verändert — Qwen 3.5, Llama 4 und GPT-OSS (OpenAIs erste Open-Weight-Modelle) sind alle verfügbar. Basis-URL: http://localhost:11434/v1 Empfohlene Modelle nach VRAM: Am besten für Tool-Aufrufe: Qwen 3/3.5 (32B+), GLM-4.7, GPT-OSS, Mistral — diese haben explizites Funktionsaufrufe-Training. Modelle mit 14B+ Parametern sind das Minimum für zuverlässige Tool-Aufrufe; 32B+ wird dringend empfohlen.
Die Qualität von Tool-Aufrufen variiert erheblich zwischen lokalen Modellen. Nicht alle Modelle generieren zuverlässig gültige Funktionsaufrufe. Testen Sie Ihr gewähltes Modell mit Agent-Workflows, bevor Sie es in der Produktion einsetzen. Die allgemeine Regel: 14B Minimum, 32B+ empfohlen für Agent-Aufgaben.

​
Drittanbieter-Relay-Plattformen

Viele Benutzer greifen auf mehrere Modellanbieter über einen einzigen Relay-(Proxy-)Dienst zu. FIM One erkennt automatisch das richtige API-Protokoll basierend auf URL-Pfadmustern – füllen Sie einfach LLM_BASE_URL aus und es funktioniert.

​
Funktionsweise

Wenn Ihre Basis-URL auf ein Drittanbieter-Relay verweist, inspiziert FIM One den URL-Pfad, um das zu verwendende Protokoll zu bestimmen: Auflösungsreihenfolge: Explizites DB-Anbieterfeld > Domain-Match (offizielle APIs) > URL-Pfad-Hinweis (Relay-Plattformen) > OpenAI-kompatibler Fallback.

​
Beispiel: Ein Relay, drei Protokolle

Mit einem einzelnen Relay-Konto können Sie auf verschiedene Anbieter zugreifen, indem Sie einfach den Basis-URL-Pfad ändern:
Keine zusätzliche Konfiguration erforderlich — Authentifizierungsheader, Parameterformate und Response-Parsing werden automatisch umgeschaltet.

​
Schritt für Schritt: Wie die Pfaderkennung funktioniert

Hier ist ein konkretes Beispiel, das zeigt, was intern geschieht, wenn Sie ein Relay konfigurieren:
  1. FIM One erkennt /claude im URL-Pfad → erkennt Anthropic natives Protokoll
  2. Modell wird als anthropic/claude-sonnet-4-6 für LiteLLM-Routing präfixiert
  3. Anfragen verwenden das Anthropic-Format /v1/messages mit x-api-key Auth-Header
  4. reasoning_effort=medium wird in Anthropics nativen thinking-Parameter übersetzt (nicht OpenAIs reasoning_effort)
Wenn die gleiche Relay-URL stattdessen https://my-relay.example.com/v1 wäre, würde der /claude-Hinweis fehlen — FIM One würde auf das OpenAI-kompatible Protokoll zurückfallen und /v1/chat/completions-Anfragen an einen Claude-nativen Endpunkt senden, was fehlschlagen würde. Der URL-Pfad ist wichtig.

​
Warum das wichtig ist

  • Anthropic nativer Endpunkt bietet dir ordnungsgemäße reasoning_content-Unterstützung (erweitertes Denken sichtbar in der UI), korrektes Tool-Calling-Format und x-api-key-Authentifizierung — Funktionen, die bei Verwendung der OpenAI-kompatiblen Übersetzung verloren gehen.
  • Google nativer Endpunkt bietet dir native Gemini-Parameter und x-goog-api-key-Authentifizierung.
  • OpenAI kompatibel ist der universelle Fallback und funktioniert mit jedem Relay, aber anbieterspezifische Funktionen (wie die Ausgabe des erweiterten Denkens) sind möglicherweise nicht verfügbar.
Wenn deine Relay-Plattform nicht standardisierte Pfadkonventionen verwendet (z. B. kein /claude oder /anthropic in der URL), greift FIM One auf das OpenAI-kompatible Protokoll zurück — das für die meisten Anwendungsfälle funktioniert. Für vollständige native Protokollunterstützung kannst du das Feld provider explizit über die Admin-Modellkonfiguration UI setzen.
Relays schlagen auch auf Weise fehl, die ein direkter Anbieter nicht tut, und die meisten dieser Fehler sind stumm: ein gelöschter Parameter, ein entfernter Cache-Breakpoint, ein gepufferter Stream, der nie einen Fehler verursacht. Die Symptom-für-Symptom-Liste findest du unter Relay/Proxy-Fallstricke.
Relays sind Best-Effort. Das dokumentierte Verhalten von FIM One ist für First-Party-Endpunkte garantiert, d. h. OpenAI, Anthropic, Google und andere Anbieter, die ihre eigenen Modelle direkt bereitstellen. Relays funktionieren und werden häufig verwendet, auch für Modelle, die nur auf diese Weise erreichbar sind, aber was ein Relay mit einer Anfrage tut, liegt außerhalb unserer Kontrolle, daher tragen sie keine solche Garantie. Nichts wird durch Hostnamen blockiert: Die Fähigkeit wird pro Endpunkt überprüft, und nicht unterstütztes Verhalten greift von selbst zurück. Bevor du einen Fehler auf Modellebene meldest, reproduziere ihn gegen den First-Party-Endpunkt.

​
Konfigurationsstrategie

​
Main vs Fast: Wann sollte man aufteilen

  • Aufteilen wenn dein Hauptmodell teuer oder langsam ist (z. B. gpt-5.4 + gpt-5.4-nano). DAG-Modus führt viele parallele Schritte aus — die Verwendung eines günstigeren schnellen Modells spart erhebliche Kosten.
  • Gleiches Modell wenn dein Modell bereits günstig ist (z. B. deepseek-chat für beide). Der Overhead der Verwaltung von zwei Modellen lohnt sich nicht.

​
Wann sollte man Reasoning aktivieren

  • Aktivieren für komplexe analytische Aufgaben, mehrstufige Planung und Aufgaben, die sorgfältige Beurteilung erfordern
  • Deaktivieren (Standard) für Routineaufgaben, einfache Fragen und Antworten sowie kostensensitive Bereitstellungen
  • Reasoning erhöht typischerweise die Kosten um das 2-5-fache pro Anfrage — medium Aufwand ist ein guter Ausgangspunkt

​
Context-Fenster-Größe

Setzen Sie LLM_CONTEXT_SIZE auf die tatsächliche Fenster-Größe Ihres Modells: Für lokale Modelle setzen Sie sowohl LLM_CONTEXT_SIZE als auch LLM_MAX_OUTPUT_TOKENS explizit — die Standardwerte gehen von Cloud-Scale-Context-Fenstern aus, die lokale Modelle nicht unterstützen können.