GPT-6.1 Terra vs Kimi K3.1 Pro: Same Rails Ticket, Real Cost

Two new models, one ticket

Two new models this week. OpenAI's GPT six point one Terra, at half the price of its big sibling. And Kimi K three point one Pro from Moonshot, with open weights on the way. In episode nine I swapped the agent and the model at once. This time only the model changes. Same agent, same ticket, same tests. Which one ships a real Rails feature for the least money?

The contenders

Terra is OpenAI's fast, cheaper tier, with a context window of over a million tokens. OpenAI says it finishes tasks three times faster than its bigger models. Kimi K three point one Pro comes from Moonshot AI. It's a mixture of experts with two point eight trillion parameters, one hundred and four billion of them active per token. Moonshot promises the open weights by November fourth. Until then, Moonshot is the only host.

Price per token

Now the price list on OpenRouter. Terra costs one dollar per million tokens in, and five out. Kimi costs twice that. And reading from the cache costs four times as much. So per token, the open model is the expensive one.

Vendor numbers

Benchmarks so far come from the vendors themselves. On Terminal-Bench four, OpenAI reports fifty point three percent for Terra, at maximum reasoning effort. Moonshot reports sixty-five point seven for Kimi. Moonshot also says Kimi's hallucination rate on a hard internal test dropped from twenty-three percent to eight. That's Moonshot's own test, though. Vendor numbers are a promise. Today we measure.

Price per task

One more thing before the test. Price per token is not cost per task. In episode nine, Beam used two point three million tokens, and ninety-four percent of them came from the cache. On paper, that same mix would cost thirty-nine cents on Terra, and about a dollar on Kimi. But no two models use the same tokens. So I don't compare price lists. I count what a finished ticket costs, and in each run, the counter at the bottom shows it live.

The ticket

Here's the ticket, in our demo shop. This is the payout queue: sellers ask for their money, compliance checks each request, and the page updates live. Now sellers want a CSV export of their own payout requests for a date range. A form object checks the range, a Solid Queue job builds the file, and a Turbo Stream tells the seller when it's ready. That's episodes two, three and four in one ticket. And the brief adds one rule: the notice goes to the seller who asked, and to nobody else. And these are the tests both models get. Sixty-one runs: the fifty old ones pass, the eleven new ones fail, because nothing is built yet. Red, as promised.

The rules

The rules. Both models run in OpenCode two point one point four, through OpenRouter, with the provider pinned, so neither gets routed to a cheaper or faster tier. Reasoning effort is high for both. Each run gets a fresh container, the same instructions and the same prompt, word for word. After the prompt, I keep my hands off. Every message I have to send counts against the model. Two runs per model. A run ends when the suite is green, or after twenty minutes.

Round 1: GPT-6.1 Terra

Round one: GPT six point one Terra. Fresh container, same prompt, hands off. Terra reads the brief, the red tests and the payout code, then writes the whole feature in one big patch. Less than a minute in, the eleven brief tests are green. Then it does something I didn't ask for: it adds its own tests for seller isolation, download paths and date boundaries. It runs RuboCop, commits, and reports done after one minute fifty-three. We run the suite ourselves: sixty-nine tests, green. Terra's scorecard: one minute fifty-three, nine cents, no help from me, and sixty-nine tests green. The second run came in at two twenty-three and eleven cents.

Round 2: Kimi K3.1 Pro

Round two: Kimi K three point one Pro, same setup. Kimi reads the same files, and then it thinks. Forty-four seconds, then another forty-five. For almost two minutes, not a single line of code. Then all seven new files land in one go. The brief tests pass, then the full suite. No extra tests, and no commit, which the prompt didn't ask for. Done after two minutes thirty-eight. Our own run: sixty-one tests, green. Kimi's scorecard: two minutes thirty-eight, twelve cents, no help from me either, and sixty-one tests green. The second run: two fifty-two and thirteen cents.

Side by side

Side by side. Terra was faster in both runs, and cheaper in both runs. Neither model needed a single message from me, and every run ended green. Now remember the paper math: thirty-nine cents against a dollar. Measured, Kimi costs about a quarter more per ticket, not two and a half times as much. It pays twice the price per token, but it uses less than half the tokens.

The rule nobody broke

And the one rule the tests don't check: the notice goes to the seller who asked, and to nobody else. The shop itself sends its payout updates on one shared stream, an easy pattern to copy. Neither model copied it. All four runs used a stream per seller, and my hidden check found no leak.

Verdict

So which one ships my Rails feature cheapest? For this ticket, Terra. Faster in both runs, cheaper in both runs, and it wrote extra tests on its own. Kimi came closer than its price list suggests. Both send my code to their vendor, and Kimi's open weights could change that once they're out. Between these two, I'd pick Terra. My everyday setup stays the same, though: Claude Opus five point five, on my subscription.

Next ticket?

Cost per finished task is the number I'll keep tracking, not leaderboard scores. Which ticket should both models get next? A database migration, or a nasty N plus one? Tell me in the comments. The repo, the brief and the tests are linked below.