MiniMax M3 vs Kimi K2.7 Code: Most affordable open-source coding model

MiniMax M3 and Kimi K2.7 occupy the same useful category: cheap open-weight models, meaning their weights are available outside a closed API.

Both claim strong multi-step tool use, where the model plans, calls tools, reads results, and keeps going, at a fraction of the highest-end closed-model pricing.

I want that category to work because coding agents get expensive fast once they start looping through terminals, logs, search, and tool calls.

I had one question: which one would I actually trust to drive an agent when the task stops being a neat prompt and turns into a messy repo or a chain of SaaS actions?

And honestly, you won’t get the answer from marketing pages. First, the pages show you benchmarks that nobody cares about, and even if they score 80%, it would be on easy examples they have already seen.

So, I took a different approach. I handpicked terminal bench questions that are provably hard even for SOTA models, along with a custom benchmark for real-world workflows. More on these later.

I tracked completion, cost, token use, and LLM as judge-verified results.

MiniMax M3 vs Kimi K2.7 at a glance

• On 10 hard sandboxed Terminal-Bench coding tasks, scored pass/fail by automated tests, M3 solved 5/10, and Kimi K2.7 solved 5/10. Kimi spent about 2.4 times as much doing it.

• They solved the same four coding tasks. The extra M3 solve was path-tracing-reverse, a path-tracer reverse-engineering task, where M3 finished after 134 model-to-terminal round trips, and Kimi timed out even with the doubled time budget.

• On the 25-task Composio tool-use suite across Gmail, Slack, Drive, GitHub, Calendar, Reddit, Notion, and web search, scored from 0 to 1, M3 averaged 0.75, and Kimi averaged 0.72. The scores were close.

• The cost gap widened on tool use: M3 cost $0.81 across the 25 Composio tasks, while Kimi cost $4.08, about 5x more.

• In my runs, M3 had the clearer edge on hard terminal coding. Every day, SaaS tool orchestration was effective.

For my use, M3 comes out ahead in both sets, with different margins. It wins clearly on agentic terminal coding and costs about a third per solved task. Real tool use was close enough to be treated as a near tie.

Intro to MiniMax M3

MiniMax M3 is MiniMax’s open-weight model aimed pretty directly at coding-agent work. It pairs a 1,048,576-token context window with low pricing and native tool calling. Here, tool-calling refers to structured requests to run shell commands, inspect files, edit code, or call external services.

The main spec is the context window: 1,048,576 (1M) tokens. That gives an agent room to keep much more repo state, logs, and previous attempts in view before it has to start trimming context.

On price, M3 is cheap: $0.30 per million input tokens and $1.20 per million output tokens on OpenRouter. I watch the output side closely with coding agents, since patches, retries, tool calls, and long explanations can quietly run up the bill. M3 keeps that meter low.

Intro to Kimi K2.7

Kimi K2.7 is Moonshot AI’s open-weight model in this matchup. It has a 262,144-token context window and native tool-calling, and Moonshot positions it as a step up from K2.7. That made it worth testing for agent work. Tool-calling matters when the model has to request external actions, wait for results, and continue from there.

In normal terms, 262K is big, though it is smaller than MiniMax M3’s 1,048,576 tokens. I still take 262K seriously, since an agent can carry a lot of repo state, as well as logs and tool outputs. It just has less room to be sloppy about history than M3.

Price: $0.68 per million input tokens and $3.41 per million output tokens on OpenRouter. M3 is $0.30 in and $1.20 out, so K2.7 output is about 2.8x more expensive. In agent loops, output tokens pile up fast because the model keeps explaining each move, calling tools, reading results, and trying again.

How I tested this

I ran two head-to-head tests. In each one, I kept the harness fixed and changed only the model ID, minimax/minimax-m3 versus moonshotai/kimi-k2.7.

• Agentic terminal coding: Terminal-Bench, run through terminus on Daytona cloud Linux sandboxes via OpenRouter.

• Real tool use: a 25-task Composio suite, using Composio tool-router meta tools via OpenRouter.

• GPT-5.5 High as the judge

OpenRouter was the routing and billing layer for both runs.

Terminal-Bench is a benchmark of hard command-line tasks. For example, tasks may require writing a compressor or reversing a path tracer. Each task runs inside its own isolated Linux sandbox, and the final answer is judged by an automated test for that task. In this section, “solved” means the task’s automated test passed.

The sample was the 10 hardest Terminal-Bench 2.0 tasks, so the score reflects that hard slice. It should not be read as a full-suite leaderboard score across every task.

Sandbox access goes through an agent called terminus. The model reads the terminal state, chooses the next command, sees the output, and then decides what to do next. I count each of those model-to-terminal round-trip as a step. So when a task takes 100+ steps, that means the model stayed coherent across a long chain of shell commands, edits, test runs, and fixes.

Each Terminal-Bench task has a built-in time limit. I doubled that limit for both models with agent-timeout-multiplier 2, because an initial run at the standard limit was cutting them off while they were still making progress. At the default limit, cutoffs often happened before the agent had finished exploring a plausible path, so I used the doubled limit for the head-to-head run.

