cowork-to-code-bridge — async bridge letting DSPy modules delegate work to Claude Code on your local machine

[abhinaykrupa]

Show and Tell: cowork-to-code-bridge — let DSPy modules delegate to Claude Code on your local machine

Hey DSPy community,

I've been building agents with DSPy and kept hitting the same wall: the agent runs in a cloud sandbox (or CI), but the interesting work — running evals, generating embeddings, calling local tools — needs to happen on my actual machine. I ended up building cowork-to-code-bridge: an async, file-based RPC bridge that lets a sandboxed agent queue work for Claude Code running locally, with no open ports and no auth tokens flying around.

How it fits into a DSPy program

import dspy
from cowork_to_code_bridge.client import queue_task, poll_task_result

class LocalEvalModule(dspy.Module):
    """Run an expensive local eval from inside a DSPy pipeline."""

    def forward(self, program_code: str, dev_set: list[dict]) -> dspy.Prediction:
        # Fire off the eval without blocking the DSPy thread
        task_id = queue_task(
            tool="bash",
            args={"command": f"python eval.py --inline '{program_code}'"},
            idempotency_key=f"eval-{hash(program_code)}",  # safe to retry
        )

        # Poll until done (or surface a timeout to the DSPy optimizer)
        result = poll_task_result(task_id, timeout=120)
        if result["status"] != "success":
            raise dspy.DSPyRetriableError(result.get("error", "eval failed"))

        return dspy.Prediction(score=result["output"]["score"])

You can drop this module into any DSPy ChainOfThought or ReAct program and the optimizer never has to care that the eval ran on a different machine.

What the bridge handles

Feature	Detail
queue_task / poll_task_result	Async by default — no thread blocking
Loop detection	Catches agent retry spirals before they blow your budget
Per-op metrics	Latency + token cost per task, queryable at the end of a run
Budget cap	Hard ceiling on total tokens/cost across the whole bridge session
No open ports	Shared bind-mount directory only; works behind any firewall

Why it's useful for DSPy specifically

DSPy's teleprompters and optimizers can run for a long time. The bridge lets you keep the optimization loop in the sandbox while expensive side-effects (file I/O, subprocess evals, GPU jobs) stay on the local machine — and the budget cap means a runaway optimizer can't silently rack up costs.

Repo: https://github.com/abhinaykrupa/cowork-to-code-bridge

---

Question for the community: Are you running DSPy optimizers in cloud sandboxes today? What's your current strategy for connecting them to local evals or tools — and would an async bridge like this fit into your workflow?

[abhinaykrupa]

Thanks for reading. Honest answer to your question: none of those four, because the bridge deliberately isn't a multi-provider router. It shells out to one runtime — the Claude Code CLI on the user's own machine — so there's no provider matrix to reconcile. Streaming, tool calls, and structured output are the CLI's problem, not the bridge's.

The friction that actually cost me implementation time is a layer below provider differences, and I think it generalizes to any DSPy module that delegates to a long-running external runtime:

1. Waiting vs. running are two different timeouts. A timeout bounds execution; it does nothing about a task that sat in the queue for four hours because the daemon's host was asleep. Executing a stale "deploy" long after the caller gave up is worse than never running it. Those need separate bounds (timeout vs max_age_sec), and the age check has to fail open on a missing/unparseable submit timestamp so older clients don't break.

2. Cancellation has to kill the process group, not the child. SIGTERM to the direct child leaves the actual build/test tree orphaned. Group-kill, then SIGKILL after a grace period, and write a normal result record with a distinct exit code — the caller shouldn't need a special path to observe "cancelled."

3. Output is untrusted and unbounded. Anything the delegated run prints lands on disk. That means capping stdout/stderr while streaming (keep the tail, flag the truncation explicitly so absence-of-flag means "nothing dropped") and scrubbing secrets on the write path, not the read path — result file, progress log, and status line are three separate sinks and all three need it.

4. Idempotency keys matter more than retries. For state-changing delegated work, a retry that double-fires a push is the failure mode, not a dropped call.

On usage reporting specifically — since the run happens under the user's own CLI auth on their own hardware, cost accounting lives with them rather than in the bridge, which sidesteps the reconciliation problem but also means the bridge can't offer a unified usage view. That's a real tradeoff, not a free win.

Repo if useful: https://github.com/abhinaykrupa/cowork-to-code-bridge