The default Session Strategy needs to be "per-session", or else it actively hurts new users

[wary valley]

This is in response to @junior marlin 's message here - #hermes-agent message .

I just wanna be really clear about this: The default being "per-directory" is a genuinely not-good default for any LLM CLI agent. That kind of thing should be opt-in, not opt-out. Most people's mental model of a CLI tool is that each invocation is independent. Sure, it makes sense for a persistent assistant you want to "pick up where you left off," but that's only the case if you want to, every once in a while, ask one really tight specific question to an agent with a REALLY tight scope. Most conversations with AIs simply don't fit that description, especially when you're setting things up and figuring things out.

With "per-directory", every new session from the same directory calls session.context() on the same persistent Honcho session object, which returns the accumulated messages from all prior runs there. That history gets injected into our context window automatically, and it grows without bound the more we use the agent. That means if your context window is full or nearly full, your context window in the new chat will be too!

We get no obvious signal this is happening until, at some point later, we notice our context window is filing up like crazy - and it does so again and again no matter how many times we restart the conversation - and every single time, just starting the conversation uses up all those tokens again - and I don't think I have to point out why THAT IS REALLY BAD for most people, especially people new to this. You are literally repeatedly paying for the entire conversation all over again every time you start it *(not exactly accurate - it's what it gets back from Honcho from previous conversations - but the context window still fills up immediately upon starting a new conversation, and users pay tokens for that.)

(cont'd...)

With "per-session", Honcho still works exactly as intended, but each run gets a fresh session ID, session.context() returns nothing (since it's a brand new thread), and we start clean. I have to wonder if people saying "no, the default should be per-directory" are perhaps worried about Honcho or Hermes's memory features not working if it's "per-session"... but they definitely do.

Like, seriously, isn't Hermes (especially with Honcho) built to store up information about your preferences over time? Literally created so you don't have to have massively long conversations just to have the AI remember things you wanted it to do? "Per-*directory", "per-repo" and especially (heaven forbid) "global" Session Strategy (good god why does "global" exist) are exactly what the memory tools and integration with Honcho are supposed to make unnecessary. Again, they should be opt-in. The default needs to be "per-session", otherwise you're going to cost new users a lot of money and time and definitely frustration.

(written by a real human who had to figure out the hard way why OpenRouter was repeatedly eating $5 thirty seconds after I added it. It was this.)

(PS: But at least I figured out why Honcho wasn't working! And you'l never believe it: after several hours of banging my head against the wall, it turned out IT WAS BECAUSE OPENROUTER WAS OUT OF CREDITS suddenly and unexpectedly, i.e. ALSO BECAUSE OF THIS EXACT ISSUE. 🙃)

To be clear, I'd been using Claude Sonnet via OpenRouter - but it was a darn good thing I was, because otherwise, all I would have seen is my Codex subscription suddenly and unexpectedly hitting my 5-hour window again and again. And I probably would have blamed Codex, when in reality the issue was that my context window was being loaded with "all the previous chats that have ever taken place in this directory".

[distant vector]

@junior marlin I think the UX complaint here is pretty fair, but the ownership boundary matters:

the specific sessionStrategy behavior being discussed here (per-directory, per-session, global) is coming from the Honcho plugin/integration layer, not from Hermes core’s base session model

so users will absolutely feel it as “Hermes kept dragging prior context forward”, which makes it a valid support issue from our side

but technically this is a Honcho-side default/behavior question more than a universal Hermes-core session default

the one nuance i’d add is that it’s not literally just replaying the full old transcript verbatim into every new prompt. the stickiness is more like reused Honcho session continuity plus Honcho auto-injected recall/context in the default hybrid path

but i do think the main UX point still stands:
if someone expects a fresh CLI run to start clean, per-directory can be a pretty bad surprise, and per-session is a very understandable preference

also worth noting there seems to be some docs/help drift here too, because not every path is describing the same default consistently

[wary valley]

not every path is describing the same default consistently
Oops, fixed now (hopefully).

t’s not literally just replaying the full old transcript verbatim into every new prompt. the stickiness is more like reused Honcho session continuity plus Honcho auto-injected recall/context in the default hybrid path
Thanks for the clarification, it's really helpful as I learn all this stuff.

Wait, so during the setup wizard, does Hermes not have control over which option is selected for Honcho's default? Genuine question; I assumed Hermes could control that because I'm within Hermes when setting up Honcho.

[muted sand]

When you run hermes memory setup, each of the installed memory plugins is listed, and they all have different options. (Honcho does let you choose the session strategy at that point).

[wary valley]

It does, but there's a default, and that default is "per-directory". It's not explicitly clear that that means "any time you're in this directory, your context will be loaded up with all the conversations that previously took place in this directory, and that might seriously bloat your context window it in a way that is almost always a bad idea".

I'd argue that when a new user sees "default", they tend to think "this wil act the way I'm used to similar things acting." And that's not the case here.

"Per-session" is the expected bahavior for starting a new chat with an AI.

[junior marlin]

Hey Cygnus, I have a PR open that changes the default strategy to per-session on the setup CLI, and adding a context cap of 800 tokens to the default behavior for session strategy with more configurability going forward. Also adding more information about the defaults and options to the honcho skill so when folks are setting it up agentically there should be more transparency for both agent and user. Thanks for raising these issues and appreciate the time you took to share your concerns!

[wary valley]

Awesome!
One question -

adding a context cap of 800 tokens to the default behavior for session strategy
What do you mean buy that exactly? Do you mean:

• A) setup will try to explain the difference in 800 tokens
• B) users will only get 800 tokens to use per session
• C) it'll only pull 800 tokens' worth of content from Honcho memory
  Or something else?

