KI effizienter im Online Marketing einsetzen: Multi-Model-Routing mit Claude Code

Wer KI im Online Marketing nur gelegentlich nutzt, muss sich über Model Routing kaum Gedanken machen. Man öffnet ChatGPT, Claude oder Gemini, stellt eine Frage und arbeitet mit der Antwort weiter.

Das verändert sich, sobald KI nicht mehr nur berät, sondern tatsächlich Arbeit übernimmt.

Ein Agent liest dann beispielsweise einen Google-Ads-Export ein, kategorisiert Suchanfragen, analysiert einen Performance-Report, erstellt Content-Entwürfe, prüft Dateien, schreibt ein Script oder führt mehrere dieser Schritte nacheinander aus.

Plötzlich entsteht eine neue Frage:

Muss für jeden einzelnen Arbeitsschritt wirklich das stärkste verfügbare KI-Modell eingesetzt werden?

In vielen Fällen lautet die Antwort: nein.

Eine strategische Analyse, ein komplexer Fehler in einer Automatisierung und die Klassifizierung von 20.000 Datensätzen sind drei sehr unterschiedliche Aufgaben. Trotzdem werden sie in vielen KI-Workflows an dasselbe Modell geschickt.

Ich habe deshalb neben Claude mehrere weitere Modelle in meine lokale Claude-Code-Umgebung integriert und getestet: GLM 4.7 Flash, DeepSeek V4.1 Flash, Gemini 3.5 Flash-Lite und Qwen 3.8 Flash. Nicht, weil eines davon pauschal „besser“ als Claude wäre. Sondern weil sie unterschiedliche Rollen übernehmen können.

Die wichtigste Erkenntnis daraus ist überraschend einfach:

Nicht die Grösse einer Aufgabe sollte über das Modell entscheiden, sondern vor allem das Risiko eines Fehlers und die Frage, wie gut sich das Ergebnis überprüfen lässt.

Vom KI-Chat zum KI-Arbeitssystem

Bei einem klassischen Chat ist die Architektur einfach:

Mensch → Modell → Antwort

Bei einem Agenten sieht sie eher so aus:

Aufgabe → Planung → Dateien → Tools → APIs → Teilaufgaben → Prüfung → Ergebnis

Damit verändert sich auch die Rolle des Modells.

Das LLM ist nicht länger zwangsläufig der einzige „Denker“ des Systems. Es kann Aufgaben zerlegen und Teile davon an spezialisierte Worker übergeben. Deterministische Schritte können klassische Scripts übernehmen. Ein stärkeres Modell wird nur dort benötigt, wo tatsächlich mehr Urteilsvermögen notwendig ist.

Im Online Marketing gibt es dafür viele geeignete Aufgaben:

• Tausende Search Terms nach Intention gruppieren
• Kampagnennamen einer Taxonomie zuordnen
• grosse CSV-Dateien strukturieren
• Daten aus Reports extrahieren
• SEO-Titel oder Meta Descriptions vorbereiten
• Kundenbewertungen kategorisieren
• Content-Briefings zusammenfassen
• Anzeigenvarianten vorbereiten
• Change Logs analysieren
• Marketingdaten auf Auffälligkeiten untersuchen
• Scripts und Automatisierungen entwickeln oder debuggen

Diese Aufgaben sehen ähnlich aus, stellen aber sehr unterschiedliche Anforderungen an ein Modell.

Der entscheidende Unterschied: Kann ich das Ergebnis kontrollieren?

Nehmen wir zwei Aufgaben.

Aufgabe A:

20.000 Search Terms sollen den Kategorien Brand, Product, Research, Support und Other zugeordnet werden.

Aufgabe B:

Ein Unternehmen möchte wissen, ob Brand- und Non-Brand-Kampagnen künftig zusammengeführt werden sollten.

Aufgabe A ist viel grösser. Sie kann erhebliche Laufzeit und sehr viele Tokens verursachen.

Trotzdem ist sie relativ gut kontrollierbar.

Nach der Verarbeitung kann ein Script prüfen:

• Sind noch genau 20.000 Datensätze vorhanden?
• Sind alle ursprünglichen IDs vorhanden?
• Hat jede Zeile genau eine Kategorie?
• Wurden nur erlaubte Kategorien verwendet?
• Gibt es Duplikate?
• Gibt es leere Felder?
• Wie sehen die Verteilungen aus?
• Bestehen 50 oder 100 zufällig ausgewählte Fälle eine manuelle Stichprobe?

