[jrvarela56]

The past month made me realize I needed to make my codebase usable by other agents. I was mainly using Claude Code. I audited the codebase and identified the points where I was coupling to it and made a refactor so that I can use either codex, gemini or claude.

Here are a few changes:

1. AGENTS.md by default across the codebase, a script makes sure CLAUDE.md symlink present wherever there's an AGENTS.md file

2. Skills are now in a 'neutral' dir and per agent scripts make sure they are linked wherever the coding agent needs them to be (eg .claude/skills)

3. Hooks are now file listeners or git hooks, this one is trickier as some of these hooks are compensating/catering to the agent's capabilities

4. Subagents and commands also have their neutral folders and scripts to transform and linters to check they work

5. `agent` now randomly selects claude|codex|gemini instead of typing `claude` to start a coding session

I guess in general auditing where the codebase is coupled and keeping it neutral makes it easier to stop depending solely on specific providers. Makes me realize they don't really have a moat, all this took less than an hour probably.

[esperent]

I've been doing the same except that I'm done with Claude. Cancelled my subscription. I can't use a tool where the limits vary so wildly week to week, or maybe even day to day.

So I'm migrating to pi. I realized that the hardest thing to migrate is hooks - I've built up an expensive collection of Claude hooks over the last few months and unlike skills, hooks are in Claude specific format. But I'd heard people say "just tell the agent to build an extension for pi" so I did. I pointed it at the Claude hooks folder and basically said make them work in pi, and it, very quickly.

[jrvarela56]

I'm leaning in this direction. Recently slopforked pi to python and created a version that's basically a loop, an LLM call to openrouter and a hook system using pluggy. I have been able to one-shot pretty much any feature a coding agent has. Still toy project but this thread seems to be leading me towards mantaining my own harness. I have a feeling it will be just documenting features in other systems and maintaining evals/tests.

[fouc]

Pi appears to be a reference to what is essentially an alternative to agent harnesses / CLI tools like Claude Code or Open Code [0]. I am curious what providers/models are you using in place of Claude's model?

[0] https://github.com/badlogic/pi-mono

[esperent]

https://pi.dev/

It's got an annoyingly hard to search name because there's a lot of overlap in results with the Raspberry Pi single board computer.

Over the past week or so my workload has been quite low so I've been tinkering rather than doing serious deep work.

I've been using:

* Gemini pro and flash

* Opus 4.6 when I had some free extra usage credits (it burned through $50 of credits like crazy).

* Qwen 3.6 Plus

* Codex 5.3

* Kimi 2.5

I just spent the last hour using Kimi. I was very impressed actually, definitely possible to do useful work with it. However, I used $1 of openrouter credits in about 20 or 30 minutes of a single session, no subagents, so it's not cheap.

[grantcarthew]

I built "start" so I didn't have to worry about any of this.

Using it I don't need skills, memory, subagents, a specific agent CLI. It defines roles, tasks, context out of the box.

I made it for me and my family though. I don't expect interest outside of that.

https://github.com/grantcarthew/start

[JulienZammit]

The "agent-neutral codebase" framing is the right abstraction. We ended up building a small generator that takes a single spec file and emits the agent-specific config (CLAUDE.md, AGENTS.md, .cursor/rules) rather than maintaining symlinks. Easier to version and to add a new agent when they inevitably ship next month.

The pain point you're underselling is hooks. They're the least portable piece by far because each harness has its own event model. Skills port reasonably, subagents mostly port, hooks almost never do.

[Lucasoato]

Have you got any advice in making agents from different providers work together?

In Claude, I’ve seen cases in which spawning subagents from Gemini and Codex would raise strange permission errors (even if they don’t happen with other cli commands!), making claude silently continue impersonating the other agent. Only by thoroughly checking I was able to understand that actually the agent I wanted failed.

[jrvarela56]

Not sure if you mean 1) sub-agent definitions (similar to skills in Claude Code) or 2) CLI scripts that use other coding agents (eg claude calling gemini via cli).

For (1) I'm trying to come up with a simple enough definition that can be 'llm compiled' into each format. Permissions format requires something like this two and putting these together some more debugging.

(2) the only one I've played with is `claude -p` and it seems to work for fairly complex stuff, but I run it with `--dangerously-skip-permissions`

[bootlooped]

I would eliminate the possibility of sandbox conflicts by 1) making sure any subagents are invoked with no sandbox (they should still be covered under the calling agent's sandbox) 2) make sure the calling agent's sandbox allows the subagents access to the directories they need (ex: ~/.gemini, ~/.codex).

[lbreakjai]

It works out of the box with something like opencode. I've had no issue creating rather complex interactions between agents plugged into different models.

[dockerd]

How do you share the context/progress of goal across agents?

[jrvarela56]

I implemented a client for each so that the session history is easy to extract regarding the agent (somewhat related to progress of goal).

Context: AGENTS.md is standard across all; and subdirectories have their AGENTS.md so in a way this is a tree of instructions. Skills are also standard so it's a bunch of indexable .md files that all agents can use.