Skip to main content
loomcycle
§ release

loomcycle 1.0 is here. Substrate complete. Paca integration next.

2026-06-16 · by Dennis Gubsky · ~11 min read

Two months ago I was running my agents for JobEmber.ai (an AI job-search SaaS) on a VPS, first with claude --print in a loop, then with the Claude Agent SDK. Three to five agents in parallel and the VPS was out of memory. My minimum plan needed 100 in parallel, per user.

So I started writing a small Go sidecar to take the loop off the application. One Go binary, ~50 MB, alongside whatever your application is written in. That was supposed to be it.

Today loomcycle 1.0 ships.

The substrate is feature-complete. The hardening pass cleared an 8-hour stability soak. The runtime survives slow local hardware (a 133-minute autonomous run on Qwen3.6:27b through Ollama, multiple auto-compactions, zero false-timeout deaths). The companion repos are real and shipping. And the Paca integration is now confirmed by direct agreement with the Paca maintainer over gRPC.

Below: what's in v1.0, what's next, and where Paca fits.

What's in v1.0

v1.0 is the feature-complete-substrate tag. No new primitives between here and v1.x; everything is hardening, distribution, and the polish work shipped across v0.34.3 → v0.37.0.

The substrate primitives

Production-grade validation

Two numbers ground the v1.0 tag.

8-hour stability soak: 1.27M circuits, 3.8M agent runs, 100% completion across 468 waves, zero leaks (RSS, goroutines, connections, quotas). Per-replica load split to 0.14%. The substrate doesn't drift under sustained load.

133-minute autonomous run on Qwen3.6:27b through ollama-local (the slow-local-model robustness pass that landed v0.34.3 → v0.37.0). Multiple auto-compactions fired correctly, the tail-cap kept post-compaction requests under the 131k window, the heartbeat ticker kept the run alive through every long prefill. The runtime is honest about local inference now, not just cloud APIs.

Writeups: the 8-hour soak and the 133-minute local-Qwen saga.

The Claude Code surface

Claude Code stays the human's conversation surface. loomcycle is the side runtime where the delegated multi-agent work runs. Two integration paths:

The cost-shape that matters: Claude Code burns Claude tokens for the conversation. loomcycle can run the delegated agents on DeepSeek, Ollama, local Mistral, or any other cheaper provider the structured-loop work doesn't need Claude for. Same MCP wire surface; the model swap is one AgentDef field. exp7's 10 reviewers ran on Claude OAuth, but the topology is provider-neutral.

The reproducible experiments

Seven self-contained reproducers under loomcycle/examples. Each is a directory with its own loomcycle.yaml, run.sh, .env.local.example, and a reproducible README. Clone, cd, run.

Paca integration: loomcycle as the agent runtime under an AI-native Scrum board

Paca is the AI-native, Apache-2.0, self-hosted alternative to Jira / Trello / ClickUp / Monday. 954 stars, active development, built around the idea that AI agents are first-class Scrum teammates. WASM plugin sandbox, MCP-native, Claude Code skill, Docker Compose deploy.

Today Paca's agent service runs Python + the OpenHands SDK, spawning a Docker container per agent conversation. After a few back-and-forth conversations with the Paca maintainer, here's the news:

The Paca maintainer is implementing the loomcycle integration as a gRPC-shaped path. Paca's agent service calls loomcycle's gRPC surface directly to spawn runs, stream events, and route per-task agent credentials. The substrate primitives (Memory, Channel, Schedule, spawn_runs fan-out, per-run credentials, redact plugin) become available to Paca's UI through the same wire shape loomcycle uses for everything else.

Direct maintainer agreement, mutual interest. The two projects make natural sense together: Paca owns the team / board / sprint / BDD-spec surface; loomcycle owns the agent runtime. Paca's container-per-conversation overhead gets replaced by loomcycle's ~50 MB binary that handles per-run isolation, multi-tenant authz, scheduled runs, signed webhooks, and the trust-boundary discipline already in production for JobEmber.ai.

Why gRPC and not MCP for this one: Paca's services/api is a Go + Gin service that already lives in a typed-RPC world. gRPC gives the Paca side a generated client with strict types, no JSON-RPC boilerplate, streaming for event progress, and the same surface loomcycle exposes for its Python adapter. The MCP wire surface stays available for other consumers; gRPC is the right shape for service-to-service integration inside one product.

Timeline: the integration work is on the Paca maintainer's side; design notes shaping the RFC are at loomcycle's design docs. When the integration lands publicly, both projects will write about it. For now: if you're running Paca, watch their release notes; if you're running loomcycle, the gRPC server is shipped already (v0.8.x onward) and the integration uses the same surface a Python or Go client would.

The companion-projects roster

With Paca confirmed, the companion-projects family settles into four:

What's next: three named post-v1.0 design RFCs

v1.0 is the feature-complete-substrate gate. The next thing is not "more features bolted on." It is three named design lines, drafted, scoped, and queued behind the v1.0 hardening pass clearing.

Context-compress plugin (RFC Z Phase 2)

Phase 1a of the contextplugin chain shipped in v0.34.0 with the redact plugin. Phase 2 is a context-compress plugin: LLMLingua-style content compression at the per-turn boundary, composing with redact in the same chain, transforming a copy of the outbound request, leaving the canonical history and the persisted transcript untouched. The seam is the same one auto-compaction already uses; the new dependency is a tokenizer.

