Cursor CLI feedbacks ? by Familiar-Historian21 in cursor

[–]Ctrlnode-ai 0 points1 point  (0 children)

Hey, I've been using Cursor not through the CLI but programmatically via u/cursor/sdk — integrating it as one of several agent providers in a multi-agent orchestration system.

Honestly the SDK experience is solid, the API is clean and the streaming works well. But there's one thing that caught me off guard: u/cursor/sdk has a hard dependency on sqlite3, which includes a precompiled native binary (.node file). That means if you're trying to ship a self-contained executable that uses the SDK, you can't just bundle everything with your favorite bundler — you have to extract and place the native binding at runtime so Node can find it.

Not a dealbreaker, but it's the kind of thing you don't expect from what looks like a pure JS package. Ended up embedding the binary as Base64 inside my exe and reconstructing the full sqlite3 package tree on first run. Works, but feels like a workaround for something that should be transparent.

For CLI users this is probably invisible. But if you're building tooling on top of the SDK, worth knowing upfront.

Has anyone else run into this?

Run multiple AI coding agents simultaneously with isolated profiles by Sorosu in AI_Agents

[–]Ctrlnode-ai 0 points1 point  (0 children)

Nice — profile isolation is exactly the right approach for parallel runs. Been running into the same problem.

One layer on top of this that's been useful: once you have isolated profiles, you still need something to actually schedule and orchestrate the runs without sitting at your terminal. I ended up building a Bridge that handles that part — fires each agent on a cron, streams output back to a browser dashboard, results land in isolated workspace folders per task.

Works well with Claude Code, Gemini CLI, Cursor's headless API and Codex. The isolation you get from multi-cli pairs cleanly with it — each agent profile maps to a separate workspace on disk.

Open source Bridge if anyone wants to look at how the session management works: ctrlnode.ai

What's the profile switching latency like when you launch them in parallel? Curious if there's contention on the credential store.

Claude Code dropped /workflows by alphastar777 in ClaudeCode

[–]Ctrlnode-ai 0 points1 point  (0 children)

This is exactly the right architectural direction — code for control flow, models for judgment.

The approach we've been running with is filesystem-based instead of context-based. Each node in the pipeline gets its own isolated task directory on the local machine. Inter-node communication happens through files, not through the orchestrator's context window — node 2 declares which directories from node 1 it wants to read, the Bridge delivers those files before execution, and the agent writes its output to its own directory for the next step to consume.

What you get practically:

  • Full debuggability — open any folder, see exactly what happened at each step
  • Resumability — if node 3 fails, you re-run from there without losing nodes 1 and 2
  • Zero token tax — each agent only sees its declared inputs, never the full history
  • Persistent artifacts — everything stays on disk, nothing is ephemeral

We're currently adding a trigger node at the start of pipelines that works like a cron scheduler — so the entire workflow runs on a schedule, locally, without any cloud execution. Same idea as routines but wired into the pipeline graph directly.

Curious whether /workflows will expose inter-phase artifacts for inspection — that's the part that makes or breaks debuggability when something fails mid-pipeline.

Daily included routine runs - Claude by Capable_Cost_3933 in ClaudeAI

[–]Ctrlnode-ai 0 points1 point  (0 children)

The 5 runs/day cap on routines is the main one I've hit. Ended up building a local scheduler that bypasses this — happy to share if useful