Claude Code vs MiniMax M3: 30 days against 3 months, in merged pull requests

On 20 September I moved my coding agents from MiniMax M3 to Claude Code. In the 30 days after, my GitHub account merged 1,845 pull requests. In the three months before, it merged 295.

That's about 19 times as many per day. It's also the kind of number that gets a post laughed off Hacker News, because it hides almost everything that matters. So this post gives you the number, and then takes it apart.

What is it about? Real counts from my own GitHub account, two periods, and the other things that changed at the same time, named. Who is it for? Developers deciding whether a $200 subscription is worth it over a $50 one, and anyone who runs AI agents and wants to measure what they actually get. At the end there's a way to count your own.

• The M3 months, 20 June to 19 September 2026 (92 days). MiniMax M3 on its $50-a-month plan was my subscription, used through OpenCode and DSH. It wasn't the only model I ran; more on that below.
• The Claude Code month, 20 September to 19 October 2026 (30 days). Claude Code on Claude Max, $200 a month, with agents on Opus and Sonnet models. My previous post covers which model does what, and why.

The counts come from GitHub's search and API: pull requests authored by my account and merged on a given day, commits on default branches, tags, releases and issues. Private repositories are included. Days are counted in my time zone. Which model ran when comes from my local agent logs.

"Changed lines" is additions plus deletions, as GitHub counts them.

The jump is real. It's also not one thing.

In the M3 months my account committed something on 46 days out of 92, in about 3.6 hours of each of those days. In the Claude Code month it committed every single day, in 11.5 different hours of the day on average.

Those aren't my working hours: most commits come from agents, not from me at the keyboard. But the split is the honest one: about 6 times more hours of work, and about 3 times more merged pull requests in each of those hours. If you expected a new model to make the same amount of work 19 times faster, that's not what happened.

This change isn't in any chart.

With M3, I reviewed every pull request myself before it merged, because I couldn't trust it. That made me the bottleneck: agents can open pull requests much faster than one person can read them.

With Claude Code and the rules in my dotfiles repository, about 99% of what the agents wrote matched what I would have written. So I stopped. A separate reviewer agent now checks every pull request: it runs the tests, breaks the code on purpose to see whether a test goes red, and checks every claim in the description. Nothing merges until it passes. That removed the bottleneck, and it only works because the output became predictable enough to trust a second agent with the check.

I didn't just swap the model. In the same weeks I started working in waves: one lead agent splits a list of GitHub issues into lanes that touch different files, and a separate agent builds each lane in its own git worktree. Every unit of work became its own pull request, squash-merged, so one pull request now means one commit on main.

So the gain belongs to several things at once: the model, the harness, the workflow and my own review leaving the loop. I can't separate them from this data, and I won't pretend I can.

M3 was my subscription, but I tried other models along the way, and my logs say so. They only start in mid-July (OpenCode) and early September (DSH), and in them:

• In September, GPT-5.6 and GPT-6 models gave 717 replies in OpenCode, against 431 from M3. That was a $20 ChatGPT subscription I was experimenting with.
• In August, DeepSeek V4 Flash gave 249 replies in one OpenCode session.
• On 18 and 19 September, about 300 DSH sessions ran on DeepSeek V4 Flash, and 45 more on 20 September, the first day of the Claude Code month.

DeepSeek was my main provider before MiniMax. I moved to M3 when DeepSeek raised its prices, and kept using DeepSeek's paid API now and then.

So "M3 against Claude Code" is really "my setup before against my setup after", with M3 as the main subscription before.

The first month on a new tool can be a burst: ideas that waited for the capacity, and the fun of a new toy. Week by week, the Claude Code month merged 501, 529, 259 and 438 pull requests, so there's no clear fall-off yet, just one quiet week in the middle. Ask me again in three months.

1.24 million changed lines sounds impressive and means little. Lines include lock files and generated data: three data imports into one of my private repositories added up to about 98,000 lines on their own.

What I checked instead is whether pull requests just got smaller, which would inflate the count for free. They didn't: the median went from 266 changed lines to 228. The slicing got a bit finer, not ten times finer.