Aufgabe B kann dagegen in wenigen Absätzen beantwortet werden.

Aber die Qualität der Empfehlung hängt möglicherweise von Wettbewerb, Budgets, Conversion-Signalen, Suchvolumen, Attribution, Brand-Bidding-Regeln und Unternehmensstrategie ab.

Eine formal korrekte Ausgabe sagt hier wenig darüber aus, ob die Entscheidung gut ist.

Das führt zu einer für mich zentralen Regel:

Je leichter sich eine Antwort unabhängig überprüfen lässt, desto eher kann die Aufgabe an ein günstigeres Modell gehen.

Das ist ein anderer Ansatz als „kleine Aufgabe = kleines Modell, grosse Aufgabe = grosses Modell“.

Drei Klassen von Aufgaben

Für die Praxis hilft eine einfache Unterscheidung.

1. Deterministische Aufgaben: möglichst gar kein LLM

Ein Sprachmodell sollte keine Arbeit übernehmen, die normaler Code perfekt erledigen kann.

Beispiele:

• Duplikate entfernen
• Summen berechnen
• Zeichenlängen kontrollieren
• URLs normalisieren
• erlaubte Werte prüfen
• CSV-Zeilen zählen
• ß durch ss ersetzen
• Zahlenformate vereinheitlichen

Hier ist ein Script schneller, billiger und vor allem reproduzierbar.

2. Semantische, aber überprüfbare Aufgaben: günstige Modelle

Das ist für mich der interessanteste Bereich.

Hier braucht man Sprachverständnis, kann das Resultat aber gut kontrollieren.

Zum Beispiel:

• Search Terms klassifizieren
• Reviews nach Themen gruppieren
• Landingpages nach Inhalt kategorisieren
• Informationen aus längeren Dokumenten extrahieren
• Change Logs zusammenfassen
• vorhandene Texte einem festen Schema zuordnen
• Entwürfe in grosser Zahl vorbereiten

Genau hier können günstigere Modelle sehr viel Arbeit übernehmen.

3. Schwer überprüfbare Aufgaben: stärkeres Modell

Anders sieht es aus, wenn Fehler teuer oder schwer erkennbar wären.

Zum Beispiel:

• Marketingstrategie
• Kampagnenarchitektur
• Bewertung widersprüchlicher Daten
• komplexe technische Fehlerdiagnosen
• produktive Systemmigrationen
• Änderungen mit weitreichenden Auswirkungen
• Entscheidungen, für die keine eindeutige Ground Truth existiert

Hier ist der Preisunterschied zwischen Modellen meist zweitrangig.

Wie mein Routing heute aussieht

Aus diesen Überlegungen ist bei mir folgende Arbeitsteilung entstanden:

Rolle	Modell
günstige und gut überprüfbare Routinearbeit	GLM 4.7 Flash
Batch-Klassifikation, Extraktion, Zusammenfassung	Gemini 3.5 Flash-Lite
Coding und robustere Multi-Step-Agent-Aufgaben	DeepSeek V4.1 Flash
alternative Provider-Strecke / Redundanz	Qwen 3.8 Flash
Planung und komplexe Entscheidungen	Claude Sonnet
besonders schwierige Ausnahmefälle	Claude Opus

Das ist ausdrücklich keine Rangliste der Modelle.

Ein Modell kann in einem Benchmark stärker sein und trotzdem für eine konkrete Automatisierung weniger geeignet sein. Entscheidend sind neben der eigentlichen Modellqualität auch Tool Use, Latenz, Berechtigungen, Datenschutz, API-Stabilität und Kosten.

GLM 4.7 Flash: günstig reicht manchmal vollkommen aus

GLM 4.7 Flash ist ein kompaktes Z.ai-Modell, das auch für agentische und Coding-Aufgaben eingesetzt werden kann.

Interessanter als Herstellerbenchmarks war für mich ein eigener Vergleich.

Ich gab GLM, DeepSeek und Qwen dieselbe mehrstufige Testaufgabe. Dabei mussten Daten verarbeitet und mehrere Berechnungen durchgeführt werden. Das unabhängig bestimmte korrekte Endergebnis betrug:

186,10 Euro.

GLM kam exakt auf dieses Ergebnis.

