Last Week
Last week, running out of Codex usage showed me how much I depend on AI assistance to keep development moving. I could still investigate a problem manually, but doing so took much longer than the workflow I had become used to.
I still see these tools as another useful layer of abstraction. Using them well takes judgment and skills of its own. The problem I need to solve is having so much of my work depend on access to one provider.
This week, that search led me to Hermes Agent. I have spent most of the week setting it up, exploring its memory system, and getting local models to work with it. I think I am about 70–80% of the way there. That is my estimate of the setup work, and it is definitely not fully operational yet.
Shokken is available on Google Play and the iOS App Store. Most of this week’s update, though, is about the tools I use to build it—and how easy it is to get absorbed in those tools.
The Decisions Between the Lines
I have been using OpenCode alongside Codex. Being able to connect the same coding environment to different providers, including models I host myself, is exactly the kind of flexibility I want.
The difficulty in my setup has been keeping decisions intact through compaction. When a conversation grows too long, the agent needs to reduce the older context so it can continue working. In my OpenCode sessions, that process has repeatedly lost details I expected it to retain.
An implementation plan saved to disk helps. The agent can read it again after compaction and recover the requirements. But a plan rarely contains every small decision that comes up during development.
Some of those decisions happen in conversation. I might choose an approach that is unusual but appropriate for what I want. The agent follows that choice until compaction, then continues with a fresh context and makes a different decision. The written plan is still there; the clarification that made it work for me is gone.
I do not want every small correction to become a separate documentation task. I want the agent to preserve those decisions alongside the plan.
Remembering What Matters Now
There is also the longer-term question of how I like to work. For example, I want concise responses that highlight the important changes. I am trying to get something done, not read a novel every time I ask for an update.
Instruction files can express that preference. Project instructions are useful for project requirements, and global instructions can carry preferences across repositories. The problem I run into is that these files keep growing.
I can write down how I want implementation, review, and investigation handled. But if all of that is loaded together, an agent doing one job also receives instructions for several jobs it is not doing. That uses context and adds material that may not help with the immediate task.
What I want is a memory system that can bring in the relevant information when it is needed. A preference should survive beyond one conversation without every remembered detail having to appear in every turn.
I have not exhaustively investigated the memory options in OpenCode. This is a description of what has been missing from my own workflow, rather than a claim that it cannot be added there. Hermes caught my attention because memory is a central part of how it presents and organizes the agent.
Trying Hermes and OpenViking
Hermes Agent is broader than a coding assistant. It can work with a repository, but it is also intended for tasks outside programming. That broader role was not what initially interested me. Its approach to remembering the user and the work was.
The built-in memory starts with bounded files for the agent’s notes and its understanding of the user. That is a useful starting point, although I still want more selective retrieval as the amount of remembered information grows.
I settled on OpenViking, which I am hosting locally. Hermes has a built-in integration for using it as a memory provider. It handles storing, recalling, and extracting useful information from conversations.
In practical terms, I want the system to remember things about how I work, then retrieve them when they matter. My preference for a short summary should not require another reminder every time. The same idea applies to useful facts and decisions from earlier work.
That is the attraction. I am still finding out how well it will work for me over time.
Getting there has taken more effort than I expected. I found the interface clunky, and the installation needed a fair amount of personalization. I have been using my existing AI subscriptions to help bootstrap the setup. Connecting a model is only the beginning of making the whole system useful.
Local Models Are Useful Again
I had largely stopped following local models while I was paying for the hosted tools I preferred. Repeatedly running into usage limits brought me back. I do not want to spend so much time scheduling work around an allowance and deciding which tasks I can afford to run.
One pleasant surprise has been Qwen3.8-Flash-Next. I am running it on my AMD Ryzen AI Max+ 395 machine using halogen-flash-server, a third-party inference server.
At Q4 quantization—a reduced-precision version that uses less memory—it has been surprisingly capable for the work I have tried. Over about three days, I noticed two failed tool calls and two turns that ended prematurely. That is not perfect, but it has been useful enough to keep working with.
The inference server has shown more than 40 tokens per second with a fresh context and more than 20 as the context gets long. Hermes reports somewhat different figures: roughly the mid-30s with a fresh context and the mid-20s with a long one. These are observations from my setup, not a controlled comparison, and I have not established why the reported numbers differ. The practical result is that it feels usable.
For work that involves a lot of output but less judgment, I also have the 5090 in my closet server. I have been experimenting with Qwen3.8-27B there, using Q5 quantization and two context slots of roughly 131,000 tokens each. The point of splitting the capacity is to let two agents run at the same time.
I have been seeing throughput above 40–50 tokens per second on that setup. It gives me another option for getting through larger volumes of routine work without sending everything through the main model.
Those pieces are promising. Making them cooperate reliably is the part I have not finished.
One Slot Is Not Enough
The most instructive problem this week was concurrency: the ability to handle more than one model request at a time.
The visible conversation is only one part of the system. There is the main agent, there may be delegated agents, and there are auxiliary model calls for jobs such as generating titles or checking whether a proposed action should be approved.
In my local configuration, the 128 GB machine running the main model can effectively serve one slot at a time. That becomes a problem if the main session occupies that slot and an approval request is sent to the same endpoint.
The main task needs the approval result before it can continue. The approval request needs model capacity that is already occupied. Without another route for that request, it can get stuck.
I could try to configure the server to switch between the jobs, but that brings latency and scheduling problems of its own. The important lesson for my setup is that being able to run the main model does not mean I have enough capacity for everything the agent system asks it to do.
My current workaround is to send auxiliary requests to an online service. They are relatively light traffic in my workflow, and giving them a separate endpoint relieves the pressure on the local server. That makes this a mix of local models and cloud services.
A cloud fallback is another option I am considering: if a local auxiliary request cannot be serviced, another model could handle it so the main task can proceed. Either way, these routes need deliberate configuration. They do not appear just because I have connected a local model to Hermes.
Next Week
This has been more involved than I expected, and also more fun. That is part of the problem.
I think I lost sight of Shokken while working on the tooling. A new tool is interesting, there is another configuration to try, and it is easy to forget why I wanted the tool in the first place. Tools can become toys very quickly.
I still think Hermes could improve my programming workflow and give me a practical alternative when access to Codex changes. I can also imagine using it for work outside programming. But it remains an experiment, not a finished replacement.
Over the next few days, I want to get the setup operational and bring my attention back to the product it is supposed to help me build.