Client Software Stack — What I Run

We’ve covered the hardware, the OS options, and the Servers. Now to get to where the rubber meets the road - the client software. This is the stuff you actually see day to day as you’re working with your own processes and data, so in effect it is the most important part of the system. It is easy to just log into a site or download an app that is pre configured to run against someone’s hosted service or SaaS offering, but to run against your own resources, takes a bit more care. I’ll go through what I use on a regular basis for my work, and why those particular tools have made it to the top spots in my workflows. These aren’t the only tools, I use, but between them they handle probably 90% of all the LLM based work I do. And hopefully this will either help you find tools that work for you, or at least give you a better idea of what you should be looking for when you choose your client application(s).

Criteria for choosing:

• I strongly prefer local installations, normally Windows-based as that’s my primary work box. Web interfaces have taken off because of their cross platform accessibility and easier deployment management (deploy once, access multiple locations.) But when working with files and items, local tools still have the edge in both usability (for me) and access to local resources such as files and network connections.
• If I’m installing something, I look for apps that have active communities. The space is moving very quickly and there are a lot of Write-Once apps being released. I don’t want something that works today, but when it needs to be updated to work with a new feature or capability, I’m on my own to implement that. An active community means that while I can implement something I want, many things are being worked on normally and problems or new features may be done without me taking on that side quest myself.
• A good UI. This is not just cosmetics (though that is a factor), but that features are discoverable and things like settings are available for what I need. Too often I run into something that’s ALMOST what I want, but something is hard coded that I need changed. If it’s a GitHub repo, then I can most likely go in and change that myself, but at that point I’m either going to be stuck on my own fork of the repo, or I’m going to have to go in and work with the maintainer to get my config management change into the main branch. Both of which are doable, but a speed bump for working on projects, not just on the tools for projects.And I’m not talking GUI - I very commonly work with command line tools which have a good UI. That (to me) primarily consists of having good –help information, but it not being 5 pages of options you have to sort through to get a task done.
• And with said, the last (and most common deal breaker) item is - it has to actually work with local resources. Far too often I run into packages/apps that have some great features but have decided to simplify running them by just having API keys as config options. So you’re tied to using some specific hosted solution. Again, I have gone in and done updates on tools like this if they offer a git repo, but I rarely stick with those tools just because of the maintenance concerns.

The actual clients

Custom C# clients

Before I start evaluating a git repo or downloadable package, I see if it is a good fit for a custom client.
1 - C# is kind of my first tool in my toolbox. Cross platform, simple tools to develop with. And I have a long history of experience with it.
2 - The entire purpose of this exercise was for me to really learn how everything fits together. And this is where the rubber meets the road. If I can use this, then I’m both getting the functionality and the learning benefits together.

I use this for things like custom scheduled jobs, interfaces into other systems, and process managers such as data classifiers and managers. I actually will be going through creating an information management app later on in this series to show just how you can use the tools to build the tools you need.
Of course the downside is - you have to build it. And while there are lots of people who love vibe coding and YOLOing it, you really do have to be prepared to read and understand what is being generated if you’re using tools - even if you don’t write the code yourself. Fortunately, that’s what I’m here for. You may or may not want to take this path.

OpenCode

Opencode is actually my third coding helper I’ve really used. I’ll cover the previous two (GitHub Copilot and Roo Code) in the next section to cover why they’ve fallen out of my top drawer tools, though I’ll still reach for them if I need to.
OpenCode has the advantage of working both as a stand alone tool and a plugin to Visual Studio Code. Each has advantages and disadvantages, but the commonality, lightweight footprint, and ease of use of OpenCode means it is one of the first things I reach for.
It comes with two types of Agents - which are Build and Plan. Those are mostly focused on managing what OpenCode can or cannot do while it is working. I find it very useful to use Plan mode when I’m asking a question as it has a tendency to go “It was easier for me to do it than explain it” when I ask a question and go off and make a lot of changes. Plan prevents that from happening. Then you can seamlessly swap over to Build mode when you’re happy with the plan.
The downside is that it can be a bit involved to set up initially and maintain. You’re going to have to edit multiple .Json files and which ones are used have actually changed as the tool has evolved. So if you just want an “install and go” option, OpenCode probably isn’t going to be for you. Another item that has bitten me with it is that PowerShell functionality has not been perfect. Path processing has had periods where it was broken for PowerShell, and unfortunately it tends to break in a permissive manner, letting OpenCode reach locations it really shouldn’t. The situations have been patched fairly quickly, but it does add a bit of risk to consider.

• OpenCode CLI
  I mostly use this for either general planning, conversations, and if I just need to YOLO something like a shell script.
  It’s quick, very lightweight, has a very active community, and is easy to create or add skills to extend its capabilities. It seldom gets in the way, and can do some pretty impressive things without you having to spend a lot of time setting things up. As a matter of fact, the biggest setup config you’ll probably run into is that if you’re using local servers/models, you’re going to have to do that previously mentioned .json editing so it can know what you have. I’m sure sometime soon the ability to auto read the models you have will be there, and Lemonade server has some really nice auto-config stuff built in, but for now just know it’ll take a few minutes to get things going and then you get to choose how much deeper you want to go.
• OpenCode Visual Studio -
  Basically most of the benefits of the CLI, plus the ability for it to really work with Visual Studio Code’s Editor and compiler support. Drop it open in a tab, then it’ll work with the rest of VSC to act as your coding assistant or QA tool. You can still YOLO, but if you’re taking this route, you’re going to have a LOT more control over what you’re creating and be a lot more productive (IMHO.)
  This has taken the place of Github Copilot (which requires a paid plan for most things) and Roo Code (which I used previously but had a pivot/branch situation.) As you can tell from the writeup, this is currently my primary tool for many tasks.

