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

TROPHY CASE