Issues closed rose the most, 26.7 times. Part of that is agents filing issues for what they notice, then other agents closing them, so read it with care.

One more caveat, against myself. The last day of the M3 period, 19 September, had 63 merged pull requests, more than any other day before the switch. My agent logs show that on that day I ran most agents on DeepSeek V4 Flash, not M3. Leave that day out and the M3 months average 2.5 pull requests a day, which makes the Claude Code month about 24 times as busy, not 19. I kept it in to be conservative.

Pull requests are a means. These are the tags pushed in the Claude Code month, all of them public:

• ts-libs, my shared TypeScript libraries on JSR, went from v1.0.0 to v1.81.0.
• preact-components, my component library, went from v0.1.0 to v8.6.1. I wrote about why I built it instead of using shadcn.
• caldav-mcp went from v1.0.0 to v1.6.0.
• mig, rostok and caldav-tasks-web got 23, 25 and 17 release tags, and Seed got one, v1-final, which marks its old code rather than a release.

That's 228 tags, 227 of them versions, against 3 tags in the three months before. A release tag is a version someone else can install, which makes it a better count of shipped work than pull requests.

Subscription money only:

The pricier plan came out at about a fifth of the cost per merged pull request. That doesn't count the $20 ChatGPT experiment or the occasional DeepSeek API calls, or my own time, which is the expensive part.

Cost per pull request only means something if the pull requests are good. My quality guard is the reviewer agent's first-pass rate, and in the Opus 5.5 vs Sonnet post I showed how much it varies by model: a cheaper implementer that fails its first review more often gives part of the saving back in fix rounds.

It felt that way to me. When I started, M3 felt overpowered. Then MiniMax ran into a backlash from users over a pricing change, and a week or two after that I started to feel that M3 got dumber. It made mistakes more often, I had to hold its hand a lot, and I had to review every pull request because I couldn't trust it.

My guess is that they found another way to make it cheaper to run, for example a more heavily quantized model. That's only a guess: I have no proof, and I know of nothing from MiniMax that says so.

My data can't settle it either. My local logs from the M3 months are thin: about 660 model replies in OpenCode over 16 days and a dozen sessions in DSH, with no record of where one task ends and the next begins. In August they show 30 API errors, mostly "high load" and "usage limit reached" responses. That's not enough to measure mistakes per task, let alone a trend.

For comparison, I trust Opus now the way I never trusted M3. I can't say the same about Sonnet yet: in my last cost comparison it passed its first review far less often.

The pull request counts come from GitHub search, one day per query, because a search returns at most 1,000 results:

gh api graphql -f query='
query($q: String!, $after: String) {
  search(query: $q, type: ISSUE, first: 100, after: $after) {
    issueCount
    pageInfo { hasNextPage endCursor }
    nodes { ... on PullRequest { additions deletions repository { nameWithOwner } } }
  }
}' -f q='is:pr author:YOUR_LOGIN is:merged merged:2026-10-01'

1. is:pr author:YOUR_LOGIN is:merged counts pull requests you authored and merged, in every repository your token can see.
2. merged:2026-10-01 is one UTC day; loop over the days of each period and when hasNextPage is true, run it again with -f after=<endCursor>.
3. additions and deletions give changed lines. Take the median, not the mean: one generated file can swamp a month.
4. For hours worked, use the REST commit search, gh api -X GET search/commits -f q='author:YOUR_LOGIN committer-date:2026-10-01', and count the distinct hours that have a commit. It only sees default branches, allows 30 requests a minute, and finds a commit twice when two repositories share history, so count each commit hash once.

Compare per day, not per period, and write down everything else you changed in the same weeks. That list is the honest part of the result.

The obvious question is how: which rules made the agents' output predictable enough that I stopped reading it. The whole setup is public in spy4x/dotfiles, and my next post walks through it, with the incident behind each rule.

If you've measured your own switch between models, I'd like to see your numbers, especially if they disagree with mine. My email is in the footer.