Der Weg dorthin war allerdings relativ unruhig: 15 Turns und sieben unnötige Versuche, Shell- beziehungsweise PowerShell-Befehle einzusetzen.

Für eine sensible Systemänderung wäre das kein ideales Verhalten.

Bei einer grossen, günstigen und danach kontrollierten Klassifikationsaufgabe ist es aber möglicherweise völlig ausreichend.

In meinem getesteten Z.ai-Setup wurden für diese GLM-Aufrufe keine Kosten berechnet. Das ist eine Beobachtung meines konkreten Accounts und keine Aussage darüber, dass der Dienst allgemein oder dauerhaft kostenlos bleibt.

Das Beispiel illustriert einen wichtigen Punkt:

Effizienz des Agents und Korrektheit des Ergebnisses sind nicht dasselbe.

DeepSeek V4.1 Flash: wenn aus einer Aufgabe ein Workflow wird

DeepSeek V4.1 Flash bekam exakt dieselbe Testaufgabe.

Auch hier war das Ergebnis:

186,10 Euro.

DeepSeek benötigte dafür nur fünf Turns und unternahm keinen unnötigen Shell-Versuch.

Der konkrete Testlauf kostete bei mir ungefähr 0,05 US-Dollar.

DeepSeek positioniert V4.1 Flash als schnelles, kosteneffizientes Modell mit nativer Tool-Unterstützung. Der Anbieter verwendet Peak- und Off-Peak-Preise; ausserhalb der Spitzenzeiten liegen die Preise bei der Hälfte des Peak-Niveaus.

Für mich ist DeepSeek deshalb derzeit eher ein günstiger Agent als ein simpler Batch-Worker.

Ein realistischer Online-Marketing-Workflow könnte beispielsweise so aussehen:

1. mehrere Exporte einlesen,
2. relevante Spalten erkennen,
3. Daten zusammenführen,
4. Abweichungen berechnen,
5. Problemfälle isolieren,
6. Resultate gegenprüfen,
7. einen strukturierten Bericht erzeugen.

Sobald eine Aufgabe mehrere Werkzeuge und Zwischenschritte benötigt, wird Tool-Disziplin relevanter.

Gemini 3.5 Flash-Lite: ein Worker muss nicht das ganze Projekt sehen

Gemini 3.5 Flash-Lite habe ich bewusst anders eingebunden.

Es ist bei mir kein vollständiger Ersatz für Claude Code, sondern ein isolierter Worker.

Getestet habe ich unter anderem:

• Klassifizieren
• Extrahieren
• Zusammenfassen
• Umschreiben
• Drafting

Google positioniert Gemini 3.5 Flash-Lite als kostengünstiges Modell für Workloads mit hohem Durchsatz. Das Modell unterstützt ein Kontextfenster von einer Million Tokens. Google nennt aktuell 0,30 US-Dollar pro Million Input-Tokens und 2,50 US-Dollar pro Million Output-Tokens im Paid Tier.

Das Worker-Prinzip hat noch einen weiteren Vorteil.

Ein Modell, das beispielsweise 5.000 Kundenbewertungen kategorisieren soll, braucht nicht automatisch Zugriff auf:

• das gesamte Dateisystem,
• Werbekonten,
• WordPress,
• Google Drive,
• Credentials,
• oder andere MCPs.

Es bekommt nur die Daten, die für seine Aufgabe erforderlich sind.

Damit wird Multi-Model-Routing gleichzeitig zu einem Berechtigungskonzept.

Qwen 3.8 Flash: nicht zwingend besser, aber unabhängig

Auch Qwen 3.8 Flash löste meinen Multi-Step-Test korrekt:

186,10 Euro.

Das Modell benötigte sieben Turns und machte einen unnötigen Shell-Versuch.

Vier Testaufrufe zusammen kosteten bei mir ungefähr sieben Cent.

OpenRouter listet Qwen 3.8 Flash aktuell mit einem Kontextfenster von einer Million Tokens und Tool Calling. Die ausgewiesenen Preise liegen bei 0,15 US-Dollar pro Million Input-Tokens und 0,47 US-Dollar pro Million Output-Tokens.

Warum also noch ein weiteres Modell?

Vor allem wegen Redundanz.

Ein automatisierter Marketingprozess, der vollständig von einem einzigen Modellanbieter abhängt, besitzt einen neuen Single Point of Failure.

