[1]: https://github.com/manuelschipper/nah

Fable is on a class of its own when it comes to coding and orchestration, but it runs out pretty quick and is prohibitively expensive and slow. For me, Astra wasn't as good of an upgrade from Sol when it comes to coding and orchestration, and it runs out pretty quick too. Opus 5 had so much potential but was such a pain to talk to, so I only had other agents delegate to it.

Given this, I kept coming back to Sol 5.6 as my daily driver (with consultations from Fable and Astra when available). Sol has an autistic character that smells like RL deepfry, which can be annoying, but it is nonetheless predictable, communicates more plainly than Claude, and is good at code and orchestration.

But this Opus 5.5 might just be it. Fable-level performance that's cheaper and faster, and communicates plainly and briefly. If it pans out in practice, I might just have a new daily driver and it might be time to raise the bar for what can be achieved.

I'll try out the new Sol 6, though Opus 5.5 seems to beat that release fair and square (at least on paper)

I'm also glad we are paying attention now to the experience of using a model, not just how good it is at 'x' class of tasks.

It’s easily extensible, has a nice simple TUI, and is resilient to an adversarial agent that tries to remove the guard.

https://github.com/manuelschipper/nah

I do appreciate the input, thanks!

mdmanager packages runtime-specific discovery, reusable Sections and Profiles, an instruction-focused TUI, and bundled CLI docs into something you can install and use.

You could build that with Ansible too, but the interface, domain rules, documentation, and maintenance are part of what you’d be building. Packaging all the nuances of 4 runtimes in was a lot of work.

If your existing setup already gives you everything you need, great. You don’t need this. That doesn’t make a dedicated tool redundant for everyone else.

“Ansible can do that” is a reasonable implementation suggestion. Taken it too far then “Python can do that” becomes an objection to everything posted on HN.

And no LLM is required for discovery, rendering, or deployment. Using an agent to edit the configuration is a workflow choice.

The TUI and the docs understand how each coding agent runtime loads instructions into context (they all have nuanced differences) including local overrides, or what gets prioritised in case there is conflict (for instance, Pi accepts both CLAUDE.md and AGENTS.md).

Your agent can load the docs to understand nuances and help you manage how you want instructions to get loaded. You can use the TUI to render the concatenated instructions as they are loaded into your agent.

So yes, templating could be replaced with smth like Ansible, but the tool solves a bit more than just that.

Thanks for the question!

I have multiple machines (personal laptop, work laptop, server) and runtimes (Claude Code, Codex, Pi) which share common instructions, but also have special cases for each runtime or machine.

For instance, I have a section that’s common across all my agents that goes something like this: “Do not co-sign commits with an AI identity; do not add backwards compatibility if you were not asked to” .

For Pi I have a special case: “Use background task tool proactively for in-scope commands expected to run for long”.

In my server I have a section on how to use the credential proxy (which I don’t have in my other profiles).

So I made this little tool ‘mdmanager’ that helps me manage and deploy the .md files with reusable Markdown sections (like “agent-common”, “pi-common”) and profiles (“vps”, “laptop”)

How it works: you tell your coding agent to run “mdmanager docs start” and it guides you through the setup. You can then open the TUI to see the diff and inspect what gets loaded into the context. The TUI is read-only. To modify and apply, you talk to your agent (it has access to the docs via the CLI)

One feature that I use often is the “Context” section in the TUI.

Open the TUI from inside the repo, and you can see what instructions get loaded into context in one Markdown page, including global and project level *.md files that are in scope.

Right now it supports Claude Code, Codex, Pi, and Cursor. Feedback and contributions are most welcome.

Comments URL: https://news.ycombinator.com/item?id=49587839

Points: 3

# Comments: 7

I did refer to some specific models, though a lot of these learnings are from experience over the past 6 months or so, and continue to generalize as frontier models improve.

Curious if there’s a specific point you feel is too detailed?

Comments URL: https://news.ycombinator.com/item?id=49368389

Points: 10

# Comments: 15

All the agent hook guards I’ve seen can be easily removed by agents (and they often do so they can get going with the task). I made mine harder to remove, and I’m working on making it impossible.

I also made “nah” easily extensible. Just point your agent to the docs which ship with the CLI, and ask it to build a custom guard.

I’m working on strong Python and Typescript pseudo-interpreters so I can detect disasters in inline code with less false positives. Bash parser is already very strong.

This is a side-project that I want to be proud off. I spend a lot of time designing, not just coding.

[1] nahguard.ai

Comments URL: https://news.ycombinator.com/item?id=49112469

Points: 2

# Comments: 0