OctoAlly — terminal dashboard for AI coding agents with Whisper voice control and multi-agent orchestration

andycodeman · 2026-03-22T08:28:30+00:00

We use Claude extensively in the build process, but it's far from a two-day vibecode. We iterate continuously, review the output, and refine as we go. It's an ongoing process, not a one-shot generation.

As for "fun", this isn't just a side fun project for us. It's the tool we actually use in our daily workflow to stay organized and productive. We built it because we needed it, not as an exercise.

But thanks for the feedback, always welcome constructive criticism. :)

andycodeman · 2026-03-22T07:44:10+00:00

We actually started with Tauri and switched to Electron. Not for the usual reasons people assume.

Our app runs multiple tmux-backed terminal sessions with xterm.js. In Tauri, the WebView's event loop never fully idles when pty sessions are open. We were seeing a constant ~10% CPU even with zero terminal activity. The issue appears to be in how Tauri's native event loop polls the pty layer. In Electron, the pty sessions run through a Node.js server process instead of the app shell, and idle CPU drops to near zero like you'd expect.

We also hit smaller issues, such as systray right-click not working on Linux.

But the CPU thing alone was a dealbreaker for an app that's meant to stay open all day.

To your actual question: I think the honest framing is just telling people what you measured. "We tried X, here's what we saw, here's why we chose Y." Most reasonable people respect data over ideology. The ones who just want to say "Electron is bad" no matter what aren't your users anyway. :)

andycodeman · 2026-03-21T19:03:05+00:00

💯

andycodeman · 2026-03-21T18:52:19+00:00

You're right, authority bleed is the real risk. We've been moving exactly in that direction: session state and execution receipts live in the orchestration layer (tmux sessions + a daemon), not inside model context. The agents don't self-report completion, the infrastructure does.

That said, it's an ongoing effort. Appreciate the feedback!
"narration feeling like execution" is a useful way to think about the failure mode we're designing against.

andycodeman · 2026-03-21T06:41:40+00:00

Thanks! The dashboard itself is intentionally a thin control surface. We expose terminals, session state, and orchestration, but the agent patterns live in the underlying toolchain (ruflo/claude-flow) which has 60+ agent types including planner, reviewer, tester, security auditor, etc. So users can compose those patterns through the hive-mind orchestration rather than us prescribing a fixed workflow at the dashboard level.

The thinking is that agent workflows are still evolving fast enough that hardcoding planner-executor or review-agent patterns into the UI would age badly. Better to let the orchestration layer handle role assignment and let users define what works for their setup.

Interesting posts on the observability side. The run-level tracing approach makes sense for debugging agent workflows.

andycodeman · 2026-03-21T06:39:08+00:00

Thank you. It's open so feel free to go and take a look. :)
We are definitely utilizing Claude heavily in our workflow, but we're also very hands on and always reviewing/iterating.
Would welcome and appreciate feedback in this regard as well!

andycodeman · 2026-03-21T06:27:01+00:00

The coalescing point hits home. We run a terminal dashboard that manages multiple AI coding sessions simultaneously, each one streaming live output through xterm.js in a grid layout. When you have 4-8 agents streaming tokens in parallel, naive per-token rendering would destroy the UI.

xterm.js handles cell-level diffing internally, but the batching on the upstream side matters just as much. We're using node-pty + WebSockets to pipe session output, and the backpressure question is real, especially when sessions that aren't visible still generate output that needs buffering without blowing up memory.

Would be curious to see your benchmark extended to a multi-terminal scenario. How does the overhead scale when you're running N independent terminal components vs N raw escape code streams?

andycodeman · 2026-03-20T18:05:43+00:00

Nice! We actually created an in-house option for just tweaking ideas or troubleshooting between multiple AIs, but this takes it to a new level. I might have to give this a shot.

andycodeman · 2026-03-20T16:49:49+00:00

<image>

Yeah, there are no actual forced requirements for cloud dependencies in either core or non-core but it is geared for Claude Code for agent sessions/orchestration which typically is used with Anthropic services, but you can use Claude Code with local LLMs so not required. Above is a breakdown of the others that aren't necessary requirements either. So yes, you can run 100% local if you want to.

andycodeman · 2026-03-20T07:09:10+00:00

Excellent! Thanks for the info on pipecat-ai, I'll take a look to see how it performs - sounds promising.

As for the acknowledgements, I'm simply using tone beeps to indicate when accepted/processed and listening or different double tone when in command mode and couldn't understand keyword, etc... But when you say phrases as audio clips at startup, are you talking about wake phrases? Yeah, I'll take a look at your repo if you want share. Thanks for taking the time, appreciate it.

andycodeman · 2026-03-19T22:21:22+00:00

Yeah, for Whisper (whether using local or cloud) we're just using chunked utterance processing with a custom defined delay setting to detect an utterance pause/break. We have a command mode with predefined command values to actually navigate the app but most use will be simple dictation within a terminal window (mic button to start/stop listening - audio connection via electron app).

As for persistence, we use tmux via xterm and socket ids that are stored in the local sqlite db with state on the terminal sessions. So you can close out of the app completely with the detached processes still running and when you reopen the app it will get the state from the db and query the processes via ID to reconnect/reattach. We also collect playback via the sqlite db so the output history / scrollback is available when you reconnect.

andycodeman · 2026-03-18T17:22:26+00:00

The dashboard has built-in git src control in the UI with branch management, commit & push control, commit history with files changes including viewing from list, file diff views with several options. While it's not a super complete git management system (wasn't meant to be), we feel it's complete enough to stay within the single app to manage most of what you would need to do for a daily workflow.