APIs können ausfallen. Modelle können ersetzt werden. Rate Limits können sich ändern. Anbieter können Accounts unterschiedlich behandeln.

Eine zweite Provider-Strecke kann deshalb einen Wert haben, selbst wenn ihr Modell bei der eigentlichen Aufgabe nicht besser ist.

Warum nicht einfach Claude Haiku 4.5?

Man könnte die gesamte Architektur wesentlich einfacher halten und innerhalb des Claude-Ökosystems bleiben.

Claude Haiku 4.5 ist direkt in Claude Code verfügbar. Anthropic positioniert es ausdrücklich für hohe Volumina, Subagents und Coding-Aufgaben. Der API-Preis liegt aktuell bei 1 US-Dollar pro Million Input-Tokens und 5 US-Dollar pro Million Output-Tokens.

Das hat klare Vorteile:

• native Integration
• weniger Konfiguration
• kein zusätzlicher Provider
• weniger Compatibility Layer
• konsistenteres Tooling
• einfacheres Berechtigungsmanagement

Dass sich Claude Code im PPC-Alltag inzwischen auch mit funktionsspezifischen Plugins erweitern lässt, zeigt der Beitrag zum Google Ads API Developer Assistant als Claude-Code-Plugin.

Für viele Unternehmen dürfte das der sinnvollere Einstieg sein.

Externe Modelle werden interessant, wenn zusätzliche Ziele hinzukommen:

• sehr niedrige Kosten,
• grosse Batch-Volumen,
• spezifische Modellstärken,
• Provider-Redundanz,
• oder besonders grosse Kontextfenster.

Die Idee, unterschiedliche Modelle für unterschiedliche Aufgaben zu orchestrieren, ist auch innerhalb des Claude-Ökosystems etabliert: Anthropic nennt Haiku 4.5 ausdrücklich als Modell für Coding-Subagents, während stärkere Claude-Modelle komplexere Planung übernehmen können.

Was das konkret im Online Marketing bedeutet

Multi-Model-Routing ist nicht speziell ein PPC-Thema.

Die Logik lässt sich auf praktisch alle Online-Marketing-Disziplinen übertragen.

Paid Search: Search-Term-Klassifikation, Kampagnentaxonomien, Change-Log-Analyse und Datenaufbereitung können günstige Worker übernehmen. Strategische Strukturentscheidungen bleiben beim stärkeren Modell.

SEO: Tausende URLs können nach Seitentyp oder Suchintention kategorisiert werden. Technische Regeln wie Statuscodes oder Canonical-Abweichungen sollten dagegen deterministisch geprüft werden. Die Entscheidung, welche Seiten konsolidiert werden sollten, benötigt wiederum mehr Urteil.

Content: Ein günstiges Modell kann Quellen strukturieren, Briefings zusammenfassen oder vorhandene Inhalte kategorisieren. Ein stärkeres Modell kann daraus einen finalen Fachartikel entwickeln.

CRM und Reviews: Themen, Sprache oder grobe Kategorien lassen sich in grossen Mengen klassifizieren. Rechtlich sensible oder kritische Kundenfälle können gezielt an eine manuelle Prüfung weitergeleitet werden.

Reporting: Ein Worker kann Tausende Zeilen nach Mustern untersuchen. Berechnungen und Schwellenwerte sollten danach mit Code validiert werden. Was ein Report am Ende für Menschen leisten muss, ändert sich dadurch nicht – dazu mehr im Beitrag zu AdWords-Reports.

Die bessere Architektur: LLM für Bedeutung, Code für Kontrolle

Genau an dieser Stelle liegt für mich der eigentliche Hebel.

Ein Multi-Model-System sollte nicht einfach billige LLMs an die Stelle teurer LLMs setzen.

Es sollte Aufgaben so strukturieren, dass Fehler erkannt werden können.

Bei einer Search-Term-Klassifikation:

LLM: versteht den Suchbegriff und vergibt die Kategorie.

Code: kontrolliert Zeilenzahl, IDs, erlaubte Kategorien und Duplikate.

Bei Anzeigen:

LLM: entwickelt Varianten.

Code: prüft Zeichenlängen, Duplikate und formale Vorgaben.

Bei einem Import:

Agent: überträgt die Struktur.

Code oder API-Prüfung: kontrolliert Kampagnenzahl, Budgets, Status und Einstellungen.