The research is done. A separate research RFC scored LLMLingua / LLMLingua-2 / LongLLMLingua / Selective Context / soft-prompt family / abstractive / pure-Go against loomcycle's constraints (black-box providers, single Go binary, deterministic byte-stable, no local model required). The recommendation: a pure-Go structural pre-pass (cheap, deterministic, no external dep), and optionally LLMLingua-2 as the model-based method (sidecar / embedded ONNX / pure-Go-only - the deployment choice is the design crux).

Status: in preparation.

SQL Memory (RFC AA)

A second facet of the Memory primitive. Per-scope SQL databases the runtime owns, isolated from the main loomcycle store, that sandboxed agents query with arbitrary SQL. Two new Memory ops (sql_query, sql_exec); durable per-(tenant, scope, scope_id) plus an ephemeral per-run scratch DB; default-deny sql_scopes ACL; statement timeouts; byte quotas; full audit. sqlite tier first (one file per scope, hardened authorizer + statement allowlist), postgres tier (one schema per scope in a separate aux DB) is Phase 2.

Closes the "agents that need structured tables today need Bash + sqlite3" gap. The Bash escape hatch is restricted-not-isolated; SQL Memory is bounded at the SQL layer, audited, and never touches the main store.

Capability-based memory interface + mem0 backend (RFC K)

Generalize the v0.15.0 memory.Backend contract with an optional MemoryLayer capability so LLM-extract memory products (mem0, Mem9 in smart mode, Zep-style) work natively (add(messages) → recall(query)) rather than degraded into a KV store.

mem0 (57k stars, Apache-2.0, daily commits, funded company, published LoCoMo 91.6 / LongMemEval 94.8 numbers) lands as the first MemoryLayer backend. The flat Backend stays canonical; an external memory-layer backend declines Backend and serves MemoryLayer only. The substrate stops pretending an LLM-extract product is a KV store.

How to actually run it

Three install paths, three commands each, same single binary. 

# Homebrew (macOS + Linux)
brew install denn-gubsky/loomcycle/loomcycle
loomcycle init --with-token
loomcycle doctor && loomcycle

# Docker (v0.11.2+; amd64 + arm64 incl. Apple Silicon)
docker pull denngubsky/loomcycle:latest
docker run --rm -p 8787:8787 \
  -e ANTHROPIC_API_KEY=sk-... \
  -e LOOMCYCLE_AUTH_TOKEN=$(openssl rand -hex 32) \
  denngubsky/loomcycle:latest

# Direct tarball (darwin-arm64 / darwin-amd64 / linux-arm64 / linux-amd64)
curl -L https://github.com/denn-gubsky/loomcycle/releases/latest/download/loomcycle-darwin-arm64.tar.gz | tar xz
./loomcycle init --with-token && ./loomcycle doctor && ./loomcycle

Then open http://127.0.0.1:8787/ui, paste the token from ~/.config/loomcycle/auth.env, and the Web UI is yours. Already using Claude Code? loomcycle import claude-code --from=.claude --write --skills-dest=$PWD/skills lifts your existing agents and skills into the substrate.

Why v1.0 was the right gate

I could have tagged 1.0 a month ago and skipped the hardening pass. I didn't, for two reasons.

First: the substrate has to survive contact with production. The 8-hour soak was the answer to "does this thing drift under sustained load." The 133-minute local-Qwen run was the answer to "is the runtime honest about hardware that isn't an Anthropic data center." Both numbers gate the tag. Without them, "production-ready" is a marketing word.

Second: the post-v1.0 plans only make sense if the substrate underneath is stable. A context-compress plugin landing on a runtime that drifts under load would be debugging the wrong layer for weeks. SQL Memory landing on a runtime whose pause/snapshot is unreliable would be cleaning up half-written rows from crashed snapshots forever. Paca's maintainer choosing to integrate over gRPC only makes sense if the gRPC surface has been stable through a real production workload and across two months of intentional stress.

v1.0 is the first portable, durable, hardened version of the substrate. Everything from here is composition.

What I'd like to hear about

If you're running loomcycle on hardware I haven't tested, file an issue. If you're integrating loomcycle into a product, drop a line; the Paca integration is the first of probably several, and I'd like the next ones to learn from the gRPC-shaped path Paca's choosing.

If you've been watching JobEmber.ai-shaped problems (per-user agent runs, scheduled background jobs, signed webhook ingress, secrets that should never reach an LLM) and waiting for a runtime to land them on: loomcycle is what I built. v1.0 is the first version that's not labeled "early adopter, here be dragons." Apache-2.0, self-hostable on a small VPS or a multi-replica cluster, no enterprise tier required for multi-tenancy (that lives in OSS, not paywalled).

Production teams inform the design; integration-shape ideas are the things that get RFCs written.

Companion reading: the substrate-shaped journey - exp1+2 · exp3 · exp4 · exp5 · exp6 + 6.5 + 6.8 · exp7. The hardening pass: 8-hour soak · 133 minutes on a local Qwen.

Dennis Gubsky · loomcycle maintainer · 2026-06-16

Building on loomcycle, or thinking about it? I'd like to hear what you're running into. [email protected] · GitHub Discussions · security disclosures to [email protected].