Welches KI-Modell für welche Aufgabe? Ein Entscheidungsrahmen für Gründer

Das Problem mit zufälligem Modellwechsel

Warum mehr Modelle nicht automatisch bessere Ergebnisse bedeuten

Wer mit mehreren KI-Tools arbeitet, kennt die Situation: Für die eine Aufgabe ChatGPT, für die nächste Claude, dann doch wieder ein anderes — nach Gefühl, nicht nach Regel. Das fühlt sich flexibel an, erzeugt aber keine konsistenteren Ergebnisse. Mehr Modelle zur Auswahl zu haben, hilft nur, wenn klar ist, wann welches sinnvoll ist.

Das eigentliche Problem ist nicht die Modellauswahl an sich. Es ist das Fehlen einer Regel: Welcher Aufgabentyp braucht welche Art von Modell und welchen Modus? Ohne diese Regel entsteht entweder das eine Extrem — immer das teuerste Modell für alles — oder das andere: zufälliges Wechseln ohne nachvollziehbaren Grund.

Die versteckten Kosten: Reasoning-Modi ohne Struktur

Moderne Modelle bieten unterschiedliche Reasoning-Modi an — Stufen, in denen das Modell vor der Antwort mehr oder weniger „nachdenkt". Höhere Modi kosten mehr Zeit und Ressourcen. Wer sie unbewusst als Standard verwendet, zahlt für jede triviale Aufgabe einen Aufschlag, der nicht nötig wäre.

Diese Kosten sind versteckt, weil sie sich nicht in einer einzelnen Aufgabe bemerkbar machen, sondern über viele Aufgaben hinweg summieren. Eine bewusste Modus-Wahl ist deshalb kein Detail, sondern ein Steuerungssystem.

Aufgabentypen als Entscheidungsgrundlage