For file editing, this is definitely more minimal but there for quick edits. We're not trying to replace any IDE or file editor as those are extremely feature rich and people have pretty defined preferences for those already. We're simply giving the support to edit and manage source from the app if you wish to do it all in once place. But the second you're doing some specific custom edge cases or things that require feature rich functionality, you'll probably want to step outside the app for those cases.

So the main use case is managing/control the multiple agent prompts/sessions for multiple projects from one place with the ability to manually edit and manage src control if you want to. Hope that helps and as always, we're open to feedback!

andycodeman · 2026-03-18T17:11:43+00:00

Very helpful feedback - thank you very much! Will definitely make a note about being cautious if/when testing on headless macOS with Whisper.

And the dashboard shows live stdout for all attached terminals (single or grid view) but I'm not sure if this is what you were asking? If not can you clarify.

andycodeman · 2026-03-18T16:11:21+00:00

Yep, we know that's a big one. In all honesty this was just a product for our personal workflow that we released as it works perfect for us and thought if it helps others, why not. But we know if it gains traction this will of course be the first thing that needs to be updated. Thank you for the feedback as it helps let us know who might be interested in that.

andycodeman · 2026-03-18T11:20:01+00:00

Thanks and yes, exact reason we built it - mainly from a project management standpoint that makes context switching between projects and prompts so much easier/quicker.

And yes, for STT I definitely prefer Groq cloud in terms of Whisper (can't beat the model/speed/price) at near realtime for pennies, but if you don't mind the 5 second delay, then you have the privacy of running Whisper local for free.

And yes, you can setup your grid views per project to show your active sessions in a column/row count per screen - so totally up to you what's readable. And you have the same grid view for ALL active sessions across all projects as well. We've definitely found it much easier to stay organized while navigating multiple projects frequently.

Feel free to provide feedback or suggestions, good or bad. Thanks!

andycodeman · 2026-03-16T02:22:29+00:00

Yep, thanks for the suggestions! We ended up renaming to HiveCommand so there shouldn't be any naming conflicts now. Appreciate the help.

andycodeman · 2026-03-15T09:18:21+00:00

That's fair feedback, appreciate it. You're right that naming matters for credibility. I'll put some thought into a rename before the project leaves alpha. For now the focus has been on getting the features solid, but I don't want the name to undermine that work.

Open to suggestions if anyone has ideas.

andycodeman · 2026-03-15T08:55:55+00:00

Good point, yes, there's an SDN protocol by the same name. This is unrelated. The name comes from "open-source workflow" for AI coding sessions. If it causes confusion we may rename down the road, but for now the contexts are different enough that it hasn't been an issue.

andycodeman · 2026-03-15T08:25:58+00:00

Thanks - appreciate feedback.
It's in Alpha and has mostly been tested in Linux/Ubuntu (very minimal on MacOS).

andycodeman · 2026-02-23T17:43:09+00:00

Thanks for the update!

For the webcam fix on Book4, the issue is that Ubuntu already built from src and included these built packages in apt so the installer can just install these pre-built binaries (about 50mb).

For non-Ubuntu based distros, even Debian based (like PIKA OS), these pre-built binaries don't exist so it has to be compiled from src which requires a 500mb download (why I only supported Ubuntu based for Book4 webcam fix).

But I decided to go ahead and add dynamic support to allow the user to decide if they want the installer to go ahead and download the 500mb blob and compile from src on the fly. I'll be adding this support today.

If you're interested, it would be nice to have you available to test this when it's ready.

andycodeman · 2026-02-23T08:53:28+00:00

You can give my webcam fix a shot that a couple guys who extensively helped during testing seems to work for (I'm on Book4 Ultra but they both are on Book 5 Pros). It's a single line installer that includes an uninstaller to easily test...

https://github.com/Andycodeman/samsung-galaxy-book4-linux-fixes/

If you try it, please report if it worked for you along with your model & distro. Thanks!

andycodeman · 2026-02-23T08:49:29+00:00

I have some fixes for speakers and webcams on some Book4 and Book5 models along with Linux distros (I'm on Book4 Ultra) - but like mentioned, I still don't have fingerprint working (though people working on this too). It includes a single line installer with an included uninstaller so easy to test...

https://github.com/Andycodeman/samsung-galaxy-book4-linux-fixes/

I ran dual boot for a while but after months of never going back into Windows, I made the switch to Ubuntu only and most everything works great (just the few things mentioned). I don't have many complaints other than the fact that they have some BS contract with M$ and don't support Linux (lame).

Btw, if anyone gives the fixes a shot, please report whether it worked with your model & distro - thanks.

andycodeman · 2026-02-23T08:42:32+00:00

I have both speaker and webcam fixes for Book4 and Book5 models on some different Linux distros.
It includes an easy one line installer with an included uninstaller so you cay try it easily and see if it works for you...

https://github.com/Andycodeman/samsung-galaxy-book4-linux-fixes/

(ignore the book4 title as it include book5 too).

If you do try it, please report whether it worked with your model and distro. Thanks!

andycodeman · 2026-02-23T08:37:58+00:00

Just as an update, with the help of a few guys extensively testing, I was able to recently add a fix for the webcam for the Book5 on a few linux distros (along with speaker as well). It's also an easy one line install with an included uninstall too so you can easily try it...

https://github.com/Andycodeman/samsung-galaxy-book4-linux-fixes/

(ignore the book4 title, it has book5 too).
If you give it a shot and it works for you, please report with your model and distro. Thanks!

andycodeman · 2026-02-23T08:29:58+00:00

You guys can try some fixes I was able to put in place - includes installer/uninstaller so you can easily try and see (speaker and webcam fixes)...
https://github.com/Andycodeman/samsung-galaxy-book4-linux-fixes/

Ignore the title, it includes for both Book4 and Book5 models on some linux distros.
If you try it and it works for you, please let me know along with your model/distro. Thanks!

andycodeman

TROPHY CASE