Was wir im Juli 2026 veröffentlicht haben

Im Juni standen Zugriffs- und Betriebsfunktionen im Mittelpunkt. Im Juli folgte die Infrastruktur der Agenten. Connic KI-Modelle bündeln 30 EU-gehostete Modelle von neun Anbietern hinter einheitlichen IDs, die in einer Zeile YAML angegeben werden. Das Projektguthaben bündelt die Abrechnung für alles, was in einem Projekt genutzt wird. Der Marketplace ist jetzt der zentrale Katalog für Templates, Verbindungen und Retrieval Sources. Das Deploy Gate kann nun außerdem Human Approvals vorab festlegen und Lifecycle-Code mocken. Retries für KI-Modell-Requests starten den Agenten nicht mehr neu, lange Sessions werden komprimiert statt überzulaufen, und ein neuer KI-Governance-Workspace dokumentiert die Vorbereitung auf den EU AI Act in exportierbaren Nachweisen.

Connic KI-Modelle mit verwalteter EU-Inferenz

Connic KI-Modelle bündeln 30 Modelle von neun Anbietern hinter einheitlichen connic/* IDs, die jedes Projekt sofort nutzen kann. Die Angabe einer solchen ID in der Agenten-YAML genügt für ein Deployment über unseren verwalteten Provider-Zugang und das Region-Routing. Jeder Call läuft über Inferenzkapazität in der EU; Request-Retries und providerübergreifendes Failover übernehmen wir.

model: connic/glm-5.2

# or a latency-optimized execution profile:
# model: connic/kimi-k3-fast

Es muss kein Key erstellt, eingefügt oder rotiert werden: Managed Tokens werden direkt vom Projektguthaben zu den veröffentlichten EUR-Preisen des jeweiligen Modells abgerechnet. BYOK bleibt für Projekte mit eigenem Provider verfügbar. Modelle mit einer -fast ID werden zum gleichen Preis auf latenzoptimierte Kapazität geroutet. Outputs können von der Standard-ID abweichen. Der Wechsel sollte daher wie ein Modellwechsel behandelt und getestet werden.

Mehr dazu steht in der Ankündigung zu Connic KI-Modellen sowie im Modellkatalog mit den genauen IDs und Preisen.

Projektguthaben für die zentrale Abrechnung

Die Abrechnung läuft jetzt über Projektguthaben. Es deckt alles ab, was ein Projekt verbraucht: Runs, Compute, Storage, synchronisierte Retrieval Items und Tokens der connic/*-KI-Modelle. Das erste Basic-Projekt eines Accounts startet mit einmalig €20 Willkommensguthaben und kann danach weiter aufgeladen werden. Ein Developer- oder Pro-Abo stellt den gewählten Monatsbetrag als Projektguthaben bereit. Die Tarife bieten bei wachsender Nutzung zusätzliche Features und höhere Limits. Für Enterprise-Projekte gelten weiterhin individuelle Vertragskonditionen.

Standardprojekte sind prepaid: Die Nutzung stoppt, wenn das Guthaben nicht ausreicht. Ein begrenztes Auto-Refill lädt es vorher auf, ohne jemals das gesetzte Limit zu überschreiten. Alle Tarife stehen zentral auf der Pricing-Seite; die Usage-Dokumentation zeigt, wie der Verbrauch auf das Guthaben angerechnet wird.

Der Connic Marketplace

Der Marketplace ist Anfang des Monats als zentraler Katalog für Bausteine von Connic-Projekten gestartet. Wir veröffentlichen jeden Eintrag; alle lassen sich kostenlos installieren. Derselbe Katalog ist auf der Website und im Dashboard verfügbar.

connic init my-project --templates=invoice

Mehr dazu steht in der Marketplace-Ankündigung. Alle Einträge stehen im Marketplace.

Tests mit vordefinierten Freigabeentscheidungen und Lifecycle-Mocks

Das Deploy Gate kann jetzt Flows mit ausstehender menschlicher Freigabe testen. approval_decisions legt das Ergebnis eines ausstehenden Tool Approvals vorab fest. So kann ein Testfall prüfen, was passiert, wenn eine Rückerstattung genehmigt, abgelehnt oder durch einen Timeout beendet wird, ohne dass jemand klicken muss. Dasselbe Mock-Modul, das bereits Custom Tools ersetzt, kann nun auch Middleware-Phasen, Tool Hooks und Custom Guardrails ersetzen. Ergebnisse werden außerdem live gestreamt: Jeder Testfall meldet sich direkt nach Abschluss statt erst nach der gesamten Suite.

tests:
  - name: approves_refund_then_rejects_notification
    builder: create_charge_then_refund
    approval_decisions:
      - tool: billing.refund
        params: params.charge_id == context.charge_id
        decision: approve
      - tool: notifications.send
        decision: reject
        reason: Do not send notifications in this scenario

• •Genehmigung, Ablehnung oder Timeout: Jeder Zweig eines Approval-Flows wird zu einem Testfall, der dem Tool und optional den Parametern zugeordnet wird
• •Strict Lifecycle Flags: strict_hook_mocks, strict_middleware_mocks und strict_guardrail_mocks lassen einen Testfall jeweils fehlschlagen, bevor eine nicht gemockte reale Phase ausgeführt wird. Fehlt ein Mock, schlägt der Test eindeutig fehl, statt unbemerkt echten Code auszuführen
• •GitLab-Unterstützung: Self-managed GitLab Instances werden per Personal Access Token verbunden, und Merge-Request-Tests melden den Status connic/pr-tests vor dem Merge

Alle Regeln stehen in der Test-YAML-Dokumentation und in der Referenz zu Fixtures und Mocks.

A/B Testing: Confidence Mode

A/B Tests gibt es jetzt in zwei Varianten, passend zu unterschiedlichen Fragestellungen.

Die A/B-Testing-Dokumentation beschreibt beide Modi.

Retries, die den Agenten nicht neu starten

Wenn ein Provider während eines Runs einen vorübergehenden Fehler zurückgibt, wiederholen wir jetzt genau diesen KI-Modell-Request. Bereits ausgeführte Tools laufen nicht erneut, und Middleware wird nicht wiederholt. Dadurch werden bei einer kurzen Provider-Störung bereits ausgeführte Aktionen nicht noch einmal ausgelöst. Ein konfiguriertes Fallback-KI-Modell übernimmt den fehlgeschlagenen Aufruf. Die neue Option initial_delay legt die Wartezeit vor dem ersten Wiederholungsversuch fest. Die bestehenden Limits für die Anzahl der Versuche und die maximale Wartezeit gelten weiterhin.

retry_options:
  attempts: 3
  initial_delay: 5
  max_delay: 30

Jeder Wiederholungsversuch erscheint im Trace als eigener Span auf derselben Ebene wie der ursprüngliche Aufruf, einschließlich der Angaben zur Wartezeit. Fehlermeldungen des Providers bleiben vollständig erhalten und werden nicht durch eine allgemeine Meldung ersetzt. Die vollständige Referenz steht unter Ausführungseinstellungen.

Kontextkomprimierung für lange Sessions

Lang laufende Agenten scheitern nicht mehr am Kontextfenster. Tritt ein Kontextlimit-Fehler beim Provider auf, komprimiert der Runner ältere Verlaufsdaten und zu große Tool-Ergebnisse und wiederholt anschließend den Call. keep_recent_messages behält die neuesten Turns unverändert bei. Ein optionaler Grenzwert für max_prompt_tokens komprimiert proaktiv vor einem späteren Call, statt erst auf einen Fehler zu warten.

context_compression:
  enabled: true
  model: connic/glm-5.2
  keep_recent_messages: 12
  session_history:
    interval: 4
    keep_recent_runs: 1

session_history verdichtet die gespeicherte History nach einem festgelegten Intervall zwischen Runs und lässt die neuesten Runs unverändert. Beide Pfade können ein kleineres dediziertes Modell für Zusammenfassungen verwenden, während normale Calls auf dem KI-Modell des Agenten bleiben. Jede Komprimierung erscheint als eigener Trace-Span mit Tokenzahlen. Die Vertiefung zu Kontextkomprimierung beschreibt die Pipeline im Detail.

Traces für einzelne KI-Modell-Aufrufe und Ergebnisse der Guardrail-Prüfungen

Jeder KI-Modell-Call in einem Run erhält jetzt einen eigenen Trace-Span mit zugehöriger Token-Nutzung: Input, Output, Thinking und Cached Input werden als kompakte Anzeige an jedem Span in den Run-Details angezeigt. Lange Agenten-Loops erscheinen damit nicht mehr als einzelne undurchsichtige Zahl, sondern als Folge einzeln prüfbarer Calls.

Guardrail-Eingriffe werden jetzt direkt am Run gespeichert und in der Runs-Tabelle als filterbare Ergebnisse angezeigt. Alle blockierten Injection-Versuche sind nun mit einem Filter auffindbar, ohne die Run-Details einzeln durchsuchen zu müssen.

Automatische Bridge Routes

Manche Protokolle verbinden sich mit einem Service und erhalten für die nächste Verbindung einen anderen Hostnamen, etwa von Redis Sentinel für den aktuellen Master, aus Kafka Metadata oder von Database-Failover-Clients. Bisher musste bei diesem Verbindungswechsel das Bridge-Suffix am zurückgegebenen Ziel stehen, dessen Name häufig nicht geändert werden kann. Automatische Routes lösen das: Pro Bridge werden genaue Hostnamen oder eine sichere Regex definiert. Passender Traffic aus dem Anwendungscode wird dann über die Bridge geroutet, während die üblichen Hostnamen unverändert bleiben.

{
  "routes": [
    {
      "match_type": "exact",
      "target": "redis-sentinel.internal",
      "port": 26379
    },
    {
      "match_type": "regex",
      "target": "^redis-[a-z0-9-]+\\.internal$",
      "port": 6379
    }
  ]
}

Routes lassen sich unter Projekt-Settings im Bereich Bridge oder über die Routes-API konfigurieren. Explizite Bridge-Hostnamen haben Vorrang, danach folgen Routen für exakte Hostnamen und schließlich Regex-Routen. Regex-Ziele akzeptieren nur eng gefasste Muster, die den vollständigen Hostnamen abgleichen. Die Bridge-Dokumentation enthält eine vollständige Anleitung für Redis Sentinel.

KI-Governance für den EU AI Act

Enterprise-Projekte erhalten einen neuen KI-Governance-Workspace, der die Vorbereitung auf den EU AI Act für Agenten, Runs und Deployments als fortlaufenden Nachweis abbildet. Dort lassen sich KI-Systeme registrieren, vorläufige Bewertungen der Rolle als Anbieter oder Betreiber dokumentieren und die daraus abgeleiteten Maßnahmen bis zum Abschluss verfolgen. Das ist ein Workflow für Dokumentation und Nachweise, keine rechtliche Einordnung: Die endgültige Klassifizierung bleibt beim Unternehmen und seiner Rechtsberatung.

• •Abgegrenzte Nachweise: Ein Snapshot erfasst ein System, ausgewählte Environments und ein Zeitfenster. Er lässt sich als unveränderliches, hash-verifiziertes Archiv für Auditoren und Rechtsberatung exportieren
• •Artikel 50 an einem Ort: Dokumentiert, wie Offenlegungspflichten erfüllt werden, einschließlich Bestätigungen der vorgelagerten Anbieter
• •Incidents eingeschlossen: Erfasst und verfolgt Incidents, damit die Nachweiskette das tatsächliche Geschehen abbildet

Der Zugang ist über den zuständigen Account Manager erhältlich. Die KI-Governance-Dokumentation beschreibt den vollständigen Workflow.

Weitere Verbesserungen

• •Retrieval: Die Knowledge Base heißt jetzt produktweit Retrieval. Bestehende Config-Keys und Tool-Namen funktionieren weiterhin, und Namespaces lassen sich inklusive untergeordneter Namespaces direkt im Dashboard löschen
• •Eigene Dashboard-Seite: Dashboards auf einer eigenen Seite erstellen, sortieren und löschen sowie bis zu 15 davon an die Sidebar heften
• •Selektive Drains: Log- und Audit-Drains akzeptieren eine filter_expression, die bereits beim Tippen validiert wird, und leiten nur passende Einträge weiter
• •Markdown Tables: Run-Details rendern Tabellen im Agenten-Output, etwa für Agenten, die Berichte erzeugen
• •Judges stapelweise auslösen: Für einen Judge einen Datumsbereich wählen, die Zahl der Runs vorab prüfen und den gesamten Batch über die Judge-Seite auslösen
• •Sensitive Variables im Raw Editor: Einer Zeile im Raw Environment Editor ein ! voranstellen, wie in !API_KEY=value, um sie als sensibel zu markieren
• •Strukturierte Trigger Payloads: trigger_agent und trigger_agent_at akzeptieren Dicts und Listen nativ. Orchestrierungscode kann damit strukturiertes JSON ohne Umwandlung in Strings übergeben
• •Neu strukturierte Dokumentation: Die Dokumentation ist jetzt in Build, Test, Platform, Verbindungen und Reference gegliedert