Statt nach Modell zu sortieren („Claude kann X, ChatGPT kann Y"), beginnt ein belastbares Routing beim Aufgabentyp. Vier Typen decken den Großteil eines Gründer-Workflows ab — jeder stellt andere Anforderungen.

Strategie und Richtungsentscheidungen

Strategie braucht Breite, Kontext und kritische Rückfragen. Hier geht es um Richtung und Prioritäten, nicht um die schnelle Ausführung. Mehrdeutige Fragen rechtfertigen einen höheren Reasoning-Modus — und am Ende steht eine menschliche Entscheidung, keine automatische.

Implementierung und Umsetzungsarbeit

Umsetzung braucht Tiefe und einen eng abgegrenzten Scope. Eine klar formulierte, eingegrenzte Aufgabe lässt sich oft im Normal-Modus zuverlässig lösen. Steigt das Risiko — etwa bei sensiblen oder schwer umkehrbaren Änderungen — ist eine Eskalation gerechtfertigt.

QA und Verifikation

Prüfung braucht Fokus und Unabhängigkeit. Wer schreibt, sollte nicht allein über das Ergebnis urteilen. Ein separater Durchgang — idealerweise mit einer anderen Instanz oder einem anderen Modell — findet Fehler, die der ursprüngliche Schritt übersieht.

Recherche und Synthese

Recherche braucht Breite und Geschwindigkeit. Häufig reicht ein schneller Modus, um Optionen zu sammeln und einzuordnen. Wichtig ist hier weniger der teuerste Modus als das anschließende Gegenprüfen der Quellen.

In der Praxis lohnt sich eine feinere Auflösung. Die folgende Matrix ordnet typische Aufgabenklassen einem Reasoning-Modus und einem Review-Schritt zu — als Ausgangspunkt, nicht als feste Rangliste:

Was Reasoning-Modi bedeuten

Normal, High, Extra, Max — wann macht eine Eskalation Sinn?

Reasoning-Modi sind eine eigene Dimension neben der Modellwahl. Sie steuern, wie viel Aufwand ein Modell in die Lösung steckt, bevor es antwortet. Ein einfacher Merksatz: Der Normal-Modus löst die meisten Alltagsaufgaben. Eine Eskalation auf einen höheren Modus ist dann sinnvoll, wenn das Problem riskant, komplex oder mehrdeutig ist — also wenn ein Fehler teuer wäre oder die Aufgabe mehrere Schritte sauber verbinden muss.

Die genauen Bezeichnungen und Stufen unterscheiden sich je Anbieter und ändern sich über die Zeit. Die Kategorisierung hier ist ein konfigurierbares Entscheidungsmodell, keine Aussage über das aktuelle Angebot eines bestimmten Anbieters.

Warum Extended Thinking nicht für jede Aufgabe gerechtfertigt ist

Ein höherer Modus ist verlockend, weil er „gründlicher" klingt. Aber gründlicher ist nicht immer besser: Für eine klar abgegrenzte, einfach verifizierbare Aufgabe bringt zusätzliches „Nachdenken" kaum mehr Qualität — es kostet nur mehr. Die Faustregel bleibt: Der Aufwand eines höheren Modus muss durch das Risiko oder die Komplexität der Aufgabe gerechtfertigt sein.

Plan, Implementation, Review, Verification

Neben dem Reasoning-Modus gibt es eine zweite, oft übersehene Ebene: den Arbeitsmodus. Eine größere Aufgabe durchläuft in der Regel vier Phasen — und jede Phase hat ein anderes Ziel und damit ein anderes passendes Routing.

• Plan Mode: die Aufgabe verstehen, Optionen abwägen, einen Weg festlegen — ohne schon zu schreiben. Hier zahlt sich ein starkes Reasoning-Modell aus.
• Implementation Mode: den festgelegten Plan eng am Scope umsetzen. Geeignet ist ein Modell, das diszipliniert innerhalb klarer Regeln arbeitet.
• Review Mode: das Ergebnis kritisch prüfen — bewusst getrennt von dem, der es erstellt hat.
• Verification Mode: objektiv nachweisen, dass es funktioniert — über Tests und eine unabhängige Prüfung statt über ein Bauchgefühl.

Ein konkretes Beispiel zeigt, wie diese Modi zusammenspielen — etwa für die Aufgabe, eine neue SEO-Landingpage zu implementieren:

Die Ressourcen-Policy: den kleinsten Modus wählen

Das Prinzip

Die Ressourcen-Policy lässt sich in einem Satz zusammenfassen: Nimm den kleinsten Modus, der die Aufgabe sicher löst. Nicht das teuerste Modell als Standard, sondern bewusstes Eskalieren nach Bedarf. Das macht den Ressourceneinsatz messbar und nachvollziehbar — und verhindert, dass einfache Aufgaben teuer werden.

Ein konkretes Beispiel (aus dem Beispielprojekt)

Wie eine solche Entscheidung in der Praxis aussieht, zeigt das fiktive Beispielprojekt FeedbackPing. Für eine kleine, klar abgegrenzte Aufgabe wird bewusst der Normal-Modus gewählt — und die Begründung festgehalten:

Routing-Entscheidungen dokumentieren statt improvisieren

Warum die gleiche Frage immer wieder auftaucht

Ohne festen Ort wird die Routing-Frage in jedem Projekt — und manchmal in jeder Session — neu gestellt: Welches Tool, welcher Modus, wer prüft? Diese wiederholte Überlegung kostet Zeit und führt zu Inkonsistenzen, weil die Antwort jedes Mal leicht anders ausfällt.

Eine MODEL_ROUTING-Datei: Entscheidungen einmal festhalten

Die Lösung ist dieselbe wie beim Projektkontext: eine Datei, die außerhalb einzelner Chats lebt. Eine Routing-Tabelle hält fest, welcher Aufgabentyp welchem Werkzeug und Modus zugeordnet ist — einmal entschieden, immer wieder anwendbar. So sieht eine beispielhafte, frei anpassbare Zuordnung aus:

• Beispielhafte Zuordnung — keine Rangliste.
• Das Routing ist frei anpassbar.
• Keine automatische Provider-Steuerung.

Wichtig: Das ist eine beispielhafte Zuordnung, keine Rangliste und keine automatische Steuerung. Welches Tool welche Rolle übernimmt, entscheidest du — die Datei hält die Entscheidung nur nachvollziehbar fest.

Das AI Orchestrator Kit: Modell-Routing als Datei

Was das Kit enthält

Das AI Orchestrator Kit macht aus dieser Methode konkrete Vorlagen. Es enthält unter anderem:

• AI_ROLE_MATRIX.md — welche KI welche Rolle übernimmt, mit klarer Aufgabentrennung.
• MODEL_ROUTING.md — wie Tool und Modell für eine Aufgabe gewählt werden.
• MODE_SELECTION.md — der kleinste Reasoning-Modus, der die Aufgabe sicher löst.
• TASK_ROUTING.md — wie eine rohe Aufgabe geformt, eingegrenzt und weitergeleitet wird.
• RESOURCE_POLICY.md — bewusster Einsatz teurer Modi.
• QUALITY_GATES.md und HANDOFF_LOG.md — die Messlatte für „fertig" und ein nachvollziehbarer Verlauf abgeschlossener Arbeit.

Das Kit besteht aus Markdown-Dateien in einem ZIP — lokal im Projektordner, kein Account, keine Cloud, kein Abo. Die Produktdateien selbst sind auf Englisch, damit sie mit allen gängigen Modellen zuverlässig funktionieren. Entscheidend: Das Kit steuert keine Modelle automatisch. Es enthält ein Entscheidungsmodell als Datei, das du für jede Aufgabe anwendest.

Wie Routing mit dem Projektkontext zusammenhängt

Gutes Routing setzt guten Kontext voraus. Ohne einen klaren Projektkontext fehlt dem Modell die Grundlage, um eine Aufgabe richtig einzuordnen — und dann hilft auch das beste Routing wenig. Beide Ebenen greifen ineinander: Der Kontext sagt, worum es geht; das Routing sagt, wer es mit welchem Modus bearbeitet. Wie sich beide Ebenen zu einem durchgehenden Ablauf verbinden, zeigt der vollständige Workflow; die Produktsicht auf das Routing-Feature beschreibt die Seite Modell-Routing im System.