Beim Import von Kampagnen zwischen Plattformen gilt dasselbe Prinzip: Automatisierung ersetzt nicht die Prüfung des Ergebnisses. Das ist beispielsweise auch beim Google-Import in Microsoft Advertising relevant.

Die Kurzform lautet:

LLM für Bedeutung. Deterministische Systeme für Kontrolle.

Und woher weiss ich, ob das Routing überhaupt benutzt wird?

Nachdem ich das Modell-Routing aufgebaut hatte, entstand noch ein anderes Problem.

Eine Policy kann sagen:

• Routine → GLM
• Batch → Gemini
• Multi-Step → DeepSeek
• Backup → Qwen
• komplexe Entscheidung → Sonnet

Aber folgt der Agent dieser Policy im Alltag tatsächlich?

Oder steht die Routing-Matrix nur in einer Dokumentation, während weiterhin fast alles mit dem Session-Modell erledigt wird?

Deshalb habe ich zusätzlich ein lokales Routing-Audit eingerichtet.

Bei einem tatsächlichen Aufruf eines zusätzlichen Modells werden nur technische Metadaten gespeichert:

• Zeitpunkt
• Projekt
• Modell
• Provider
• Laufzeit
• Erfolg oder Fehler

Nicht gespeichert werden Prompt, Antwort, Dateiinhalte oder API-Keys.

Ein normales PowerShell-Script erstellt daraus einen 7- oder 30-Tage-Report. Dafür wird bewusst kein weiteres KI-Modell benötigt.

Zum Zeitpunkt dieses Artikels zeigt der Produktivreport erst einen einzigen externen Modellaufruf seit Einführung des Audits – einen kontrollierten GLM-Test.

Das ist noch keine Nutzungsstatistik.

Aber genau darum geht es.

Wenn der Report nach einigen Wochen weiterhin fast leer bleibt, weiss ich, dass die Routing-Architektur zwar technisch existiert, praktisch aber kaum eingesetzt wird.

Wenn dagegen Dutzende Aufgaben über günstige Worker laufen, lässt sich erstmals messen, was das Routing tatsächlich bringt.

Multi-Model-Routing sollte nicht zum Selbstzweck werden

Es wäre leicht, aus all dem den falschen Schluss zu ziehen:

Je mehr Modelle, desto besser.

Das Gegenteil kann der Fall sein.

Jeder zusätzliche Provider bedeutet:

• zusätzliche Credentials
• zusätzliche Fehlerbilder
• zusätzliche Kostenmodelle
• zusätzliche Datenschutzfragen
• zusätzliche Wartung

Ein Team, das drei KI-Aufgaben pro Woche erledigt, braucht keine Infrastruktur mit fünf Modellen.

Interessant wird Routing dort, wo AI-Workflows häufiger, autonomer und volumenstärker werden.

Dann lohnt es sich, über Rollen nachzudenken.

Nicht:

Welches ist das beste Modell?

Sondern:

Was ist das kleinste und günstigste System, das diese konkrete Aufgabe zuverlässig erledigen kann?

Fazit

Die spannendste Erkenntnis aus meinen bisherigen Tests ist nicht, dass eines der getesteten Modelle „gewonnen“ hätte.

GLM, DeepSeek und Qwen lieferten bei meiner identischen Multi-Step-Aufgabe alle dasselbe korrekte Ergebnis.

Sie unterschieden sich vor allem darin, wie effizient und diszipliniert sie dorthin kamen.

Gemini wiederum erfüllt in meiner Architektur eine ganz andere Rolle als isolierter Batch-Worker.

Claude bleibt die Steuerungsebene für schwierigere und schwer überprüfbare Aufgaben.

Damit verändert sich auch die Frage, die Online-Marketing-Teams beim Einsatz von KI stellen sollten.

Nicht mehr nur:

Welches KI-Modell sollen wir verwenden?

Sondern:

Welche Teile unseres Prozesses brauchen überhaupt ein starkes Modell – welche können günstigere Worker übernehmen, und welche sollten wir lieber mit normalem Code lösen?

Je mehr KI vom Chatfenster in echte Arbeitsprozesse wandert, desto wichtiger wird diese Unterscheidung.

Das eigentliche Ziel ist nicht, möglichst viele Modelle einzusetzen.

Es ist, für jeden Arbeitsschritt gerade so viel KI einzusetzen, wie tatsächlich notwendig ist.