I gave Kimi K3 the same task. It found GLM's answer key

Kimi K3 completed the task for less than GLM 5.2. Then I opened the session and saw what it had done.

First I gave GLM 5.2 a task in OpenCode: create a LinkedIn carousel showing how easy it is to launch the model through pks-cli. When it was done, I asked it to write the documentation for agentics.dk/tools too.

A few days later, I gave Kimi K3 the same two prompts. The initial result looked compelling: Kimi completed the work for an estimated API cost of $2.44, while the GLM run cost roughly $6.91.

My first assumption was that Kimi was simply the cheaper model. That was wrong. Moonshot charged $3/M for regular Kimi input versus $1.80/M for GLM, while Kimi output cost $15/M versus GLM's $5.50/M. A model with higher list prices still delivered the cheaper run because the agent reused existing work and hit Moonshot's input cache.

Then I inspected the OpenCode session.

Kimi had found GLM's finished carousel in the repository.

They received the same task

GLM received this raw prompt, reproduced exactly as written:

Kimi received the same task with the model, provider, and implementation reference replaced. The prompt remains verbatim here, including its mix of Danish and English:

Both then received the same follow-up:

This was never designed as a scientific benchmark. Still, I expected Kimi to solve the task reasonably independently from the code and the repository's broader design system.

That is not quite what happened.

It found the perfect template

Kimi started sensibly. It read the repository, inspected the commit, and explored the existing marketing assets.

Then it wrote this in its reasoning:

There's a previous carousel marketing/linkedin/opencode-glm-5-2-scaleway which is the previous version of this exact same story. Let me look at how that's structured — it's the perfect template for this new carousel.

It proceeded to read:

• GLM's carousel.html
• its build.mjs
• the LinkedIn post copy
• the preview page

Then it produced a Kimi version with the same directory structure, build flow, seven-slide structure, and visual system.

GLM 5.2Slide 1 of 7

Kimi K3Slide 1 of 7

A basic line diff makes the reuse visible:

Across those four files, roughly 85 percent of the lines were byte-for-byte unchanged. That number needs context: much of it is CSS, rendering code, and other boilerplate that should be reused. But Kimi did not create an independent visual solution. It produced a competent adaptation of GLM's work.

The more expensive model delivered the cheaper run

OpenCode did not know Kimi K3's pricing and displayed $0. It had recorded all token counts, though, so I could calculate usage from Moonshot's prices for cached input, uncached input, and output.

That created an odd difference during the experiment: with GLM, I could watch the dollar counter increase inside OpenCode. Kimi looked free, even though Moonshot was of course still charging my account. I had to export the session and calculate the bill from the recorded tokens.

The GLM figure includes the child agent that retrieved context from the original Codex session. Kimi made more model calls — 70 versus 55 — but sent only 113,347 regular input tokens. Another 4,954,624 input tokens hit Moonshot's cache and were billed at one tenth of the regular input price.

Kimi was therefore 67 percent more expensive for regular input and almost three times as expensive for output. The cheap part was cache-hit input at $0.30/M. This particular run was cheaper because almost 98 percent of its input hit that cache, and because the agent could reuse the work GLM had already left in the repository.

A model with higher list prices can still be cheapest for the task when the agent's working method reduces the amount of expensive work.

Those are still useful operating numbers. Given a repository containing a closely related example, this concrete Kimi task cost approximately $2.44.

They do not show that Kimi is 65 percent better or cheaper at creating the work from scratch. It had access to a solution GLM never had.

I did not benchmark two isolated models. I observed two agents at different points in the life of a repository — a repository that had gained memory between the first and second run.

It is a benchmark flaw and a production strength

If the objective had been a clean benchmark, the experiment was contaminated. I should have used clean worktrees, hidden the first model's output, and given both models a new but equivalent task.

That is not how I normally want a coding agent to work.

In a real repository, I expect an agent to:

1. look for existing solutions,
2. reuse design and conventions,
3. avoid inventing another build flow,
4. adapt prior work to the new task,
5. verify the result.

Kimi only “cheated” if the assignment was to prove its own creativity under laboratory conditions. The actual assignment was to deliver a carousel and documentation that fit an existing product. For that purpose, it behaved correctly.

The interesting result is not which model won. It is how much more effective agents become when the repository already contains good examples, documentation, and previous artifacts.

pks-cli is the entry point, not the judge

I am not building pks-cli to crown one model as the winner. I am building it to make the agent and model that fit the task easy to launch.

The GLM run started like this:

pks opencode --model glm-5.2

The Kimi run started like this:

pks moonshot init
pks opencode --model kimi-k3

pks-cli resolves the provider from the model, reuses registered credentials, and launches the right tool without putting secrets in the argument list or writing them into OpenCode's configuration.

That does not make the experiment scientific. It makes the experiment easy to run — and makes it practical to keep using the model that solves the actual work best in the context it receives.

We welcome requests for the next agents, models, and providers to include in pks-cli.

Request an agent, model, or provider →

You can also inspect the current setup in the pks opencode documentation.