Zum Hauptinhalt springen
Connic

Lokal bearbeiten.
In der Cloud ausführen.

connic dev stellt einen isolierten Cloud Runner bereit, lädt das Projekt hoch und beobachtet das lokale Dateisystem. Änderungen erreichen den Runner in 2–5 Sekunden; beim nächsten Aufruf lädt der Agent Loader die neue Version.

Mit Basic startenQuickstart in 5 Minuten
Dev-Server-Dokumentation lesen
zsh — connic dev
~/invoice-bot ❯ connic dev
  agents/ und tools/ werden beobachtet
  mit Dev Runner verbunden · Session a1b2c3d4
  ✓ bereit in 412 ms
  ↻ tools/documents.py geändert
  ✓ invoice-processor in 2,4 s neu geladen
  → invoice-processor #a1b2c3d4
    3 Entitäten geparst und in der Datenbank gespeichert
  ✓ Run in 2,3 s abgeschlossen
❯

Speichern. Synchronisieren. Ausführen.

connic dev beobachtet die Projektverzeichnisse agents/, tools/, middleware/, hooks/ und weitere. Der nächste Agent-Aufruf verwendet die aktuellen Änderungen.

agents/triage.yaml
im Editor speichern
etwa 1 s gebündelt
die CLI lädt geänderte Dateien zum Runner hoch
beim nächsten Aufruf
der Agent Loader führt die neue Version aus

Änderungen erreichen den Runner in 2–5 Sekunden. Dateispeicherungen werden etwa eine Sekunde lang gesammelt und gemeinsam hochgeladen, etwa wenn mehrere Dateien umbenannt werden. Ein vollständiger Neustart ist nicht nötig.

Wenige Befehle, keine Liste von Flags

Die CLI benötigt dafür zwei Befehle: connic dev für eine kurzlebige Session, connic dev <name> für eine persistente.

terminal
connic login

Einmal authentifizieren. Die CLI öffnet das Dashboard für einen API Key und schreibt die Zugangsdaten anschließend in eine .connic-Datei im Projektstammverzeichnis.

terminal
connic dev

Eine kurzlebige Dev Session mit Cloud Runner, Projekt-Upload und Überwachung des lokalen Dateisystems. Wird bei Ctrl+C automatisch gelöscht.

terminal
connic dev my-feature

Mit einem benannten Environment erneut verbinden oder es erstellen. Das benannte Environment bleibt zwischen Sessions mit eigenen Verbindungen und Umgebungsvariablen bestehen.

terminal
connic deploy

Die Auslieferung für den Produktivbetrieb nutzt dasselbe Projekt und dieselben Verbindungen in einem anderen Environment.

Live im Dashboard tracen. Im Terminal testen.

Dev Sessions erscheinen im Dashboard neben den Standard-Environments. Agenten lassen sich über eine Verbindung oder das Dashboard auslösen, der vollständige Trace Stream bleibt in Echtzeit sichtbar und die Test Suite läuft vor dem Ausliefern gegen die aktive Session.

Die Agenten-Ansicht markiert die Dev Session mit dem Badge Dev Session. Dadurch ist sie sofort erkennbar. Run Traces werden live in derselben Struktur wie produktive Runs in der Observability angezeigt.

Dev Sessions sind von anderen Environments isoliert. Ein an die Dev Session gesendeter Webhook kann daher nicht versehentlich die Produktivumgebung auslösen.

Während die Session aktiv ist, führt connic test die Suite gegen denselben Code aus, den der Runner gerade lädt. Nach jedem Speichern ist kein erneutes Deployment nötig.

zsh — connic test
❯ connic test

  12 Testfälle werden gegen die Dev Session ausgeführt...

  ✓ extracts_invoice_total           (5/5 · 312ms avg)
  ✓ handles_missing_vendor_field     (5/5 · 247ms avg)
  ✓ rejects_unsupported_currency     (5/5 · 218ms avg)
  ✗ handles_corrupt_pdf              (3/5 · 894ms avg)
      expected_result failed:
        output.status == "rejected"
      got: "completed"


  11 bestanden, 1 fehlgeschlagen in 8,4 s

Entdecke weitere Features

Composer SDK

Agenten in YAML definieren.

Tools

Vordefinierte Tools, eigenes Python oder MCP.

Storage

Retrieval, Sessions und Datenbank.

Testing

Assertions und Judges in CI.

Environments

Konfiguration und Secrets je Environment.

Observability

Jeden Schritt und jedes Token nachvollziehen.

Häufig gestellte Fragen

Dateiänderungen in den Standardverzeichnissen agents/, tools/, middleware/, hooks/, schemas/, guardrails/ und tests/. Die CLI sammelt Änderungen etwa eine Sekunde lang und lädt sie gemeinsam hoch. Das bündelt zum Beispiel die Umbenennung mehrerer Dateien oder Änderungen durch einen Formatter.

Beides. connic dev erstellt eine kurzlebige Session, die bei Ctrl+C automatisch gelöscht wird. connic dev <name> erstellt ein benanntes Environment oder verbindet sich erneut damit. Das benannte Environment bleibt zwischen Sessions mit eigenen Verbindungen und Umgebungsvariablen bestehen.

Die Authentifizierung beginnt mit connic login. Die CLI öffnet das Dashboard für einen API Key und schreibt die Zugangsdaten anschließend in eine .connic-Datei im Projektstammverzeichnis. Für CI oder gemeinsam genutzte Shells lassen sich auch CONNIC_API_KEY und CONNIC_PROJECT_ID als Umgebungsvariablen übergeben.

Python-Abhängigkeiten werden beim Start der Dev Session installiert. Nach einer Änderung an requirements.txt muss die Session neu erstellt werden.

Ja. Dev läuft in einem eigenen Environment mit eigenen API Keys, Umgebungsvariablen und Verbindungen. Dev Environments werden im Environment Switcher des Dashboards separat gruppiert, damit ein Webhook nicht versehentlich auf die Produktivumgebung verweist.

Nein. Pro benanntem Environment kann nur eine Dev Session aktiv sein. Unterschiedliche Namen oder kurzlebige Sessions ermöglichen paralleles Arbeiten.