The second test was a 25-task Composio suite against real connected accounts across Gmail, Google Calendar, GitHub, Slack, Google Drive, Reddit, Notion, and web search. Composio connects agents to authenticated app actions; the tool-router meta tools let the model find and run an app action when needed.

The Composio tasks were graded from 0 to 1. A score of 1 means the model actually did the job inside the connected account. A score of 0 means it failed the task. Partial scores mean it got some of the required work right but missed or mangled part of it, or failed to verify the result. An independent GPT-5.5 judge model graded the finished task and checked public claims against the live web.

Related: Opus 4.8 vs GPT 5.5

Test 1: Agentic terminal coding

The run used the 10-task hard slice from Terminal-Bench 2.0, through the same terminus agent on Daytona via OpenRouter. Each task is passed/failed by an automated test, and both models got a doubled time budget.

M3 and Kimi tied this run 5/10 to 5/10. Their three shared solves were a FEAL cypher-attack task, an LLM inference-batching scheduler, and password recovery.

The split came from the edge cases. M3 solved the fix-code-vulnerability and path-tracing-reverse tasks. Both models had double the normal time budget. M3 kept the agent working for 134 steps, meaning 134 model-to-terminal round trips, and eventually landed the path-tracing solve. Kimi spent $1.75 on the same task and still timed out.

Kimi made up the gap by solving regex-chess and torch-tensor-parallelism, both of which M3 missed. That makes the pass count even, but the cost line still favours M3.

M3 finished the whole run at $2.80. Kimi spent $5.86 for the same number of solved tasks, about 2.1x the total spend.

The result stays narrow. The MIPS interpreter build (make-mips-interpreter), the PyTorch pipeline-parallelism task (torch-pipeline-parallelism), and write-compressor beat both models even with the doubled budget. My read is narrow: M3 was cheaper and stronger on the long path-tracing task, while Kimi recovered with wins on regex-chess and tensor parallelism.

Test 2: Real-world tool use

This run covered 25 real jobs against connected accounts:

• summarising a month of emails by sender,

• counting a week of Slack by channel,

• organising 1,000 Drive files,

• looking up a GitHub repo’s stats,

• scraping startups and drafting outreach emails. Each task got a 0-to-1 score from an independent grader.

• …etc

Kimi won this tool-use run on quality, averaging 0.783 against M3’s 0.75.

Kimi’s biggest wins came on research-heavy and mixed-tool tasks, including microservices research, weather summary, productivity reporting, and Rust/Go/Zig comparison.

M3 still won several practical SaaS tasks, including inbox summaries, Notion page listing, Drive organisation, Slack summaries, YC outreach, and GitHub trend lookup.

The cost gap still favours M3. M3 spent $0.81, while Kimi spent $2.02, about 2.5x more.

My read: Kimi K2.7 is slightly better on quality, especially for research and synthesis, while M3 remains the better value pick.

Cost Analysis

I used the actual per-run price billed through OpenRouter and summed it per task.

Terminal-Bench costs $2.80 for M3 and $6.61 for Kimi, about 2.4x more. M3 also solved one more task. The per-solved-task math is worse for Kimi: $0.56 per solve for M3 against $1.65 for Kimi.

The tool run had a bigger spread. Across the 25 Composio tasks, M3 spent $0.81, and Kimi spent $4.08, roughly 5x. The quality scores were close, 0.75 for M3 vs 0.72 for Kimi, while Kimi cost about five times as much to get there.

OpenRouter rates explain part of that. M3 was listed at $0.30 per million input tokens and $1.20 per million output tokens. Kimi was $0.68 input and $3.41 output, so input was a little over 2x, and output was about 2.8x. Kimi also tends to emit more tokens per task, so the gap compounds inside agent loops.

Caveat: these were small task counts, and OpenRouter’s billed prices can differ slightly from a vendor’s own API. The direction remained consistent for this workload: M3 was significantly cheaper.

Final Verdict

My pick is M3 for both workloads, but the margins are different. The terminal-coding run is a clearer win, and M3 costs about a third per solve. The real tool-use run is a near tie.

Terminal-Bench was the cleaner M3 win: 5/10 for M3 vs 4/10 for Kimi. M3 costs $2.80 total and $0.56 per solve, while Kimi costs $6.61 total and $1.65 per solve. The task I kept coming back to was path-tracing-reverse: M3 solved it in 134 agent steps, meaning model-to-terminal round trips, while Kimi timed out even with the doubled budget.

Composio was much closer. M3 averaged 0.75 across 25 real tool tasks; Kimi averaged 0.72. Both handled the same kind of Gmail, Calendar, GitHub, Slack, Drive, Reddit, Notion, and web search orchestration well enough that I would treat them as close on that workload. M3 did it for $0.81 instead of $4.08.

When you’ll notice the difference

Hard, long-horizon terminal work is where M3’s lead and cost edge matter. For SaaS orchestration, the models are close enough that M3’s lower bill is the practical separator.

Caveats: this was only 10 Terminal-Bench tasks plus 25 Composio tasks. The Terminal-Bench run used a doubled time budget, so treat it separately from standard leaderboard comparisons. Both models are still far below the best closed models on the hardest coding tasks, so I’d try them on your own workflow before swapping anything in.

If you want to build agents like this against real apps, Composio connects them to 1,000+ apps with auth handled.

Get started with Composio