#When connected via Localhost (omniroute), stops reading MEMORY.md, and immediately starts search

1 messages · Page 1 of 1 (latest)

spark plank
#

agent: https://paste.rs/DnAKa
gateway: https://paste.rs/kanTe

I have some complete nonsense going on, I don't really understand when I connect it through a local host through an API in which I use CHATGPT5.5-XHIGH via omniroute it doesn't recognize information about me it doesn't read skills and it doesn't improve itself and it doesn't even read memory and doesn't know what kind of AI it uses, At the same time, if you directly connect a сhatgpt (etc. codex) he will understand who he is, read skills, use everything, and so on. That is, I don't understand, it only happens when I use it with omniroute.

noble delta
#

This does not look like Hermes failing to find MEMORY.md. The debug dump shows built-in memory is active, and your screenshot from the direct Codex path shows Hermes can read /home/user/.hermes/memories/USER.md and /home/user/.hermes/memories/MEMORY.md.

The difference is the localhost route:

custom (cx/gpt-5.5-xhigh) through http://localhost:20128/v1/

So the next thing to test is whether omniroute is passing tool schemas/tool calls correctly.

While using the omniroute model, run these two prompts exactly:

Use the read_file tool to read /home/user/.hermes/memories/USER.md and /home/user/.hermes/memories/MEMORY.md before answering. Then tell me the first heading or first sentence from each file.

Then:

Use the skills_list tool and show me the first 5 available skills.

If the omniroute route answers without calling read_file or skills_list, then this is not a MEMORY.md issue. It means the omniroute/custom provider path is not behaving like a working Hermes tool-calling model.

If direct Codex calls those tools correctly but omniroute does not, please paste the tool activity from both runs. That gives us the useful comparison:

direct Codex: tool calls work
omniroute/custom: tool calls missing or malformed

At that point the likely fix is on the omniroute/custom-provider side: it needs to pass OpenAI-compatible tools/tool_calls through cleanly, and the model route needs to support tool calling. If omniroute does return proper tool calls but Hermes still ignores them, then we can look for a Hermes adapter bug.

noble delta
#

Were you able to test this against a known good provider?