Hermes Agent

Hermes Agent is a newer tool to my toolbox. When everyone went wild over OpenClaw, I was one of the skeptics simply because there were so few guardrails and so much of the stuff that was showing up in the add-ins for it were malicious. But the draw of having something operating as an orchestrator was strong.
So with that, I decided to try out Hermes Agent, mainly on the promise of it being more self-improving. Basically the ability for it to custom generate skills vs pulling down packages others write and running them locally. It’s not bulletproof, but it did seem an easier bet to manage.
I have it currently running in a “sandbox” of an old Intel NUC I had lying around from a previous project (N100 processor.) So I’m not trusting it with everything, but I did give it the run of that box. For me it was a good trade off in limiting blast radius but leaning into that self-improving promise.
I won’t say that setting it up was the easiest, and I’m still testing things like extended memory systems and what data sources I can open it up to, but once it is running, I’ve actually been pretty impressed. It CAN go off on a tizzy at times, but it is much better at giving larger items (with good instructions) and letting it churn overnight when I wouldn’t have had load on my local Lemonade server. That’s kind of a different way of working vs the cloud model where you count (or at least SHOULD count) the costs of letting things run unsupervised for longer periods and hope something comes out at the end. With the local server, if I’ve got some idle time, I might as well have something running, it’s not costing me any more.
The interface is also interesting. It defaults to a CLI interface on the box, has lots of web and native client interfaces. I’m still testing and working through that - for example getting Voice mode working in the Hermes Desktop app took several hours of troubleshooting and the Telegram client still seems kludgy.
I’ll likely do an article on the specifics here in the future, as there’s a lot in here. I know there are already a good many tutorials on how to use it, but it really seems like almost everyone has a different usage pattern, so I’ll look at giving you mine.
So to wrap this section up, Hermes Agent is a new addition, but I’m rapidly finding places where it is useful for me. Longer running tasks and general multi-systems orchestration being the main things right now. If you need a larger, heavier weight system that can do scheduled tasks and longer running goal seeking, this might be something for you to look at. Just know it isn’t a one click setup, and the community is active enough that you’re going to have to spend time keeping up with the current state of it - choosing what to bring in and what to generate yourself.

AnythingLLM

And on that note - AnythingLLM is kind of the opposite side of the coin. Easy to set up, good support, focused on very targeted, specific use cases. AnythingLLM is more of a Knowledge Worker’s tool. It isn’t going to be your coding assistant or self improving system, but if you need something like Google’s NotebookLM but local, AnythingLLM fits that space.
It is a native client that can run an LLM on its own, connect with a local server, or connect to a cloud provider. A nice thing is that to do any of that it doesn’t need a side car or some other helper to work, it just handles things.
It has its own add in network, and is fairly simple to add an MCP server or a custom skill to. It is probably the best tool I can name to both have a Good Enough option built in but also be able to add external capabilities if Good Enough is no longer good enough.
It specializes in creating local knowledge bases and document stores to index and query against. It also has a super easy context management with Workspaces and threads under those. It has also added a meeting assistant semi-recently where you can use it to locally manage meetings and give results afterwards.
It integrates easily with my local LLM stack and even my NUC based databases. It is the lowest friction of any of my primary tools to get started with. All in all, if you’re local, not coding, and not trying to create a whole always on system, AnythingLLM is likely what you’re looking for.

OpenLumara

This is my latest addition, and we’ll see if it sticks. It overlaps somewhat with Hermes Agent, and can install and live along side it if you’re doing something like I am with the Intel NUC. The goal of it is to be lighter weight than Hermes/OpenClaw thus allowing you to configure just what you’re looking for. The result should be a more targeted system that stays on course better and costs less. It is still in heavy development and I’ve got the least feedback on this one of the four packages here. But there was a lot of noise about Pi.Dev and its benefits, and the author is very active in the Lemonade server Discord, helping people out trying it and getting feedback about how to make it more accessible.
If you like the idea of Hermes/OpenClaw but want something lighter weight, want a Pi.Dev alternative, or just want something where the author is super accessible - this might be for you.
I’ll try to loop back around as it develops to give updates as it matures.

How to Choose: Decision Guide

Actionable Takeaways & Next Steps

So now you’ve got the rundown on what I use day to day. My workflow didn’t start here, and I’m sure it won’t end here. Every one of the tools listed above are actively changing and have strong communities helping guide where they are going. But the space is incredibly active and dynamic, the key is to keep evaluating what things are coming out, while not just spending all your time just looking at new things.
The balance is to not thrash changing tools, but to ensure you do set aside some time every week to evaluate how your current workflows are going and see if you might need to add or migrate them to something new. I normally try to spend around an hour evaluating my usage over the week on Friday afternoon, and if I see anything that I should probably be addressing, I put it on my task list for the next week. That way I check while it’s fresh in my mind, but I also let it sit for a bit so I can evaluate it with fresh eyes on Monday when I set up my week.

Feel free to give me information about tools you use that I may have missed or underappreciated, I’m always interested in hearing what works for everyone else.

And if your favorite client wasn’t on this list - it might be in the next article - “Client software stack - the road not taken” where I’m planning on covering a number of tools that either were part of my stack but I don’t use as much any more or ones that at least were promising enough to get an install and a decent trial.

See you then!

Originally published on Substack on July 10, 2026.