systima

How does this differ to Spec Kit / BMAD / etc?

We are using Claude Max with OpenCode. See the post for details.

We've updated the post now!

UPDATE – 13/07/26:

1) We have added a repository reproducing the methods.

2) We have commented on output quality in the post (in addition to tokens/cost).

3) Per a previous update, we now handle Fable 5 in the post.

UPDATE:

After reading PUSH_AX's valid comment: ``` This is like saying contractor (A) asked for $33,000 to undertake the work and contractor (B) asked for $7,000 Are we measuring and caring about the right thing? ``` We will update the post to include:

1) A more in-depth task. 2) Qualitative results comparison. 3) As soon as possible, a reproduction of the inputs and outputs.

Anecdotally, the results from OpenCode + Claude appear to be the same if not better for our uses over the past year.

We have never read your blog or your content before.

Suspect that many have covered the "Comparing agentic coding tools" angle before, and that the differentiator is depth of analysis + conclusions.

We are yet to try Pi!

Model:

Cost, mainly. The runs went through a Claude Max subscription rather than metered API billing, and pinning an older stable snapshot kept run-to-run comparisons clean and cheap. The fixed harness payload (system prompt plus tool schemas), so the headline numbers shouldn't change too much.

That said, happy to re-run the matrix on Fable and publish the diff; payload figures should barely move, tool-calling behaviour might.

Gateway:

Meridian (github.com/rynfar/meridian); proxy that bridges the Claude Code SDK to a standard Anthropic endpoint so a Claude Max subscription can drive OpenCode-et-al.

It's the auth route for all agent traffic on the machine, not something built for the benchmark.

Is this allowed under Apple's ToS?

I recall the Beeper Mini debacle not so long ago, and fear that this may be a house built on sand.

How does this differ to Mastra?

As the entire planet now knows, the Claude Code source leaked on March 31.

The engineering-focused findings have been covered extensively (fake tool injection, Undercover Mode, KAIROS, etc).

This piece focuses on what these findings mean if you're using Claude Code to build AI systems subject to the EU AI Act.

TL;DR / spoiler:

Claude Code isn't a high-risk AI system in and of itself.

The EU AI Act regulates your deployed system and your process, not your tool vendor's internal engineering practices.

How does this differ to Open Code Desktop?

Sorry, I missed part of your question:

What caused the switch was that we're building AI solutions for sometimes price-conscious customers, so I was already familiar with the pattern of "Use a superior model for setting a standard, then fine-tuning a cheaper one to do that same work".

So I brought that into my own workflows (kind of) by using Opus 4.6 to do detailed planning and one 'exemplar' execution (with 'over documentation' of the choices), then after that, use Opus 4.6 only for planning, then "throw a load of MiniMax M2.5s at the problem".

They tend to do 90% of the job well, then I sometimes do a final pass with Opus 4.6 again to mop up any issues, this saves me a lot of tokens/money.

This pattern wasn't possible with Claude Code, thus my move to Open Code.

Yes I regularly plan in Opus 4.6 and execute in “lesser” models ie MiniMax

Open Code has been the backbone of our entire operation (we used Claude Code before it, and Cursor before that).

Hugely grateful for what they do.

I agree.

In my experience, this correlates more with soft skills and “one man band” founder/maker companies that tend to sell training products or (if they do exist in a company environment at all) invariably work in DevRel and aren’t pushing code.

Thank you — Excellent points. Will think about them.

I don’t think it’s that.

I think it’s more about setting a norm and precedent that “Age verification is not our responsibility; the App Store layer does that and it’s an established truth now”.

Which itself conveniently helps as a defence in lawsuits when a teenager kills themselves over harmful content etc.

"But there is an obvious solution: mandate the operating systems (iOS and Android) to share device users' ages when they download apps from the app stores – data the operating systems get as part of the hardware acquisition already. This would be a simple one-step way for parents to control all the different apps that their kids use (in the US, the average teen uses forty different apps per month) and would remedy the fractured app-by-app approach we have today. We should make a societal judgement about whether to set these age limits for smartphones or social media use at thirteen, fourteen, fifteen or sixteen, then write it into law." in How to Save the Internet by Nick Clegg

Follow what Nick Clegg has been saying post-Meta. He might give a big clue.

Maybe https://usepec.eu ?

Impressive! Well done

Respectfully, this is not really engaging withe content of the post.

IMO what you’re describing is essentially crypto-shredding.

It would definitely work (and when dealing with petabyte levels of data the simplicity of only having to delete the key is convenient).

We’re leaning toward the dual-layer separation I described though (metadata separate to content) mainly because crypto-shredding means every read (including regulatory reconstruction) depends on a key store.

In my view that’s a significant dependency for an audit log whose whole purpose is reliable reconstructability, whereas dual-layer lets the chain stand on its own.

Your point about developer mistakes is fair. It applies to dual layer as you say with your example, but I’d say crypto shredding isn’t immune to mistakes because (for example) deleting the key only works if the key and plaintext never leaked elsewhere accidentally in logs / backups etc.