Connic

Edit locally.
Run in the cloud.

connic dev provisions an isolated cloud runner, uploads your project, and watches your filesystem. Edits land in the runner in 2-5 seconds, and the agent loader picks them up on the next invocation.

Start Building Free5-minute quickstart
Read the dev server docs
zsh — connic dev
~/invoice-bot ❯ connic dev
  watching agents/ and tools/
  connected to dev runner · session a1b2c3d4
  ✓ ready in 412ms
  ↻ tools/documents.py changed
  ✓ reloaded invoice-processor in 2.4s
  → invoice-processor #a1b2c3d4
    parsed 3 entities, stored to db
  ✓ run completed in 2.3s
❯
The dev loop

Save. Sync. Run.

connic dev watches your project directories: agents/, tools/, middleware/, hooks/, and more. The next agent invocation runs against your current edits.

agents/triage.yaml
save in your editor
debounced ~1s
CLI uploads changed files to the runner
next invocation
agent loader runs the new version

Edits land in the runner in 2-5 seconds. Saves are debounced ~1s so a multi-file rename uploads as one batch. No full restart.

The commands you'll actually use

A handful of commands, no flags to memorize

The CLI is small on purpose. connic dev for an ephemeral session, connic dev <name> for a persistent one. That's the whole loop.

terminal
connic login

Authenticate once. The CLI opens the dashboard for an API key, then writes credentials to a .connic file in your project root.

terminal
connic dev

Start an ephemeral dev session. Provisions a cloud runner, uploads your project, and watches your filesystem. Auto-deleted on Ctrl+C.

terminal
connic dev my-feature

Reattach to (or create) a named environment that persists between sessions, with its own connectors and env vars.

terminal
connic deploy

When you're ready to ship, push your project to production. Same project, same connector wiring, just a different environment.

While iterating

Trace live in the dashboard. Test from your terminal.

Dev sessions appear in the dashboard alongside your standard environments. Trigger agents from a connector or the dashboard, watch the full trace stream in real time, and run your test suite against the active session before you ship.

The Agents view tags your dev session with a Dev session badge so you can spot it at a glance. Run traces stream in live with the same shape as production runs in observability.

Dev sessions are isolated from your other environments, so a webhook fired against dev can't accidentally hit production.

With the session active, connic test runs your suite against the same code your runner is currently loading. Every save, no redeploy needed.

zsh — connic test
❯ connic test

  Running 12 cases against dev session...

  ✓ 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 passed, 1 failed in 8.4s

Keep exploring

Composer SDK

Define agents in YAML.

Tools

Predefined, custom Python, or MCP.

Storage

Knowledge, sessions, and a database.

Testing

Assertions and judges, in CI.

Environments

Per-env config and secrets.

Observability

Trace every step, every token.

Frequently Asked Questions

File changes under the standard project directories: agents/, tools/, middleware/, hooks/, schemas/, guardrails/, and requirements.txt. Saves are debounced ~1s so a multi-file rename or formatter pass uploads as one batch.

Both. connic dev gives you an ephemeral session that's auto-deleted on Ctrl+C. connic dev <name> creates or reattaches to a named environment that persists between sessions, with its own connectors and env vars.

Run connic login once. The CLI opens the dashboard for an API key, then writes credentials to a .connic file in your project root. You can also pass CONNIC_API_KEY and CONNIC_PROJECT_ID via environment variables for CI or shared shells.

Adding a package to requirements.txt triggers a re-install in the cloud runner on the next sync. No restart needed.

Yes. Dev runs in its own environment with its own API keys, env vars, and connectors. Dev environments are grouped separately in the dashboard's environment switcher so you can't accidentally point a webhook at production.

No. Only one dev session can be active per named environment at a time. Use a different name, or omit the name for an ephemeral session, to work in parallel.