I now it's "yours", but do you know how you differ from for example https://cmux.com/ which I'm happily using right now?

I wouldn't say change your workflow if you're happy, but I'll answer anyhow!

I also actually tried cmux, but I didn't like they way it did tabs. I like my tabs top-level and not inside panes (but I realize this is a personal choice).

We also do good GH native integrations (linking PRs, showing statuses, and linking GH issues). We also do AI status indicator even for non-focused terminal panes. You can also manually mark a worktree as 'unread' (kind of like a star in Gmail) In addition Orca has a built in file viewer, search, git diff viewer (see all changes like VsCode does)

Also cmux is Mac only (doesn't matter for you, but for others)

So tl;dr -- alot of small things. But those build up for me in a tool that I basically find myself living in

^ I updated the post to reflect some of these

Thanks for the rundown. I just started using cmux and the pane behavior you’re describing is my biggest gripe. I’ll check this out.

Thanks for trying it out! Accuracy is the #1 priority every finding should be real and actionable. Glad to hear that's holding up on your project. If you do hit any false positives, please open an issue!

The fields/flags state model is a nice idea, having structured values separate from boolean state is something I haven't seen in other frameworks. How does this compare to Alpine.js or htmx in practice? They're in a similar space (no build, SSR-first) but I'm curious what made you go with a new framework rather than building on top of those?

Think Xstate[0] machines are a little more intuitive than the conditional value structuring displayed here in the example, but it is an interesting idea indeed.

[0]: https://github.com/statelyai/xstate?tab=readme-ov-file#super...

Alpine/htmx are great, but they're more "sprinkle behavior on HTML" tools. Qite is closer to a structured component system: explicit events, a state engine, and a consistent way to wire parts/fields/children together without ad-hoc glue.

You can build similar things with Alpine/htmx, but once things grow, you end up reinventing structure. Qite just bakes that in from the start.

I agree, I hate unnecessary hypercomplexity.

Most of the time, it's enough to build in a simple, clean, and lightweight way. Just like in the old days. Your server's resources will also thank you. Furthermore, the simplicity of web pages is also rewarded by search engines.

If it were up to me, I'd build sites exclusively in .md format :)

It's a CLI. CLIs have man pages and cheat sheets. That's not a UX failure, that's the format. The same argument would apply to git, ripgrep, or ffmpeg.

The actual complexity in Claude Code isn't the commands, it's figuring out a workflow that works for your codebase. CLAUDE.md files, hooks, MCP servers, custom skills. Once you have that set up the daily usage is just typing what you want done.

This matches my experience. The bottleneck isn't what the agent knows, it's what the agent can verify. A knowledge base tells it "don't do X", but the agent still has to remember to check. Giving it a tool that returns ground truth works better. The agent calls the tool, gets a concrete answer, acts on it. No memory required, no drift over time.

Ai

This is a good point. For anything without a DOM, screenshot diffing is basically your only option. Mozilla did this for Gecko layout regression testing 20+ years ago and it was remarkably effective. The interesting part now is that you can feed those screenshots to a vision model and get semantic analysis instead of just pixel diffing.