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?