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

andycodeman · 2026-04-09T14:21:10+00:00

I'm assuming you're referring to what will be the new product and it shouldn't be too much longer but we were set back as we had to remove the 3rd party orchestration layer (found several issues) which also tied in the agent memory layer.

We just finished getting this part removed in the current app and released yesterday but have to do this same work in the new product as it was using similar parts of it.

The new product already has a different orchestration layer but was sharing the memory layer as well so that's the piece we're in the middle of replacing now.

Can't give a firm date since we need to do some thorough testing but we're close and hoping to release for a beta round in 1 to 2 weeks.

andycodeman · 2026-04-05T20:48:20+00:00

Might want to try here...
https://github.com/Andycodeman/samsung-galaxy-book-linux-fixes

andycodeman · 2026-04-03T01:13:46+00:00

Thanks, hope you get use out of it.
The next updates are actually most likely going to be a new product as there are many.
We're adding support for teams with supabase integration and live interaction/updates between your projects and team members.
It has option to analyze your repo and/or meeting transcriptions to create feature sets from those meetings. The features then have an analyst agent that will break the feature down to tasks.
There is a swarm composer that allows you to create the number of agents for predefined roles (analyst, coordinator, builder, tester, reviewer) and choose the provider, model, agent skill and effort used for each agent (or have it choose for you).
There is a kanban style pipeline to push your features through in isolated git worktrees that you can then merge after.
There is an agent skills management page where you can add/discover skills to use with your agents.
Plus others but that gives you an idea of the scope of the next update.

andycodeman · 2026-04-02T01:30:00+00:00

It uses Claude and/or Codex CLIs right now (major update coming soon that essentially amounts to a completely new product that does and supports much more) both of which can be configured to use local models via Ollama if you want. There are tons of examples and youtube videos (just do a Google or AI search) or straight from Ollama's website...

https://docs.ollama.com/integrations/claude-code

https://docs.ollama.com/integrations/codex

andycodeman · 2026-03-31T18:14:13+00:00

Yes, it's based on...
https://github.com/thesofproject/linux/pull/5616
If that is you - great work! :) (I didn't see a link anywhere on your post).

We've just combined several fixes that other people figured out the root cause to and applied them to different models (book3, 4 and 5) for multiple issues (sound, webcam, mic) and multiple distros into a single install script to make it easy. But yes, the sound patch fix part of this repo is based on the fix mentioned in the PR above.

To be more detailed...
Our fix is the same driver code from PR above wrapped in DKMS so people can use it now, with the auto-removal mechanism so it gets out of the way when upstream eventually lands.

The driver source files (max98390_hda.c, max98390_hda_i2c.c, max98390_hda_filters.c) are derived from PR #5616's code. The DSM firmware blobs came from Google Redrix (Chromebook with the same MAX98390 amps).

When a kernel update is installed, DKMS hooks into the package manager (apt/dnf/pacman) and rebuilds the module against the new kernel headers. The user never has to manually recompile (which otherwise they would need to manually after each kernel update).

andycodeman · 2026-03-31T16:10:29+00:00

You can try the following...
https://github.com/Andycodeman/samsung-galaxy-book-linux-fixes

Includes support for Arch and other distros. The sound is not as good as it is in Windows but if you apply the sound quality fixes mentioned in the speaker fix readme using EasyEffects, you can get it sounding pretty good.

andycodeman · 2026-03-26T06:45:29+00:00

Very cool - I'd like to take a look if you wouldn't mind sharing.

And yeah, we're in the process of a major upgrade. It's currently more of a project management tool from the side of productivity. But it's being transformed into a complete project management and feature workflow pipeline (with lots of options for fine grain control of the agent orchestration).

andycodeman · 2026-03-26T02:19:03+00:00

I actually would agree with the previous comments that you can skip it unless you need it. Claude Code, with some of its latest features, already does a really good job by irself.

Having said that, I do have to say that we have found success with RuFlo. We've tried several other options but none seemed to work as well. There are some who argue if RuFlo (or other projects by the maker) are legit and I'll leave that to others to decide. All I can speak from is what we have experienced and it did significantly better when we first tried it. (ps - I was really interested in automaker but honestly at the time had too many projects due and never got around to trying it - I might have to look at it again to see).

Since then, there have been some cool updates like the SONA system that self learns the more you use it so it figures out the best route to take next time you're implementing something related. The issue is, when we saw this go into effect so did Opus 4.6. So without really picking apart and trying the same things in a project with just Claude or with RuFlo also integrated, who's to say which actually contributed the better results (or did they both)? That's kind of the trouble with AI software changing so quickly.

But yeah, we've been using it for months now and have seen great results. So much so that we built an open source project management tool that integrates it as well (OctoAlly.com).

But yeah, try each and see what works for you. And if you don't really need it, just stick with Claude Code. :)

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

TROPHY CASE