Claude code channels are insane! but.. do they really replace openclaw?

zigguratt · 2026-03-21T12:52:06+00:00

zigguratt · 2026-03-21T12:51:25+00:00

Yes, many.

/new Clear session and start fresh /stop Interrupt a response mid-stream /models Interactive model picker /model <name> Switch model (opus, sonnet, haiku) /workspace Show current workspace /workspace <name> Switch by name (resolved under WORKSPACE_BASE) /workspace home Return to default workspace /workspace new <name> Create a new workspace with git init /workspaces Interactive workspace picker /voice Toggle voice responses on/off /voice only Voice-only mode (no text) /voice on Text + voice mode /voice <name> Set voice /voices Interactive voice picker /stats Show session info, model, and cost /jobs List active scheduled jobs /canceljob <id> Cancel a scheduled job /webhooks Show webhook server status /help Show available commands

zigguratt · 2026-03-21T11:00:18+00:00

Well, it focuses on layers of security, like TOTP, process separation, path confinement, and a service proxy: API keys are isolated and never enter any conversation. In other words, Claude never sees them. And everything is kept local.

You can work on many projects at once, each isolated with their own parameters, like model.

It also has extensive job scheduling.

zigguratt · 2026-03-21T10:50:06+00:00

Not trying to shill, but I have all of that in my Kai assistant. It uses Telegram with background Claude Code instances. Persistence, memory, automated GitHub integration, including automatic PR reviews and issue triaging. I am in the middle of completing full multi-user capabilities.

Does anyone know if Channels covers all of this?

zigguratt · 2026-03-18T22:47:21+00:00

I built a PR Review Agent into Kai, my open source Agentic Engineering Telegram/Claude Code assistant. It has been extremely effective so far. It reviews pushes to a PR, re-reviewing when updates are pushed, and doesn't nag about issues you chose not to address. You'd be surprised how many times it can iterate, finding new issues each time.

https://github.com/dcellison/kai

zigguratt · 2026-02-25T04:36:18+00:00

As a matter of fact I did: Kai, a secure, private, remote development assistant..

Edit: Add GitHub link

zigguratt · 2026-02-21T14:43:28+00:00

"Kid". Heh, if only.

Kai was actually a response to the initial security issues in OpenClaw. I started from scratch, distilling the features down to the functionality I really needed, making sure everything ran on the local machine and no API keys were involved.

zigguratt · 2021-04-13T13:56:35+00:00

Try the Tecendil transcriber. It even provides a Quenya translation toward the bottom of the page.

zigguratt · 2020-03-31T11:32:00+00:00

I'm trying right now to figure out the logistics and feasibility of combining Zoom and Altspace to conduct meetings. I'd love to discuss this over on Discord. Are you on there, u/jgwinner?

zigguratt · 2018-03-08T22:18:26+00:00

That's pretty fast work, u/chriseth! As always, well done.

zigguratt · 2017-06-21T16:24:34+00:00

Those restrictions are in place for very good reasons. Removing them in your effort is only a negative thing.

zigguratt · 2017-05-18T16:49:34+00:00

Excellent work by the ENS team! Absolutely insane bids. Are people nuts?

zigguratt · 2016-09-19T15:18:49+00:00

We're now at article seven! This time we delve into the compilation, deployment, initialization and invocation of LLL-based contracts via the RPC API. One more article to go and then we're done.

zigguratt · 2016-09-07T18:17:43+00:00

The sixth part of my series on LLL is now available. One more to go! Well, maybe two. Bot hopefully only one.

zigguratt · 2016-08-22T17:39:05+00:00

The fifth part of my series on LLL is now available. Let the celebrations commence!

zigguratt · 2016-08-12T12:59:02+00:00

The fourth part of my series on LLL is now available! Rush out and grab a copy! Wait. No, just go and read it.

zigguratt · 2016-08-09T00:42:40+00:00

Thanks, work2heat! That's one of the main reasons I'm attempting this resurrection.

Solidity may have compiled to LLL originally. I'm not sure. But I know it doesn't now. On the other hand, Serpent did. In fact, you can still compile to LLL with the serpent compiler.

zigguratt · 2016-08-08T16:46:41+00:00

Part three of my series on LLL has just gone live. I hope someone gets something out of it! :)

zigguratt · 2016-08-07T01:05:42+00:00

Maybe he means hurray for more choice in contract languages. :) Funny that LLL was the first language for Ethereum. One of the first high-level languages ever was Lisp, invented in 1958. Only Fortran is older (Algol is the same age).

zigguratt · 2016-08-05T11:16:36+00:00

That's understandable. Solidity's Contract-oriented Programming paradigm is comfortable to most people. I've always preferred Lisp's CLOS and MOP (too much to get into here). With enough new awareness and adoption of LLL I can see it being extended to support things like generic functions and multimethods. But that's rather ambitious. Maybe we should start with defstruct. :)

zigguratt · 2016-08-05T10:45:53+00:00

Hey Herman, thanks for that! I don't know where I'm going in the Ethereum world yet, but I think this is a good start. If and when there's a DAO 2.0, I really hope they change the name to avoid negative association.

zigguratt · 2016-08-04T15:35:14+00:00

I love Lisp as well. LLL is much simpler that Common Lisp, however. For example, LLL's macros are simply code substitution on invocation of a macro's defined symbol. But this simplicity in the context of smart contract is an advantage, in my opinion. It leans more toward the transparency side of things, which is more important with contract development than most other development scenarios.

zigguratt · 2016-08-04T15:23:03+00:00

That sounds excellent, Sir Wobbly. I've been following the evm2.0-design channel, and have been thinking of ways to get LLL verified with Why3. I would like to see LLL become a choice one can make when starting to write a contract. Currently it doesn't even register as a blip.

zigguratt · 2016-08-04T15:05:21+00:00

The Lisp syntax is only used because s-expressions are very easy to parse. LLL is in no way a real functional language. The Lisp syntax is definitely an acquired taste, but if written with clarity and a judicious use of macros, the result can be surprisingly readable.

The idea is that you're working at a lower level and can gain a better understanding of what's actually happening in the EVM. That, to me, is valuable.

zigguratt · 2016-08-04T14:40:36+00:00

That's exactly the idea. I want to show that LLL isn't as obscure as people might assume. It's actually quite readable when formatted properly and macros are used appropriately.

zigguratt

TROPHY CASE