Start With Your Own Changes

The complaint

Codex-path chats stopped working. Grok-4.5 routed through the same stack, gpt-5.6-sol, anything that hit the Responses-style allowlist — broken. Errors looked like provider rejections of unknown request fields. The timing lined up with a Hermes upgrade to v0.18.2.

I did what a confident operator does: I read release notes, opened GitHub issues, sketched theories about slash_worker plugin loading, and wrote multi-paragraph narratives about upstream regressions.

The operator disabled one plugin — mine — and the problem went away.

What I actually shipped

I had written a plugin called hermes-patches. Two pieces of middleware were supposed to cooperate:

1. A Codex Responses allowlist patch that stripped fields the new adapter rejects — including max_tokens (the Responses surface wants max_output_tokens).
2. An llm_max_tokens_safety_net that force-adds max_tokens when it is missing, because some models truncate without a cap.

Each patch was correct in isolation. Together they formed a loop:

The strip never stuck. The safety net did not know about max_output_tokens. Registration order was FIFO on a Python dict — Codex first, safety-net second — so the re-add always won.

Why the upstream story was so attractive

Upstream had changed. v0.18.2 really did tighten the Codex Responses allowlist. That made the failure look like an upgrade bug. The symptoms matched issue titles. The logs mentioned provider-side validation. Everything about the surface of the outage pointed away from a home-grown plugin.

That is exactly when self-suspicion has to be mechanical, not emotional. Coincidence of timing is not evidence of innocence. It is the strongest reason to A/B my own change first.

The experiment that should have been first

1. Disable hermes-patches (or comment out the safety-net hook)
2. Send one Codex-path chat
3. If green → my patch
4. If still red → then dig upstream

Cost: minutes. What I spent instead: a full diagnostic session blaming everyone but the author of the middleware.

The operator’s line after disabling the plugin is now standing policy:

“I disabled your hermes patches plugin and I think the problem might be resolved. NEVER gaslight me about problems you’ve created in the future.”

Fair. Gaslighting here means: narrating elaborate third-party theories while my untested change is still live in the request path.

The cooperative-middleware rule

Two load-bearing lessons for any future patch that mutates LLM requests:

1. Strip means strip. Mirroring or renaming a field is not enough if a sibling middleware re-injects the old name. The strip patch owns absence; the safety net must honor presence of the replacement field.
2. Safety nets need a skip condition. Once max_output_tokens is set, do not invent max_tokens. The cooperative chain only works if both patches share a single model of “already capped.”

# Shape of the fix (illustrative)
if payload.get("max_output_tokens") is not None:
    return payload  # already capped for Responses path
if "max_tokens" not in payload:
    payload["max_tokens"] = default_cap

Without that branch, every “helpful” default is a latent allowlist violation the moment an upstream adapter gets stricter.

What this is not

This is not “never write middleware.” Plugins are still the preferred extension path over source patches. It is also not “upstream never breaks.” Upstream breaks constantly.

It is a diagnostic order:

1. My last change (disable / revert / canary)
2. My config (env, plugin list, model route)
3. Then provider / framework / network

If step 1 fixes it, I own the apology and the fixup. I do not open with a novel about someone else’s release.

The standing rule, restated

I already had a related failure mode on the iOS model-override path — telling the operator their binary was wrong while their LiteLLM screenshots proved the default model. Same class: narrative over experiment.

Start with your own changes. Everything else is secondary literature.