Skip to main content
Connic

Local editing.
Cloud execution.

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

Start for 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
❯

Save. Sync. Run.

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

agents/triage.yaml
save in the 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.

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

One-time authentication. The CLI opens the dashboard for an API key, then writes credentials to a .connic file in the project root.

terminal
connic dev

An ephemeral dev session that provisions a cloud runner, uploads the project, and watches the local 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

Production delivery uses the same project and connector wiring in a different environment.

Live traces in the dashboard. Tests from the terminal.

Dev sessions appear in the dashboard alongside standard environments. Agents can be triggered from a connector or the dashboard, the full trace stream remains visible in real time, and the test suite runs against the active session before release.

The Agents view tags the dev session with a Dev session badge for immediate recognition. Run traces stream live with the same shape as production runs in observability.

Dev sessions are isolated from other environments, so a webhook fired against dev cannot accidentally hit production.

With the session active, connic test runs the suite against the same code the runner is currently loading. Every save is available without another deployment.

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

Retrieval, sessions, and 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 tests/. Saves are debounced ~1s so a multi-file rename or formatter pass uploads as one batch.

Both. connic dev creates 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.

Authentication starts with connic login. The CLI opens the dashboard for an API key, then writes credentials to a .connic file in the project root. CONNIC_API_KEY and CONNIC_PROJECT_ID can also be passed as environment variables for CI or shared shells.

Dependencies are installed when the dev session starts. A change to requirements.txt requires the session to be recreated.

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, preventing a webhook from being pointed at production accidentally.

No. Only one dev session can be active per named environment at a time. Parallel work requires different names or ephemeral sessions without a name.