I don't usually like my cursor to be hijacked but man, I like this one.

Since prompt caching won't work across different models, how is this approach better than dropping a PR for the other harnesses to review?

Sorry, I may be misunderstanding the question.

The way this works is that it stores workstreams and session state in a local SQLite DB, and links each ctx session to the exact local Claude Code and/or Codex raw session log it came from (also stored locally).

What do you mean by prompt caching?

Prompt caching is done on the provider side. If you send two requests to a provider in short succession and the beginning of your second request is the same as your first (for example, because your second request is the continuation of an ongoing chat), the repeated tokens are much less expensive the second time.

Obviously, your tool does not provide this. But I think GP is undervaluing the UX advantages of having your conversation history.

Yes that's it. I actually just ask codex/claude code to look up the session id when I want to resume sessions cross harness, it's just jsonl files locally so it can access the full conversation history when needed.

Great callout about the prompt caching, this switch is going to burn subscription limits on Claude real real fast.

Unless the goal is to move from one provider to another and preserve all context 1:1. And I can’t seem to find a decent reason why you would want everything and not the TLDR + resulting work.

I'm working on multi-tenant version of OpenClaw for organizations that has shared memory layer. It includes an entity based agent context layer that can be used as OpenClaw plugin and a sandbox runtime layer which uses just-bash with pi and let you expose the context via a bot an API.

https://lobu.ai

It playbook is that a model is too dangerous until a competitor releases a competing model that beats yours.

At which point you tell them they are being extremely reckless but subtly mention that something new & even scarier is being developed internally that's going to blow everything else out of the water.

I get why they block OpenClaw and it makes sense but I wonder if they can actually detect OpenClaw calling Claude Code CLI using something like acpx.

It's simply identical to how people use Claude Code locally.

does it matter?

Yeah it does. If you're happy routing your personal data through software that lacks an author who fully understands what the software does, good for you. Suggesting that this doesn't matter in general is.. not an opinion I'd share publicly.

Immensely, and in saying it as someone both writing stuff by hand and using AI as a helper.

At the very least any primarily AI submission should be tagged. If untagged - should be removed.

Compliance tech company who doesn't know about open-source. Interesting.

They're composable but computers are not. Two skills might depend on a different version of a dependency which is pretty hard to maintain and their needs to be a deterministic system (agents are not) to resolve the conflicts and make sure two skills can live in the same environment.

If you are using Python it should be creating separate venv's for different skills. It is 2016, uv can install any version of Python you need.

I extensively use uv (IMO better than venv) but still it's Python specific and not universal. npm is much worse and native binaries are almost impossible to deal with multiple versions.

nix is specifically targeting this use-case and it'e extensively used by vendors like Replit.

I vote for taste

There is nothing wrong with MCP, it's just that stdio MCP was overengineered.

MCP's Streamable HTTP with OAuth discovery is the best way to ship AI integration with your product nowadays. CLIs require sandboxing, doesn't handle auth in a standard way and it doesn't integrate to ChatGPT or Claude.

Look at Sentry, they just ship a single URL https://mcp.sentry.dev/mcp and you don't need anything else. All agents that supports MCP lets you click a link to login to Sentry and they make calls to Sentry to fetch authentificated data.

The main problem with MCP is the implementation. Instead of using bash to call MCP, agents are designed to make single MCP tool calling which doesn't allow composability. We solve this problem with exposing MCP tools as HTTP endpoints and it works like charm.

Could you expand on this some more? I'm not quite following.

I agree with the sandboxing challenge of a CLI, although I think any CLI (or MCP) wrapping an http API should be subject to a sane permissioning system that's a first class concept in the API itself. That's in my opinion the correct way to limit what different users/tools/agents can do.

But I don't fully understand the Streamable HTTP point.

I doesn't matter how it "should" work. In the real world you need to interact with external systems which don't have granular enough permission schemes.

People out here letting Claude code run CLIs using their own user permissions are morons waiting to have their data deleted.

I get that. Should and DO are different. But you aren't addressing my Streamable HTTP question which is the heart of what I asked.

CLI enables the actions to be made on behalf of you, the external service is not aware whether it's you or AI making the calls. With MCP, Sentry knows it's AI making the call so can be smarter about the security. There is many MCP annotation hints on tools to mark the as destructive, read-only etc.

That's interesting, but that still sounds like something a proper auth/token permission system would more than address. You're also actively choosing to limit what functionality MCP provides, which is fine, but there are many ways to do the same via the API or CLI tooling.

I'm not saying you are wrong to do this, I just don't think it's enough to convince me that yes this is the one true approach you should use.

There's nothing special about using http other than most corporate firewalls allow it. It's just the pragmatic choice.

This is my take as well.

Way easier to set up, centralized auth and telemetry.

Just use it for the right use cases.