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.
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.
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.
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`
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.
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.
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.
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.