Genuine question - your README is full of em-dashes, emojis, feature squares and ASCII diagrams - none of which are present in your pre-AI era projects.
Why do you expect a potential userbase to care to read something you didn't even care to write?
Provided he reviewed it and checked the readme is telling the users what it needs to tell them - what's the issue? I've found documentation to be one of the better tasks AI can perform and see no reason why not to use it provided a human is in the loop.
I agree, but its tricky as many people seem to not read it and I have seen AI documentation that is so verbose and dense that its almost as useless as not having it. Its a fine line but so long as the AI documentation is reviewed and reasonable then I see no issue.
1. In reality most people simply do not do this, and frankly it's exhausting to be expected to always assume goodwill in a setting that is full of pure vanity.
2. There's a difference between technical documentation, which AI can be quite decent at, and product marketing. A README is usually about 20/80, maybe 50/50 for large FOSS projects. You can have the AI write the sections on how to install the thing for all I care, but as soon as AI is telling me why I should use it, you've lost me. Signals a complete lack of interest in your own product.
So this is a wrapper on top of a wrapper on top of Claude Code (which is a wrapper) on top of the API.
Considering that Open Claw requires 2GB of RAM and Claude Code is by no means a "lightweight" CLI either, I would argue that the compounding overhead here is hard to justify when you could just hit the API directly.
Each layer adds its own memory footprint, failure modes, and debugging surface area and at some point, the convenience of abstraction is outweighed by the cost of running what is essentially a Matryoshka doll of Node processes just to send a prompt and get a completion back.
Actually, Relay doesn't sit on top of Claude Code.
Relay connects to OpenClaw. OpenClaw connects to whatever model provider you choose (Claude, GPT-4, Llama, custom endpoint, whatever).
So the stack is: Your local files → Relay → OpenClaw gateway → Your chosen model.
That said, your point about abstraction overhead still stands. Each layer adds cost. We think the tradeoff is worth it for teams that need always-on agents + local file access + approval workflows. But if you just want to hit an API directly, you're right — this isn't for you.
These seem misleading. Cowork's VM is not on Anthropic servers?
> Local file access
>> Relay: Truly local
>> Cowork: Sandboxed VM on Anthropic's servers
> The bottom line: Claude Cowork is excellent for personal productivity on Anthropic's cloud. Relay is for teams and companies that need data sovereignty, compliance-ready audit trails, and model freedom — all on their own infrastructure.
better, more, screenshots or video walkthrough would help why something like this is interesting/needed.
The flood of new tools is truly overwhelming there isn't enough time to setup all of them to validate the marketing claims against actual functionality and benefit
Who is the troll here? I asked a genuine question and tried to explain why I think this way, and now you're all toxic. Can't you take feedback? If not, then why did you post this project here?
23 comments
Why do you expect a potential userbase to care to read something you didn't even care to write?
Seems a bit disrespectful to me.
The question is: "Should I spend my time engaging with this project?"
The AI-forward presentation says: "Absolutely not."
2. There's a difference between technical documentation, which AI can be quite decent at, and product marketing. A README is usually about 20/80, maybe 50/50 for large FOSS projects. You can have the AI write the sections on how to install the thing for all I care, but as soon as AI is telling me why I should use it, you've lost me. Signals a complete lack of interest in your own product.
But I can imagine that medium-sized companies will want to use AI as a backend in the future, without wanting to be dependent on Antropic.
After all, there are already quite a few companies using OpenClaw.
A self-hosted OpenClaw instance (or other solutions in the future) with Relay would be a good alternative to Claude Cowork.
Considering that Open Claw requires 2GB of RAM and Claude Code is by no means a "lightweight" CLI either, I would argue that the compounding overhead here is hard to justify when you could just hit the API directly.
Each layer adds its own memory footprint, failure modes, and debugging surface area and at some point, the convenience of abstraction is outweighed by the cost of running what is essentially a Matryoshka doll of Node processes just to send a prompt and get a completion back.
Just a thought.
Relay connects to OpenClaw. OpenClaw connects to whatever model provider you choose (Claude, GPT-4, Llama, custom endpoint, whatever).
So the stack is: Your local files → Relay → OpenClaw gateway → Your chosen model.
That said, your point about abstraction overhead still stands. Each layer adds cost. We think the tradeoff is worth it for teams that need always-on agents + local file access + approval workflows. But if you just want to hit an API directly, you're right — this isn't for you.
> Local file access >> Relay: Truly local >> Cowork: Sandboxed VM on Anthropic's servers
> The bottom line: Claude Cowork is excellent for personal productivity on Anthropic's cloud. Relay is for teams and companies that need data sovereignty, compliance-ready audit trails, and model freedom — all on their own infrastructure.
I'm not entirely sure what Cowork means by “sandboxed VM” right now. Relay simply has access to the folder you've defined for the project.
The flood of new tools is truly overwhelming there isn't enough time to setup all of them to validate the marketing claims against actual functionality and benefit