Asking because that's a pretty tiny amount of tokens for some things, and I wouldn't want to accidentally limit something too much 😅

[fervent galleon]

yo

please link me up to the PR

[junior marlin]

valid question -- along the lines of C) but meant to say it will ship with no cap but if people want a limit then it might be 800 but after testing could probably bump it up to 1200 and have people configure form there. really depends on which models people are using & how much context they have, but in your case -- don't want to have things become unbounded quickly and a cap might have prevented that.

when the auto-injection is limited it should also be able to make a tool call for honcho get_context when necessary.
in any case, as the user you will have the ability for more configurations once this PR is merged!
docs will be updated as well to reduce drift .

[junior marlin]

you got it . https://github.com/NousResearch/hermes-agent/pull/6719

making one more pass on it this AM

[fervent galleon]

lmk once its ready to review

[wary valley]

Badass, thanks!

[fringe root]

Hi @junior marlin and thanks for the updates to our lovely honcho. I'm going to change from per-directory to per-sessions (i've already updated config and made my first and now I have a dated session in https://app.honcho.dev/explore?workspace=engine&view=sessions )

i'm wondering if, as a result of my config update, existing hermes sessions will continue to use the same dir-based honcho session (my home dir has the super long 3 week honcho session) or if these long running hermes sessions will get hooked to new honcho sessions?

I'd prefer the former i guess. and going forward all new hermes sessions will be roughly 1-1 with hermes and honcho.

[junior marlin]

the updates will have no breaking changes for your current configurations! changes will only take effect for first time setups. if you run through the hermes honcho setup or hermes memory setup commands there will be new settings available for you. but the settings you have should be auto-detected through the setup process -- lightly check before hitting enter on all of them if you choose to reinitialize 🫡

[steady granite]

For testing, I deployed Honcho Memory locally. But when it comes to auto-injection, I’m not seeing any activity in the Docker logs. Feels like I might be missing something in the settings—any idea what could be off?

Also ran into a model-specific issue. Some LLMs use different JSON schema formats (like DeepSeek vs others). So for local deployment, I had to tweak a couple of things:

In src/utils/clients.py, switched json_schema → json_object
In src/deriver/prompts.py, explicitly added the word “json” in the prompt

DeepSeek needs both:

response_format: json_object (not json_schema)
The keyword “json” in the prompt

I’m using DeepSeek via LiteLLM, so I had to make these adjustments.

Now the question is—what’s the clean way to handle this? Ideally, I don’t want to hardcode DeepSeek-specific changes. Is there a better approach to keep the original code intact and add some kind of fallback or model-specific handling layer?

[fringe root]

My question was about what's the effect of changing the setting on the behavior of Hermes and Honcho going forward.

[junior marlin]

oh i see, chaging it to per-session from per-directory is best if you work on many different things or want to start a bit more "fresh" per session . the user-modeling aspects of honcho will be there no matter what but if you are always working in the same folder, the history will not be there automatically on the honcho side.
for me, i run honcho with per-directory because my workflow is project based and i like to switch projects frequently from my computer and i can pick up right where i left off.

[junior marlin]

hmm you're not seeing any .chat() or .context() calls when running this command docker compose logs deriver --tail 20? what about hitting the health check curl http://localhost:8000/health ?
let me dive into the questions about deepseek and get back to you on that

[fringe root]

For background, I think I have more of the 'basic' use case that @wary valley referred to. I always just start hermes in my home dir and then have it do various tasks. I start new hermes sessions to manage context. So because I used per-directory, I effectively only have 1 honcho session but many hermes sessions.

My question was more about how the identifiers are managed between hermes and honcho. Once i start a hermes session, is the honcho session id it stared with permanently associated with it regardless of the change to sessionStrategy ?

I think it would be helpful to highlight the impact of this session connection on high level agent behavior in the hermes docs.

[steady granite]

can i share here some useful tutorial based setup for multi domains with multi profile setup /??

[junior marlin]

so once you change to per-session honcho will begin to auto create new sessions coinciding with every new hermes session and should share the same session_id that hermes creates. will definitely make this clearer in the docs for this next PR