Heute veröffentlichen wir Connic KI-Modelle: 30 Modelle von neun Providern hinter einheitlichen IDs, die jedes Projekt sofort nutzen kann. Eine Zeile in der Agenten-YAML gibt das KI-Modell an. Provider-Konto, API-Key und Regionsangabe entfallen. Jeder Aufruf läuft auf Inferenzkapazität in der EU.
Dieses Release wollten wir bereits seit dem Start von Connic veröffentlichen. Bisher mussten Entwickler ihre eigentliche Arbeit unterbrechen, um ein Konto bei einem KI-Modell-Provider zu eröffnen, eine Karte zu hinterlegen, einen API-Key zu erzeugen und ihn in jedes Environment einzufügen. Anschließend mussten sie prüfen, ob der bereitgestellte Endpunkt in der EU lag. Dieser Umweg ist jetzt optional.
Was sind Connic KI-Modelle?
Wir stellen Connic KI-Modelle jedem bereitgestellten Projekt unter dem Präfix connic/ auf Inferenzkapazität in der EU bereit. Zur Auswahl wird die exakte Katalog-ID in das Feld model eines Agenten geschrieben. Dasselbe Feld nimmt auch Provider-Präfix und KI-Modell-ID auf. Die Nutzung wird vom Projektguthaben abgerechnet, dem Guthaben für Runs, Compute, Storage und Retrieval.
„Managed“ bedeutet hier: Eine connic/*-ID bietet einen veröffentlichten Preis, eine Konfigurationszeile, eine Rechnung und einen in einer Tabelle dokumentierten Funktionsumfang. Ein separates Provider-Konto oder die Verwaltung von Provider-Zugangsdaten ist nicht erforderlich.
Connic KI-Modelle ergänzen Bring Your Own Key und eigene OpenAI-kompatible Endpoints als dritte Option. Jede der drei Optionen kann als primäres KI-Modell oder als Fallback eines Agenten dienen:
| Von Connic verwaltet | Bring Your Own Key | Eigener Endpoint | |
|---|---|---|---|
| Konfigurationswert | connic/glm-5.2 | anthropic/claude-sonnet-4-6 | vllm/mistral-7b |
| Einrichtung | Keine, standardmäßig aktiv | Provider-Zugangsdaten zum Projekt hinzufügen | Präfix wählen und auf eine Basis-URL richten |
| Wer Tokens abrechnet | Connic, über Projektguthaben | Der Provider über das zugehörige Konto | Niemand; das Unternehmen betreibt den Server |
| Wo Inferenz läuft | Nur EU | Wo der Provider sie betreibt | Wo das Unternehmen sie hostet |
| Rate Limits | Von Connic verwaltet | Der Provider-Vertrag | Die Hardware des Unternehmens |
Funktioniert als fallback_model | Ja | Ja | Ja |
Ein Projekt kann alle drei kombinieren. Ein verwaltetes primäres KI-Modell mit BYOK-Fallback ist ebenso möglich wie der umgekehrte Weg:
version: "1.0"
name: refund-agent
type: llm
description: Reviews refund requests and drafts a decision
system_prompt: |
Review the refund request and draft a decision.
model: connic/glm-5.2
fallback_model: connic/gpt-5.6-terra # oder anthropic/claude-sonnet-4-6 mit konfiguriertem Anthropic BYOK
temperature: 0.3
reasoning_effort: highWelche KI-Modelle enthält der Katalog?
Stand 30. Juli 2026 enthält der Katalog 30 KI-Modelle von neun Providern: Anthropic, Google, Meta, MiniMax, Mistral, Moonshot AI, OpenAI, Qwen und Z.ai. Open-weight KI-Modelle stehen neben gehosteten proprietären KI-Modellen, und jeder Eintrag nennt seine Lizenz. Dadurch ist sofort erkennbar, ob sich ein KI-Modell auch auf eigener Infrastruktur betreiben lässt.
Die Bandbreite ist bewusst gewählt. Zweiundzwanzig Einträge akzeptieren Bild-Input, drei Audio und zweiundzwanzig unterstützen Reasoning, davon siebzehn mit einer einstellbaren Reasoning-Stufe. Ein kleines Vision-KI-Modell kann damit gescannte Rechnungen vorsortieren, während ein besonders leistungsfähiges Reasoning-Modell eine anspruchsvolle Entscheidung übernimmt: beide im selben Projekt, beide in YAML benannt. Sechs Einträge zeigen die Bandbreite:
| KI-Modell-ID | Provider und Lizenz | Context | Inputs | Reasoning Effort |
|---|---|---|---|---|
| connic/mistral-small-3.2-24b-instruct-2506 | Mistral, Apache-2.0 | 128k | Text, Bild | nicht unterstützt |
| connic/qwen3.6-35b-a3b | Qwen, Apache-2.0 | 256k | Text, Bild | none, low, medium, high |
| connic/glm-5.2 | Z.ai, MIT | 256k | Text | none, high, max |
| connic/gemini-3.5-flash | Google, Provider Terms | 1M | Text, Bild, Audio | low, medium, high |
| connic/claude-sonnet-5 | Anthropic, Provider Terms | 1M | Text, Bild | low, medium, high |
| connic/gpt-5.6-sol | OpenAI, Provider Terms | 1M | Text, Bild | low, medium, high |
Der vollständige Katalog der Connic KI-Modelle enthält jede ID, ihren Funktionsumfang und ihre Limits, den Preis pro Token und das Datum der letzten Aktualisierung. Er ist durchsuchbar, nach Provider filterbar und nach Preis oder Kontextfenster sortierbar.
Für das Deployment reicht ein connic/* KI-Modell im Agenten-YAML. Provider-Konto, API-Key und Regionsangabe entfallen.
Jetzt entwickelnInferenz ausschließlich in der EU
Dieser Teil ist uns am wichtigsten und eine feste Vorgabe für den Katalog. Es muss keine Region angegeben werden, und hinter der KI-Modell-ID gibt es keinen weltweiten Fallback. Jede Anfrage an connic/* geht ausschließlich an EU-Inferenzkapazität. Kann diese Grenze für ein KI-Modell nicht eingehalten werden, wird es aus dem Katalog entfernt oder der Aufruf wird sicher abgebrochen. Er wird nicht still an einen anderen Ort geroutet.
Die Kennzeichnungen unterscheiden zwischen Inferenzstandort und Herkunft des Providers. Eine Beschaffungsprüfung muss beide Fragen klären.
Die Verteilung im Katalog zeigt, welche Optionen dafür bestehen. Einundzwanzig der 30 Einträge tragen überhaupt kein Label für einen nicht EU-nativen Provider. Zehn davon stehen unter einer offenen oder Source-available-Lizenz: Apache-2.0, MIT, Modified MIT, Llama 3.3 Community und Kimi K3 License. Damit kann eine gesamte Agenten-Flotte auf EU-nativer Kapazität und Open Weights laufen. Für einzelne Aufgaben bleibt ein entsprechend gekennzeichnetes Frontier-KI-Modell verfügbar. Unser Leitfaden zum EU-Betrieb ohne US-Hyperscaler beschreibt die Anforderungen, wenn eine US-Cloud ausgeschlossen sein muss.
Die Garantie hat eine klare Grenze: Die connic/*-Garantie deckt den KI-Modell-Call ab. Ein Projekt ist vollständig EU-resident, wenn auch seine Deployment-Region und jede konfigurierte Komponente (BYOK-Provider, Tools, Guardrails, Judges und externe Datenziele) EU-resident sind. Unser Leitfaden zur Datenresidenz beschreibt die gesamte Agentenplattform. Ergänzend vergleicht unser Überblick über EU-gehostete KI-Modelle die Provider und Deployment-Optionen.
Eine ID, die hält, was sie verspricht
Eine Managed KI-Modell-ID, die still auf ein neues Ziel zeigt, wäre schlimmer als gar keine Managed KI-Modelle auszuliefern. Tests, Judge-Scores und Kostenvergleiche würden jede Aussagekraft verlieren, ohne einen klaren Hinweis auf den Zeitpunkt der Änderung. Deshalb ist die Zusage explizit: Jede connic/*-ID verweist auf das neben ihr im Katalog genannte KI-Modell und bleibt dabei. Wird ein KI-Modell eingestellt, kündigen wir die Änderung an, bevor die ID verschwindet. Ein Deployment tauscht nie das getestete KI-Modell aus.
Rate Limits, Timeouts und Provider-Ausfälle gehören zum Alltag, sobald Agenten rund um die Uhr laufen. Wir behandeln Fehler daher am KI-Modell-Call, statt den vollständigen Run zu wiederholen:
fallback_model des Agenten übernimmt, ob Managed oder BYOK. Runs mit einem Wechsel erhalten ein Tag. Eine Filterung der Run List nach context.fallback_model_used zeigt exakt, wie oft ein Provider in der vergangenen Woche ausgefallen ist.Zwei Vorteile einer Managed ID
Fast-IDs für geringere Latenz
Sieben KI-Modelle bieten eine zusätzliche ID mit dem Suffix -fast: dasselbe KI-Modell über einen latenzoptimierten Ausführungspfad, zum gleichen Preis. Zwei weitere, beide Kimi-KI-Modelle, werden nur über diesen Pfad angeboten; bei ihnen ist -fast schlicht Teil der ID. Das Suffix ist die Zusage: Trägt eine ID es nicht, wird das KI-Modell nicht auf diese Weise bereitgestellt.
Fast-IDs haben zwei Einschränkungen, die vor dem Produktivbetrieb berücksichtigt werden sollten.
Die erste betrifft den Kompromiss zugunsten der Geschwindigkeit. Eine Fast-ID kann über ein quantisiertes Deployment des KI-Modells bereitgestellt werden. Das senkt die Latenz, kann aber dazu führen, dass sich die Ausgaben beim selben Prompt von der Standard-ID unterscheiden. Quantisierung ist ein Qualitätskompromiss, kein kostenloser Gewinn. Ein Wechsel sollte deshalb wie ein KI-Modell-Wechsel behandelt werden: Die Tests des Agenten werden erneut ausgeführt, und qualitätskritische Schritte bleiben auf der Standard-ID, bis die Fast-ID nachweislich mithält. Ein A/B-Vergleich liefert diesen Nachweis am günstigsten, weil er beide Seiten mit produktivem Traffic bewertet.
Außerdem kann eine Fast-ID in drei Bereichen stärker eingeschränkt sein als ihre Standardvariante: weniger Reasoning-Stufen, ein kleineres Kontextfenster oder weniger Eingabetypen. connic/glm-5.2-fast akzeptiert nur high, während die Standard-ID auch none und max akzeptiert, und connic/qwen3.5-397b-a17b-fast akzeptiert nur Text, während die Standard-ID auch Bilder liest. Drei der sieben zusätzlichen IDs entsprechen exakt ihrer Standardvariante; das Info-Symbol neben jeder Fast-ID nennt alle Unterschiede.
Reasoning Effort, der einen KI-Modell-Wechsel übersteht
Jeder Provider benennt und skaliert seine Reasoning-Steuerung anders. In Connic gibt es dafür ein Feld: reasoning_effort. Wir übersetzen die gesetzte Stufe in die vom zugrunde liegenden KI-Modell erwartete Form. Die akzeptierten Werte jedes verwalteten KI-Modells stehen im Katalog; auto überlässt die Entscheidung wieder dem KI-Modell.
Der Vorteil zeigt sich beim Wechsel. Eine Änderung der KI-Modell-Zeile erfordert keine Neufassung eines providerspezifischen Parameters daneben. Erfasstes Reasoning erscheint weiterhin im Ausführungs-Trace, wenn das jeweilige KI-Modell es zurückgibt. Die Dokumentation zu Runs und Traces beschreibt die Details.
Wie wird die Nutzung verwalteter KI-Modelle abgerechnet?
Tokens für verwaltete KI-Modelle werden vom Projektguthaben abgezogen, das auch für Runs, Compute, Storage und Retrieval gilt. So werden die Betriebskosten eines Agenten aus einem gemeinsamen Guthaben bezahlt. Input, Output, Thinking und Cached Input werden pro KI-Modell unabhängig bepreist; der Katalog zeigt die aktuellen Preise neben jeder ID.
KI-Modellwechsel mit Tests absichern
Ein günstigeres KI-Modell im Katalog senkt die Kosten erst, wenn es die Qualitätsanforderungen erfüllt. Dafür stehen in Connic drei Werkzeuge bereit, die auch mit verwalteten KI-Modellen funktionieren:
Kostenwarnungen und feste Limits gelten in beiden Fällen: global, pro Environment oder pro Agent und täglich oder monatlich. Bei aktivierter Anomalieerkennung löst eine Ausführung, die weit mehr kostet als der 30-Tage-Durchschnitt dieses Agenten, selbstständig eine Warnung aus. Der vollständige Ablauf für A/B-Tests einer Agentenänderung und die Usage- und Budget-Dokumentation enthalten alle Details.
BYOK bleibt
Wir haben verwaltete KI-Modelle entwickelt, um den Einstieg zu vereinfachen. Ausgaben für KI-Modelle, die bereits durch einen ausgehandelten Provider-Vertrag abgedeckt sind, können dort bleiben. Teams mit einem Fine-Tuning auf eigener Hardware können ein eigenes Präfix darauf richten und es über eine Bridge ohne eingehende Ports erreichen. Verwaltete KI-Modelle und BYOK sind gleichwertige Optionen im selben YAML-Feld; jedes Observability-, Testing- und Budgeting-Feature behandelt sie gleich.
Dabei gilt weiterhin eine Grenze: connic/* KI-Modelle sind Teil der bereitgestellten Connic Runtime und keine öffentliche KI-Modell-API für direkte Aufrufe. Sie dienen der Ausführung von Agenten.
Erste Schritte mit Connic KI-Modellen
- 1.Den Katalog der Connic KI-Modelle durchsuchen und eine exakte ID wählen, gefiltert nach Provider und sortiert nach Preis
- 2.Die ID als
modelin einer Agent-Datei oder in_defaults.yamlsetzen, um jeden Agenten in diesem Verzeichnis und darunter zu ändern - 3.Agenten bereitstellen; Provider-Konto, API-Key und Regionsangabe entfallen
- 4.Vor produktivem Traffic Auto-refill aktivieren und ein Spend Limit für den Agenten setzen
Für Teams, die Connic erstmals einsetzen, beschreibt der Quickstart das Deployment des ersten Agenten, ohne dass ein API-Key eines anderen Providers nötig ist. Die Dokumentation zu KI-Modellen und Providern erklärt jedes Konfigurationsfeld. Die Funktionsseite zur KI-Modell-Auswahl gibt einen Überblick über die Optionen.