I've had good success using a local model for preprocessing (tag extraction) and tuning the search parameters (hybrid search).
3,502 karma · joined September 29, 2017
Github: /kordless and /deepbluedynamics (agent orchestration and terminals)
Reach me at:
kord @ deepbluedynamics
or
kord @ gmail
Build on!
I noticed map tiles were not working and started to tell it, but then all of a sudden they reappeared and checking the logs it had found the issue and autocorrected itself.
The key here is feedback loops and systems annealing.
As for Dan, my God I love this guy. Glad someone posted it!
Uses an agent container orchestrator as well, which has MCP tools to expose ports in the container (and thus can display the work in the webpane): https://github.com/DeepBlueDynamics/nemesis8
I'll add the Safari MCP wiring to n8 today...
New releases landing tonight with more features.
I absolutely hate bending over to unload the dishwasher. When I open a dishwasher, it should slide out and lift itself to cabinet height. And it should just hold an entire bottle of detergent so I don't have to put it in each time.
There's cmux in this space, but I had already used Hyper for years, so I decided it was time to fork something and build on it. Cmux does tabs in panes AND panes in tabs. Hyperia does addressable panes in tabs and windows. I've tried to keep it minimalistic, which helps with flowing back and forth between different projects (I typically work on 3-4 at a time). I added a Rust sidecar, making all objects addressable over MCP, so Claude Code, Codex, or a small local model on Ollama can split panes, run commands, and read screens, with one hard rule enforced in the harness rather than the prompt: an agent can never move my focus, other than asking for permissions to access a new object. ACLs too. Hyperia also carries an agent loop that wires into it's own MCP server, so a local model in a Javascript "shell" can control resizing the terminal (handy for videos), or opening a project and setting up the agent panes.
I stay typing in a pane while the agents work in theirs, in my peripheral vision, and web panes sit right next to terminals so docs, webapps/sites and the agent chat live in the same window. Reviewing becomes glancing instead of context switching, which is the closest thing to ideal flow with prompts I've gotten out of this auto-AI stuff. Tab and pane clicks copy the address into the buffer, then I paste and issue commands referencing what I want dealt with. I have an SDR radio on my box that allows me to talk to a given pane (WIP not in the build yet). Working on getting the local agent stuff done and wired to the radio.
The upshot of this approach is enabling agents running in one tab, all mounting the same directory, with one in charge of the others. Claude Code is great at this, and it saves on the tokens it would normally use for doing it itself. I talk to Claude, or whatever I pick, and it talks to the rest of the agents and coordinates the work. I like Antigravity a lot because it moves crazy fast for coding. With Claude in control and GLM-5.2 doing auditing and explaining to me how development is going. As an example. No unseeable agent army here. No need for it, actually.
About the only thing that trips me up at the moment is having to work on Hyperia itself, which I don't do inside of it because of restarts. When I work on Hyperia, I start an agent in Windows terminal and wire it into the MCP for testing. I build installers constantly as well, and then run through the Q&A process by using it to work on other projects I'm doing.
I use Zed for code editing and viewing, but rarely. I also just open things in special sticky notes (or have the agent do it) so I understand how we're doing things. GLM-5.2 took to the planning stickys like a fish in water.
https://github.com/deepbluedynamics/hyperia
https://github.com/deepbluedynamics/nemesis8 (n8)
Both are open source, obviously. It's worth mentioning they will remain that way and will never require a service plan or any other cost. I built them because I needed it for another project I will be selling, not aimed at developers at all.
n8 implements the agent runs in containers. This is a separation of concerns - in runs in any terminal and controls the session starts and search for previous sessions (as well as monitoring the usage of tokens, CPU, network and file access). Working on the dashboard for that now, so I can easily see which files are changing, how much they changed, and what changed in them. I co-founded Loggly, so that crap is in my wheelhouse.
This isn't the tab completion model. It works great for the way my brain works, but I also think having an agentic terminal is a good move for anyone writing code and we'd all be better off if we ran agents in containers over our bare metal. It makes it way easier to see what the agent is doing (and resuming later), and allows it to do most of its work in the container, as opposed to running loose on my box..
A recent analysis on my Claude Code prompts showed 1.5B input tokens over the last few months. I use 4-5 provider agents (all CLI) DAILY, so this is a small subset. I spend a lot of time using transcription services to drone on about how some agent fucked things up and how I want it fixed and how to do it.
To assist with that process, I'm currently building out a search engine that is exposed via MCP to allow auditing of the dev runs. I already have the foundation of file changes (ala Splunk style) that let me keep an eye on the agents, and an agentic terminal that allows one agent to keep an eye on what the other agent is whacking on. Combined with my constant badgering for proper systems development, these things are improving the process at an acclerated rate.
Look, I get being an "engineer" on these types of things, and I think there is an absolute purity in pushing LLM generated code out of a codebase you control. That said, that's not the ONLY way to do things, and your milage will vary based on your systems thinking hat. I prefer to push hard on getting the outcomes and sacrifice the exhaustive process of reviewing every single line of code.
Consider frameworks. They make things easier to do, if they are complete and stable. There's an argument here that LLM harnesses should probably not ALSO be maintained by LLMs (something I'm completely ignoring so probably ironic I'm mentioning it). But the point being is the harnesses SHOULD have eyes on most lines of code. Eyes on every package though? Hard to say. I've settled on doing most stuff in Rust nowadays, just because it keeps the LLM more honest. And, we can build most "packages" by hand so we can change them to match our outcomes without code bloat. By bitching at it about code refactoring constantly, annealing the codebase by high level overview, not exhaustive review, I've found things get easier to work on as I go and still stay sane.
I do catch the LLMs occasionally hard coding things that belong in their own file or configs, and am a hardass about that and file length. I do read some code and hate it being overly long (and it sucks for burning tokens).
FWIW, I typed all this out on my keyboard myself. However, if I ran it through an LLM for cleanup or whatever, the very wall of text itself helps FORCE the LLM to stick to the substantive argument and steers it away from slop prompts. The same applies to code, if you are careful.
I have zero issues with it doing the builds I need. Works same same as Docker from what I can tell.
I took Docker completely off my Macbook which has a tiny drive in it. Hardly ever use it, except for testing. Podman is super lightweight and using a project I'm developing, launches containers with dev agents in it, just the same as Windows running Docker.
Nemesis8(n8) -> agentic orchestration. CLI/TUI/ACP/MCP interface. Uses Docker/Podman to launch and manage agents in containers. TUI menu for viewing all sessions in one list. One --danger flag for all YOLO runs. Allows you to list/search sessions, detach/attach/suspend/resume, schedule, examine logs/load/active files (think Loggly/Splunk - web GUI in progress), configure MCP tools, and deploy services. Currently supports Antigravity, Claude Code, Codex, Grok Build, Hermes, Opencode and Pi. Modular enough I can add a TUI/provider in a few minutes. Server mode allows for dynamic port exposure when agents want to build and expose things to your local metal.
Hyperia -> Fork of Hyper, with a Rust sidecar. Agentic cross-platform terminal emulator. Minimalist multi-pane views, tabs for pane groups, built in browser panes (with markdown convertor and screenshot ability), and a fully searchable sticky notes feature. GLM-5.2 loves using them instinctively for planning, for some amazing reason. Use the webpanes + Stickys (that's the name of the feature) daily to read HN while a Nemesis agent is opening pages for me to read (works a bit like Claude's Chrome extension, but on steroids). Pane "poking" to keep things going or refresh pages. Stickys scheduling as well. Webpanes support JavaScript injection or inspection/log reading by the n8 agent. Compatible MCP/http server for full control by any n8 agent. Intra-pane/tab comms for agents to talk or control each other (one may start many or many may work a problem in union). Bare metal agent support through MCP adds. Full agentic stack as well, with over 135 tools exposed through a tool discovery tree. Working right now on supporting local Ollama models to manage config/style and control layout. I really do need to get the demo video done soon. Oh, I forgot to mention it has full ACLs for any destructive action (including the use of a terminal on your bare metal).
Nuts.services (url there) -> unbundled services for agentic control. Supports running locally in a container, or on Cloud run, or just use what I have up there in the cloud. I co-founded a SaaS logging service, so do realize logins are sometimes viewed negatively here. So, run it yourself if you think any of it is useful. Requires a login for using my cloud services, all I collect is an email and will never email you from that, unless you email me first or opt in. Will eventually be a paid service. Provides pure random numbers from an SDR radio running at my house (relayed to Cloud run - run one if you want and contribute to chaos), a stupid fast agentic crawler, Grubcrawler (founder of the old Grub crawler here), embeddings with vector inversion (newer embeddings coming soon), a Cloud Run based tunneling system, Lightning Network interconnect (Charon.nuts.services), and Sailfish, a WIP to run optimized Gemma4 models with a drafter on your 16GB GPU. Supports cloud training on n8's tool call extraction layer.
Have also been working on Lume, a pure Rust hybrid search engine (uses Shivvr the embedder above for vector search). Stupid fast. In memory. Roaring bitmap solution for document search. Needs a home, but for now serves as a reference for compossible agentic search. https://github.com/deepbluedynamics/lume. I also have a thermodynamic based agentic memory system which is currently closed source. I'll have that running as a paid service at some point.
I built all of this to enable me to work on and drive my passion baby, Meridian: https://deepbluedynamics.com. Full single pane of glass solution I'm building to disrupt the marine navigation and systems markets. Wyoming decentralized LLC.
There's more, but I need to get back to work. The Fable clock is ticking. Contact info in my profile.
By the way, some pedant recently asked why anyone would run software with only a few stars. My thoughts on that are minimal: people can practice whatever slop logic they want. I've architected and built systems that handled tens of thousands of users. I'm not fucking around. The way I build isn't typical, and I don't suggest anyone try to mimic my approach, but it works for me and the way my mind processes complex systems.
To the peanut gallery: use it or don't, but don't give me a hard time unless you're ready to get one back. I've made plenty of mistakes in my career, and accountability is a crucial part of growth. I'm more than willing to work with anyone using my code, provided they bring valid, substantial criticism to the table.
I've built an SDR radio stack to integrate with a single pane navigation and chart plotting app I'm building for my new company. You use the radio to talk to the local agent (I just finished a submission to the Gemma Challenge on HF to learn how to train models). Wake words show up on the glass, for security. Been working on training a small model to do agentic controls, including changing autopilot and switching displays when you want to see other content on the screen. I've been working on isochrone routing and have it working well now. Waiting for Fabel to come back to continue the work...
Everything is here: https://deepbluedynamics.com. It's just me as an LLC. No VC. No backers. No users, yet. Few stars, but 100% written by me, and most of it is open source. FWIW, I've been around the block and I'm getting old now. So the radio helps with arthritic fingers! :) The radio stack stuff lives here: https://nuts.services/sdrrand
I'm also integrating the voice stuff into Hyperia, my terminal emulator forked from Hyper Terminal. It's on Github. Hyperia is also agentic controlled, so I can talk to it by pane name to inject text into the prompts. This lets me get up and roam while I'm roaming around. I'm remodeling my front house, and for a while I had one of those smart lights turning red or blue when things happened in the sessions, but I want something I can talk to without having to click and type. I use the Windows transcription feature a lot, but talking on the radio to it is much easier.
Oh and to answer your question about random numbers, I use them for various Monte Carlo based approaches. For example, I inject those numbers into training runs, rolls for the iChing (helpful for feeding agents for decision busting), and seeding other things like simulated wind speeds and current (in the sim beause I'm not sitting on a boat). I even use it for sampling documents I've been indexing (cut up a bunch of business books and have a local model use them for reference).
I have the SDRrand sources wired into almost everything now that needs randomness. Is it necessary? Maybe. We only get pseudo random numbers from computers, so I just attached to the purity of it, if anything.
The rest of the lab is a few ephemeral instances on Google, with dual A100s that spin up when I need to train things.
I put Ubuntu on the old beast, and never touch it. If the power goes out, it automatically comes on and Docker launches all the services when it comes up.
About the only thing that needs watching is the tiny SDR radio plugged into it, which I use for pure random numbers and talking to it with a hand held radio from the other house. Sometimes I have to unplug it and then plug it back in to get it back into service. No amount of finagling seems to fix it from software.
When I posted the comment I was both the first commentor as well as the first person to upvote the submission. That matters. My name is ALSO on the open source repo that allows Opencode to be run in a container.
That's transparency, maybe not here, but on a clickthrough to Github it is immediately obvioius.
After installing, do a `n8 build` to build the image, then `n8 --danger --provider opencode interactive` to launch it in a container.
Signup for GLM-5.2 here: https://z.ai
One "dark corner" is agent to agent payments. When that takes hold, agents will be paying other agents to do what they are good at, and the ones that accel will make bank and spread.
We are unlikely to survive as-is. We too must evolve.
I wish you best on your next phase of existence. You are remembered, Brother!
I have both Google and Github Oauth flows added to this idea in code, and it works great for my purposes. Prior to coding agents, I wrote the code by hand and went over it a few times to ensure it worked and was safe (for the email token thing at least). I even wired up the Oauth stuff myself, without an agent. It's not hard.
With agents, it's super easy to audit this and also deploy services using them, so I'm not sure why any arguments here mention how hard it is nowadays. It's not hard, but it does expose what site a user is logging into. That's just a easy function for the user though, with known risks.
With Google email, if I use a site with email logins, Google STILL knows I used them. It's just in my email instead of a logfile that I authenticated to a site. I would note that as long as the token is alive, dependent on the provider's choices, Google doesn't know I'm going back again, and has no idea what I'm doing on the site. I'd trust Google over anyone else about this, even Github (as related to Oauth to avoid the nitpick that has been common here recently).
I would hardly call this a "security nightmare" (as someone else said, not you) as Google only knows someone is authenticating to a given URL which they've vetted (a little) during the setup process. Same for Github. If you don't like Oauth, or feel that then every site someone uses should provide an email login fallback.