DEV Community: xiun xiao

Open models vs Claude: Kimi K3, GLM 5.3 and DeepSeek V4 Pro against Sonnet 5.5 and Opus 5.5

xiun xiao — Fri, 06 Nov 2026 01:44:12 +0000

Originally published on the QuickSilver Pro blog.

The usual reason to choose an open model over Claude is price. Now that every Claude model on QuickSilver Pro costs 75% less than Anthropic's list price, that reason needs checking again, and so does the question of what you give up in quality. So we put three large open models from our catalog and two Claude models through the same set of tasks, on 2026-10-20.

Model	Price per 1M tokens (input / output)
Kimi K3	$2.55 / $12.75
GLM 5.3	$0.60 / $2.20
DeepSeek V4 Pro	$0.70 / $2.10
Claude Sonnet 5.5	$0.50 / $2.50
Claude Opus 5.5	$1.00 / $5.00

How we tested

17 tasks, each with an answer a script can check, in two groups:

13 standard tasks: six small Python functions (a duration parser, interval merging, an LRU cache, strict Roman numerals, an expression evaluator with C-style division, semantic-version ordering), three extractions to JSON (an invoice from an email, attendees from meeting notes, log-line counts) and four short maths and logic questions.
4 harder tasks: shell-style word splitting with quoting rules, the final state of an order after a chat full of changes and reversals, a counting-out puzzle where the count alternates between 3 and 4, and the number of integers up to 100,000 whose digits sum to 20.

Code passes only if it survives a fixed set of unit tests; JSON passes only if it equals the expected object; maths answers must match exactly. Every model got the same single user message per task through the OpenAI-compatible /v1/chat/completions endpoint, non-streaming, max_tokens 8,000, no system prompt, no temperature setting. Each task ran three times: 51 requests per model.

With these defaults the three open models think before answering and bill those reasoning tokens as output; the two Claude models answered directly, without extended thinking. Cost below is the billed input and output tokens multiplied by QuickSilver Pro prices on 2026-10-20.

Results

	Kimi K3	GLM 5.3	DeepSeek V4 Pro	Claude Sonnet 5.5	Claude Opus 5.5
Standard tasks passed	39 / 39	37 / 39	35 / 39	39 / 39	39 / 39
Harder tasks passed	10 / 12	8 / 12	7 / 12	12 / 12	12 / 12
All tasks	49 / 51	45 / 51	42 / 51	51 / 51	51 / 51
Median latency	26.6 s	3.7 s	110.5 s	3.7 s	5.2 s
90th percentile latency	140 s	10 s	370 s	7.0 s	9.4 s
Average output tokens	1,312	513	2,631	507	580
Cost per 1,000 tasks	$17.31	$1.22	$5.68	$1.71	$3.80

Costs are at QuickSilver Pro prices on 2026-10-20, computed from the measured tokens.

Where the open models were good enough

Routine extraction. All three open models got the invoice, the attendee list and the log counts right in all nine of their runs. If your workload is "turn this text into this JSON", any of them will do it.
Small, well-specified functions. Kimi K3 passed every coding task in every run. GLM 5.3 missed two of 21 coding runs: once it accepted an empty string as a Roman numeral, once it rejected a valid quoted string in the shell splitter.
GLM 5.3 on price and speed. It was the only open model that was both cheaper than Sonnet 5.5 (about 30% less per task) and as fast (the same 3.7-second median). On the 13 standard tasks alone it passed 37 of 39 for $0.85 per 1,000 tasks, against 39 of 39 for $1.59 on Sonnet.

Where they were not

Multi-step reasoning. The counting-out puzzle needs about forty careful steps. Sonnet 5.5 and Opus 5.5 solved it in all six runs. Kimi K3 solved it once in three, GLM 5.3 once (its other answers were 37 and 13), DeepSeek V4 Pro never.
Getting an answer out at all. DeepSeek V4 Pro returned an empty answer 8 times out of 51: it spent its tokens reasoning and stopped before writing anything, five times by reaching the 8,000-token limit. A ninth request had not finished after ten minutes. Kimi K3's two misses were the same pattern. A larger max_tokens might have let them finish, at a higher cost per task; we did not test that.
Following the output format. In one run GLM 5.3 wrote the correct JSON object and then appended its reasoning after it, which breaks any parser that expects JSON only.
Latency. Kimi K3's median was 26.6 seconds and DeepSeek V4 Pro's 110 seconds, with DeepSeek's median ranging from 24 seconds in one run to 233 seconds in another. Fine for a batch job, not for anything a user waits on.
Price. At 75% off list, Sonnet 5.5 cost less per task than both Kimi K3 (ten times less) and DeepSeek V4 Pro (a third), and it passed every task. Even Opus 5.5 was cheaper per task than both on this test.

So which should you use?

For extraction and simple functions where cost matters most, GLM 5.3 held up: cheaper than Sonnet and just as fast, with a few more misses. Validate its output, as you would with any model in a pipeline.
For anything with several reasoning steps, or where a wrong or empty answer is expensive, Claude Sonnet 5.5 was the better buy on this test: every task passed, a few seconds each, at a lower cost per task than two of the three open models.
Kimi K3 was accurate on the standard tasks but slow and, at its price, by far the most expensive model here per task.
DeepSeek V4 Pro had the lowest pass rate and the slowest answers on this harness; if you use it, allow a large max_tokens and retry empty responses.

Limits of this test

17 tasks and three runs per model is a small sample: one task moves a pass rate by two points, and the harder group has only four tasks. The tasks are short, single-turn and in English. We did not test long contexts, tool use, agentic coding, other languages, or the open models with reasoning turned down or Claude with extended thinking turned on, and any of those could change the picture. Latency was measured from one client on one day. Treat the table as a starting point and run your own prompts: the request code is the same for every model, so switching is a one-word change.

from openai import OpenAI

client = OpenAI(
    base_url="https://api.quicksilverpro.io/v1",
    api_key="YOUR_QSP_KEY",
)

for model in ["glm-5.3", "kimi-k3", "deepseek-v4-pro", "claude-sonnet-5-5"]:
    response = client.chat.completions.create(
        model=model,
        max_tokens=8000,
        messages=[{"role": "user", "content": "Your task here"}],
    )
    print(model, response.usage.completion_tokens, response.choices[0].message.content)

For the full Claude price list, see Claude API pricing in 2026. For requesting output that follows a JSON schema, see the JSON schema guide.

Run Claude Code and Codex on a cloud dev box

xiun xiao — Thu, 05 Nov 2026 01:36:46 +0000

Originally published on the QuickSilver Pro blog.

Coding agents are happiest on a machine they can treat as their own: a shell, a browser, Docker, room to install things, and nothing on it you would mind them breaking. That is usually a VPS you set up yourself. QuickSilver Machines is that machine ready-made: a private Linux desktop and terminal that opens in your browser, with Claude Code, Codex, OpenCode and Hermes already installed and signed in to your QuickSilver Pro account. Agents ready out of the box, one unified bill, zero friction: the machine and AI usage at normal model prices come from one QuickSilver balance, with no separate cloud, Anthropic or OpenAI bills, no API keys to paste and no config files to edit. Open the terminal and type claude.

We created one on 2026-11-04 and used it the way you would on a first day: open it, check what is installed, give Claude Code a small task, pause it, resume it, and delete it. This post is what we saw, with the times and the bill.

Short version:

From clicking Create to a running machine took about 30 seconds in our latest test. The desktop and terminal were usable as soon as the page loaded.
All four agents worked with no setup. No API key to paste, no config file. Claude Code finished a small task with tests in 11 seconds for about 2 cents of AI usage.
Pause and resume kept everything, including a shell variable and a background job that kept running after resume. Pausing took about 25 seconds and resuming about 11.
The machine itself cost $0.0027 for about 8 minutes of running time, at $0.02 per running hour.

What you get

Every machine is the same Standard size during the beta:

2 vCPU, 4 GB RAM and a 20 GB home disk.
A Linux desktop with Chromium, and a terminal, side by side in one browser tab.
Docker, Python with uv, and ports 3000 to 9000 free for your own servers, which you can open from the Ports tab.
Claude Code, Codex, OpenCode and Hermes, each already configured to use your QuickSilver Pro account.
A US IP: the machines run in Santa Clara, California, and all outbound traffic leaves from there.
$0.02 per running hour, billed per minute from your QuickSilver Pro balance. A paused machine costs nothing. There is a cap of 200 running hours a month.

Step 1: create the machine

Open Machines in the dashboard, click Create Machine, give it a name and confirm. The dialog shows your balance. A new account can start its free trial machine on the signup credit, with no card; after the trial, you need at least $1.00 available to start a machine.

In our latest test, on a brand-new trial account later the same day, the machine was Running 32 seconds after the click. Our very first machine earlier that day took about 14 minutes, during the initial rollout. Start times can be longer when many machines start at once. You can close the tab while it starts; the machine keeps going.

Step 2: open it

The machine page puts the terminal on the left and the desktop on the right. The desktop opens on a welcome page that lists the four agents, the command for each, and the model each one uses by default:

Agent	Command	Default model
Claude Code	`claude`	Claude Sonnet 5.5
Codex	`codex`	GPT 6.1 Terra
OpenCode	`opencode`	GPT 6.1 Terra
Hermes Agent	`hermes`	GPT 6.1 Terra

On the free trial, the agents use Claude Haiku 5.5 (Claude Code) and DeepSeek V4.1 Flash (the others) instead.

The first thing we ran in the terminal was a check of what was really there:

free -h | head -2; df -h ~ | tail -1; curl -s https://ipinfo.io/region
for a in claude codex opencode hermes; do printf '%s: ' $a; $a --version | head -1; done

It reported 3.8 GiB of memory, a 20 GB home disk, an outbound IP in California, and Claude Code 2.1.316, Codex CLI 0.166.0, OpenCode 1.19.5 and Hermes Agent 0.22.5.

Step 3: give an agent a task

The agents need no setup: each machine has its own machine key, and the agents are already pointed at it. We gave Claude Code a small task in non-interactive mode:

mkdir -p ~/demo && cd ~/demo
time claude -p --dangerously-skip-permissions "Create slugify.py with a slugify(text) function that lowercases, strips accents, and joins words with hyphens. Add test_slugify.py with pytest tests, install pytest with uv if needed, run the tests and report the result in one line."

It wrote both files, installed pytest into a new virtual environment with uv, and reported that all 8 tests passed. That took 11.4 seconds and cost $0.0205 of AI usage on Claude Sonnet 5.5. --dangerously-skip-permissions lets Claude Code run commands without asking; on a disposable machine like this one that is a reasonable trade, and it is the main reason to give an agent its own box.

AI usage and machine time come out of the same balance but are counted separately. Each machine key has a $5 AI budget by default. You can raise it under API Keys → Machine keys; topping up your balance does not raise it.

Step 4: pause and resume

To check what survives a pause, we set a shell variable and started a background loop that wrote the time to a file every 5 seconds:

export PAUSE_TEST=kept
(while true; do date -u +%T >> ~/tick.log; sleep 5; done) &

Then we clicked Pause. The machine showed Paused about 25 seconds later. We waited, clicked Resume, and it was Running again after about 11 seconds. Back in the same terminal, PAUSE_TEST was still set, the background job was still running, and tick.log had a one-minute gap around the pause before the timestamps picked up again.

Pause saves a checkpoint of the running machine for up to 24 hours. If a checkpoint fails, the next resume starts your applications fresh, but the files in your home directory stay. For a known-good state you can come back to, Save snapshot in the header keeps named snapshots of the disks; the newest three are kept.

What it cost

Item	Amount
Machine time, about 8 minutes running	$0.0027
Claude Code task (Claude Sonnet 5.5)	$0.0205
Other AI usage during the session, not started by us	$0.0020
Total	$0.025

At $0.02 per running hour, a machine you use for four hours on each of 20 working days costs $1.60 a month, and nothing while it is paused. The 200-hour monthly cap works out to $4.00. Your agents' AI usage is extra, at normal QuickSilver Pro model prices.

Using it from a phone or tablet

Everything runs in the browser, so you can reach the same machine from a phone. We checked the layout with Chrome's device emulation rather than on real devices. At phone width, the desktop is view-only (you can zoom in, but not click), while the terminal stays fully usable and gains a row of Esc, Ctrl, Tab, arrow and symbol keys. At iPad width, you can control the desktop as well.

Limits to know about

It is a beta. There is no backup guarantee, so keep important work in Git or somewhere else.
One size, 2 vCPU and 4 GB. Large builds or several containers at once will feel it.
Sessions stop after 8 continuous hours, and there is the 200-hour monthly cap. Paid accounts can have up to 2 machines, both running at once; trial accounts get 1.
Retention: a paid account's machine is deleted 30 days after it was last used, a trial machine after 24 hours.
Traffic: each month includes 186.3 GiB of download and 93.1 GiB of upload; our session used 16 MiB.
Start time: about 30 seconds in our latest test, longer when many machines start at once. Resuming a paused machine took about 11 seconds.

Try it

New accounts get $0.05 of free credit, no card required, which covers about two and a half running hours shared with your agents' AI usage. After that, add $5 or more by card to keep going. Open Machines, create one, and type claude in the terminal.

If you would rather run the agents on your own computer, our setup guides cover Claude Code, Codex CLI and OpenCode and Crush.

Gemini 4 Argon vs Claude Opus 5.5 for coding agents

xiun xiao — Wed, 04 Nov 2026 01:42:42 +0000

Originally published on the QuickSilver Pro blog.

Gemini 4 Argon is Google's new flagship reasoning model. On QuickSilver Pro it costs $2.00 / $10.00 per million tokens, against $1.00 / $5.00 for Claude Opus 5.5. We wanted to know whether it can stand in for Opus in a coding agent, and what that costs.

We tested this on 2026-10-27. Both models ran in the same agent, OpenCode, on six small but real coding tasks, and we graded every run with tests the agent never saw. Short answer: both passed every hidden test in every run. Gemini 4 Argon was slower and more expensive on every task: 134 seconds and $0.142 per task on average, against 82 seconds and $0.094 for Opus.

How we tested

Agent: OpenCode 1.19.4, non-interactive (opencode run --auto), with QuickSilver Pro added as an OpenAI-compatible provider. The only thing that changed between runs was -m quicksilverpro/gemini-4-argon or -m quicksilverpro/claude-opus-5-5. QuickSilver Pro serves Gemini 4 Argon on the OpenAI-compatible endpoints (/v1/chat/completions and /v1/responses), not on the Anthropic Messages API that Claude Code needs. So we used one agent that can drive both models.
Agent settings: a clean OpenCode config with no MCP servers, plugins or extra skills, and OpenCode's defaults otherwise. OpenCode sent no reasoning-effort setting, so each model ran at its default. OpenCode chooses its system prompt by model family, and we left that as shipped. Gemini got a 16,400-character system prompt and Opus a 9,300-character one. Both got the same tools.
Tasks: six throwaway Python repositories, each with a one-paragraph prompt, a spec or bug report in the repo, and one visible test. Every task had a separate hidden test suite that we ran after the agent finished. We wrote five of the suites before any run and checked that each passed against our own reference solution and failed against the starting code. The sixth is the official Mustache spec suite.
Runs: each task twice per model, same inputs, 24 runs in total. Both models ran each task at the same time, so both saw the same network and server conditions.
Graded on: the share of hidden tests passing. We also recorded wall-clock time, number of API requests, input / cached / output tokens, and cost.
Cost: the per-request cost that QuickSilver Pro returns in each response's usage block, summed over every request in a run, at QuickSilver Pro prices on 2026-10-27. We recorded it with a small local pass-through proxy. The same figures appear per request in the dashboard.

The tasks:

Two-file bug fix. A shop module whose totals were off by a cent and whose discount was applied twice. The fix needed changes in both files, plus a rule from the README that the bug report did not mention: a minimum order for one discount code. 18 hidden tests.
Implement from a spec. A duration parser ("1h30m", "2 hours and 5 min", "PT1H30M") with a page of rules on separators, unit order and what must be rejected, including non-ASCII digits. 84 hidden tests.
Refactor without changing behaviour. Split a long function full of copy-pasted code into helpers. The hidden tests compared the new output with the original on 300 random inputs and 16 edge cases, including invalid options and missing fields. They also checked that the function shrank to at most half its original length. 317 hidden tests.
Add input validation. A sign-up function with a written rule set: per-field error codes, rule order, and fields that interact. For example, a password must not contain the username, but only if the username is valid. 84 hidden tests.
Parser for a config format. Sections, quoted values with escapes, inline comments, line continuation with correct error line numbers, and ${section.key} references with cycle detection. 57 hidden tests.
A Mustache template renderer from scratch, graded against the official Mustache spec test suite: interpolation, sections, inverted sections, comments, partials and delimiter changes. 136 hidden tests.

Results

Averages over two runs per model and task. Cost is per run, at QuickSilver Pro prices on 2026-10-27.

Task	Gemini 4 Argon: tests passed	Gemini 4 Argon: time	Gemini 4 Argon: cost	Opus 5.5: tests passed	Opus 5.5: time	Opus 5.5: cost
1. Two-file bug fix	18/18, both runs	73 s	$0.079	18/18, both runs	34 s	$0.049
2. Duration parser	84/84, both runs	74 s	$0.100	84/84, both runs	53 s	$0.063
3. Refactor	317/317, both runs	133 s	$0.131	317/317, both runs	85 s	$0.091
4. Input validation	84/84, both runs	86 s	$0.104	84/84, both runs	65 s	$0.075
5. Config parser	57/57, both runs	267 s	$0.267	57/57, both runs	116 s	$0.132
6. Mustache renderer	136/136, both runs	173 s	$0.172	136/136, both runs	139 s	$0.155
Average	all passed	134 s	$0.142	all passed	82 s	$0.094

Where the tokens and the money went, averaged over all 12 runs per model:

Per run	Gemini 4 Argon	Opus 5.5
Requests (including one short title request from OpenCode)	10.2	7.9
Input tokens	124,000	107,000
...of which read from the prompt cache	86,000 (69%)	54,000 (51%)
Output tokens	5,600	7,800
...of which reasoning	900	0
Cost of uncached input	$0.077	$0.052
Cost of cached input	$0.009	$0.003
Cost of output	$0.056	$0.039
Total cost per task	$0.142	$0.094

What the numbers say

Quality was a tie. Neither model failed a hidden test in 24 runs. That includes all 136 cases of the official Mustache suite and the 316 comparisons with the original function in the refactor.

Gemini got there with less checking. On the refactor, both Opus runs saved a copy of the original function and compared old and new output on random inputs before finishing. Neither Gemini run did that; Gemini relied on the one visible test and still matched the original on all 316 hidden comparisons. On the Mustache task, both Opus runs downloaded the official spec test files from GitHub and ran them. Our hidden tests for that task are the same files, so Opus's score there is not independent. Gemini did not download them and passed all 136 anyway. What Gemini did instead was run the test suite more often: 24 pytest runs over its 12 runs, against 14 for Opus.

Gemini was slower on every task, from 1.2 times as long on the Mustache renderer to 2.3 times on the config parser. Its typical request was actually quicker than Opus's, with a median of 6.2 seconds against 7.6. But it made more requests (10.2 per task against 7.9), and its slow requests were slower: one in ten took over 34 seconds, and the slowest took 109. The config parser shows the effect most: the second Gemini run took 18 requests and almost five minutes.

Gemini cost more on every task, about 1.5 times as much on average. It has the higher per-token prices on QuickSilver Pro, and it sent more input per task because it made more requests. It wrote fewer output tokens than Opus, but at its output price they still cost more ($0.056 against $0.039 per task). Gemini's caching did better than Opus's: 69% of its input came from the prompt cache. On every Opus request the cache covered the same 8,028 tokens, about the size of OpenCode's system prompt and tool definitions. The rest of the conversation was billed at the full input rate. Even so, Opus came out cheaper.

When Gemini 4 Argon makes sense

On these tasks, Opus 5.5 is the better choice for a coding agent. It solved the same tasks, in about 60% of the time, for about two thirds of the cost.

Gemini 4 Argon solved every task too, so it is a workable second model. Use it if you want a non-Anthropic model in the loop, for example to cross-check a change, or if you are already building on Gemini elsewhere. We did not find a task in this set that either model failed, so we cannot tell you which one solves more on harder work. On this evidence, Gemini 4 Argon does not save you money over Opus 5.5.

Limits of this test

Six tasks, two runs per model. Small, self-contained Python tasks of 30 seconds to 5 minutes each, not a multi-hour change in a large codebase.
We wrote five of the six hidden test suites, so they reflect our reading of each spec. We checked each against a reference solution before running the agents.
One agent, OpenCode, with its default per-model system prompts. Another agent, or a different reasoning-effort setting, could change both the speed and the cost. Gemini used about 900 reasoning tokens per task at its default effort. Opus reported none, so it worked without extended thinking.
The prompt told the agents not to edit the existing tests. In four runs Gemini added its own tests to the end of the existing test file instead of creating a new one. It did not change or remove the existing test, and the hidden tests are separate, so this did not affect the scores.
Wall time includes network and server time. Two runs of the same model on the same task differed by up to 47%, so read the time column as a rough guide.
Every Claude request reported about 690 more input tokens than the text sent. OpenCode's short title request, which is the same text for every model, came to 1,593 input tokens on Opus against 639 on Gemini. At 7.9 requests per task that adds at most about $0.005 to an Opus run, which does not change the comparison.

Run it yourself

The OpenCode config we used, pointed at the public endpoint. Save it as opencode.json in your project:

{
  "$schema": "https://opencode.ai/config.json",
  "provider": {
    "quicksilverpro": {
      "npm": "@ai-sdk/openai-compatible",
      "name": "QuickSilver Pro",
      "options": {
        "baseURL": "https://api.quicksilverpro.io/v1",
        "apiKey": "{env:QSP_API_KEY}"
      },
      "models": {
        "gemini-4-argon": { "name": "Gemini 4 Argon", "limit": { "context": 1000000, "output": 64000 } },
        "claude-opus-5-5": { "name": "Claude Opus 5.5", "limit": { "context": 1000000, "output": 64000 } }
      }
    }
  }
}

Then run the same prompt with each model:

export QSP_API_KEY=YOUR_QSP_KEY

opencode run --auto -m quicksilverpro/gemini-4-argon "Fix the failing test in tests/"
opencode run --auto -m quicksilverpro/claude-opus-5-5 "Fix the failing test in tests/"

--auto approves the agent's file edits and shell commands without asking, so use it only in a project you can reset. OpenCode shows a cost of 0 for a custom provider. The real cost of each request, with its model and token counts, is in your QuickSilver Pro dashboard. Model details are on the Gemini 4 Argon and Claude Opus 5.5 pages. For the OpenCode setup, see Use QuickSilver Pro in OpenCode and Crush. For Opus against GPT-6.1 Sol on the same tasks, see Claude Opus 5.5 vs GPT-6.1 Sol for coding agents.

Kimi K3.1 Pro Highspeed vs Pro: we measured the real speedup

xiun xiao — Tue, 03 Nov 2026 01:16:46 +0000

Originally published on the QuickSilver Pro blog.

Kimi K3.1 Pro Highspeed is the same model as Kimi K3.1 Pro, served on Moonshot's high-speed endpoint. On QuickSilver Pro it costs $4.00 / $20.00 per million tokens, twice the $2.00 / $10.00 of the standard version. The usual pitch is "about three times faster". We wanted to know how much faster it is end to end, and when the extra money buys anything.

We tested both on 2026-11-02 through the QuickSilver Pro API, in two ways: single API requests of three shapes, and a coding agent working on six tasks with hidden tests. Short answer:

Generation speed: Highspeed generated text 2 to 3 times faster.
Time to first token: about the same for both models. Highspeed does not start answering any sooner.
End to end: a short answer arrived 1.7 times faster and a long code answer 2 times faster. A question about a 52,000-token log came back only 1.25 times faster.
Coding agent: every task finished 2.5 times faster on average, for 1.5 times the cost. Both versions passed every hidden test.

Test 1: single API requests

How we tested

Requests: streamed /v1/chat/completions calls with default settings, sent by a small Python script. Each model got three request types:
- Short answer: "In three sentences, explain what a database index is and when it hurts write performance." About 110 input tokens.
- Long code answer: an LRU cache module with per-entry TTL, thread safety and size-based eviction, plus a pytest file. About 150 input tokens; both models wrote about 11,700 output tokens, of which about 9,400 were reasoning.
- Long input: a 52,614-token service log with one line naming the root cause of an incident. The question asked the model to quote that line and explain it.
Runs: 8 per model and request type, 48 requests in total. The two models alternated going first, so both saw the same network and server conditions.
No cache: every request started with a unique tag, so no request was served from the prompt cache.
Measured: time to the first token (reasoning or answer), total time, output tokens per second after the first token, and the cost QuickSilver Pro returned in each response's usage block.

Results

Medians of 8 runs per model and request type.

Request	Model	First token	Total time	Output tokens/s	Cost per request
Short answer	Kimi K3.1 Pro	2.1 s	9.8 s	37	$0.0028
Short answer	Highspeed	2.8 s	5.7 s	102	$0.0059
Long code answer	Kimi K3.1 Pro	2.2 s	5 min 42 s	34	$0.117
Long code answer	Highspeed	2.7 s	2 min 51 s	71	$0.235
52K-token log	Kimi K3.1 Pro	7.3 s	12.4 s	51	$0.108
52K-token log	Highspeed	7.4 s	9.9 s	148	$0.216

Both models found the root-cause line in all 16 long-input runs and quoted it exactly.

What the numbers say

The speedup is in generation, not in getting started. Once text started flowing, Highspeed produced 2 to 3 times as many tokens per second. Time to first token was the same, or slightly longer on Highspeed: 2.8 seconds against 2.1 for the short answer. On the long log both models spent about 7 seconds reading the input before the first token.

So the end-to-end gain depends on the shape of the request. Total time is the wait for the first token plus the generation time. The more of a request is generation, the closer it gets to the full speedup:

Short answer: 1.7 times faster. Waiting for the first token is a big share of a 10-second request.
Long code answer: 2 times faster, or 2 minutes 51 seconds saved per answer.
52K-token log: 1.25 times faster. Most of the time goes to reading the input, so Highspeed saved about 2.5 seconds for twice the cost.

Twice the price meant twice the cost per request. Both models wrote about the same number of tokens for the same request, so each Highspeed request cost almost exactly double.

Kimi reasons a lot by default. Between 60% and 80% of the output tokens were reasoning, depending on the request type. The long code answer varied from 6,200 to 15,300 output tokens across runs of the same prompt, so the cost of a single request can swing by a factor of two either way.

Test 2: a coding agent on six tasks

How we tested

Agent: OpenCode 1.19.4, non-interactive (opencode run --auto), with QuickSilver Pro added as an OpenAI-compatible provider. The only thing that changed between runs was -m quicksilverpro/kimi-k3.1-pro or -m quicksilverpro/kimi-k3.1-pro-highspeed.
Agent settings: a clean OpenCode config with no MCP servers, plugins or extra skills, and OpenCode's defaults otherwise. Both models got the same system prompt and tools.
Tasks: the six tasks from our Gemini 4 Argon vs Claude Opus 5.5 test. Each is a throwaway Python repository with a one-paragraph prompt, a spec or bug report, one visible test, and a separate hidden test suite that we ran after the agent finished:
1. Two-file bug fix in a shop module. 18 hidden tests.
2. A duration parser implemented from a page of rules. 84 hidden tests.
3. A refactor that must not change behaviour. 317 hidden tests.
4. Sign-up validation with interacting rules. 84 hidden tests.
5. A config-format parser with references and cycle detection. 57 hidden tests.
6. A Mustache template renderer, graded against the official Mustache spec suite. 136 hidden tests.
Runs: each task twice per model, 24 runs in total. The two models ran side by side.
Cost: the per-request cost that QuickSilver Pro returned, summed over every request in a run.

Results

Both models passed every hidden test in every run. Averages over two runs per model and task:

Task	Kimi K3.1 Pro: time	Kimi K3.1 Pro: cost	Highspeed: time	Highspeed: cost	Speedup
1. Two-file bug fix	226 s	$0.143	115 s	$0.251	2.0x
2. Duration parser	284 s	$0.149	135 s	$0.259	2.1x
3. Refactor	365 s	$0.194	129 s	$0.310	2.8x
4. Sign-up validation	263 s	$0.134	105 s	$0.206	2.5x
5. Config parser	559 s	$0.268	272 s	$0.477	2.1x
6. Mustache renderer	754 s	$0.440	239 s	$0.463	3.2x
Average	409 s	$0.221	166 s	$0.328	2.5x

All twelve runs per model together took 82 minutes on Kimi K3.1 Pro and 33 minutes on Highspeed.

What the numbers say

In an agent, Highspeed cost 1.5 times as much, not 2. About 90% of each run's input tokens were cache reads. An agent sends the whole conversation again on every request, and the repeated part comes from the prompt cache. Cache reads cost $0.20 per million tokens on both versions, so only the new input and the output pay the doubled price.

Saving four minutes cost about eleven cents. On average a task took 4 minutes less on Highspeed and cost $0.107 more.

The Mustache gap is partly luck. In one of its two Mustache runs, Kimi K3.1 Pro started a sub-agent and made 41 requests, against 11 to 18 in the other Mustache runs. That run took 18 minutes and cost $0.65. Without it, the Mustache times were 7 minutes against 4. All four Mustache runs downloaded the official spec tests and ran them before finishing. Our hidden tests for that task are the same files, so the Mustache scores are not independent.

When Highspeed is worth it

Someone is waiting: chat, coding assistants, interactive agents. Two to three times faster generation is easy to feel. An agent task that takes 7 minutes takes about 3.
Long answers: code generation and long-form writing, where generation is most of the time.
Agents with long sessions: the prompt cache keeps the extra cost to about 1.5 times.

Stay on Kimi K3.1 Pro for:

Batch jobs and pipelines, where nobody watches the clock. You pay twice as much for time nobody uses.
Long input, short output: summarising, extraction and search over big documents. On our 52,000-token log, Highspeed saved 2.5 seconds per request at twice the price.

Limits of this test

One day of measurements (2026-11-02). Serving speed depends on load, so another day or time could give different numbers, for either version.
Eight runs per API request type and two runs per agent task. The agent times varied by up to 2.5 times between two runs of the same task, mostly because of how much the model chose to reason or check its own work.
Times include network time from our client to QuickSilver Pro and on to the provider.
Default settings only. We did not change the reasoning effort or limit reasoning tokens. Either would change speed and cost for both versions.
One agent, OpenCode, and small Python tasks of 1.5 to 18 minutes each, not a multi-hour change in a large codebase.

Run it yourself

Stream a request to each model and watch the difference:

export QSP_API_KEY=YOUR_QSP_KEY

for model in kimi-k3.1-pro kimi-k3.1-pro-highspeed; do
  echo "== $model"
  time curl -sN https://api.quicksilverpro.io/v1/chat/completions \
    -H "Authorization: Bearer $QSP_API_KEY" \
    -H "Content-Type: application/json" \
    -d "{\"model\": \"$model\", \"stream\": true, \"messages\": [{\"role\": \"user\", \"content\": \"Write a Python LRU cache with TTL.\"}]}" \
    > /dev/null
done

To try both in OpenCode, add QuickSilver Pro as a provider in opencode.json:

{
  "$schema": "https://opencode.ai/config.json",
  "provider": {
    "quicksilverpro": {
      "npm": "@ai-sdk/openai-compatible",
      "name": "QuickSilver Pro",
      "options": {
        "baseURL": "https://api.quicksilverpro.io/v1",
        "apiKey": "{env:QSP_API_KEY}"
      },
      "models": {
        "kimi-k3.1-pro": { "name": "Kimi K3.1 Pro" },
        "kimi-k3.1-pro-highspeed": { "name": "Kimi K3.1 Pro Highspeed" }
      }
    }
  }
}

opencode run --auto -m quicksilverpro/kimi-k3.1-pro "Fix the failing test in tests/"
opencode run --auto -m quicksilverpro/kimi-k3.1-pro-highspeed "Fix the failing test in tests/"

Every request shows up in your QuickSilver Pro dashboard with its model, token counts and cost, so you can compare the two versions on your own work. Prices for every model are on the pricing page.

9 image prompts worth saving: we ran each one over the API

xiun xiao — Mon, 26 Oct 2026 06:49:36 +0000

Nine image prompts collected from GitHub prompt repositories and Threads posts, each one run once over the API on 2026-10-26. Every prompt is plain text-to-image: no photo upload needed.

Every image below is the first result we got from the exact prompt shown, through the QuickSilver Pro API. Nothing was retried or cherry-picked. Prompts are credited to their authors.
Short prompts ran on GPT Image 2.5 Flare ($0.018 per image, 1024x1024). The three prompts longer than 1,000 characters ran on GPT Image 2 ($0.01 per image), because Flare on QuickSilver Pro accepts prompts up to 1,000 characters and 1024x1024 only.
All ten images together cost $0.16.
Replace anything in [brackets] with your own content.
The last section shows how to run these prompts yourself.

1. City-name letter poster

A giant city name where every letter is filled with a local street scene, with a panorama strip on top. The original Threads post has 23,000 likes, and the replies are full of "do my city".

GPT Image 2, requested 1536x1024, returned 1672x941, 78 seconds, $0.01.

The prompt is written in Traditional Chinese, and the English lettering still came out spelled correctly. To change the city, swap three things: the city name, the scene in each letter, and the panorama strip.

製作一張精緻的香港城市旅遊插畫海報，16:9 橫式構圖，暖米白色紙張背景，四周保留乾淨留白。整體結合復古旅行海報、現代平面設計與細緻建築插畫，使用清晰色塊、柔和漸層、細微印刷顆粒與霧面紙張質感。
【核心文字構圖】
畫面中央以極大型英文大寫「HONG KONG」作為主體。文字必須拼寫正確，八個字母完整入鏡，排列為同一行，兩個單字之間保留清楚間距。使用筆畫厚實、窄長比例、幾何感強烈的無襯線字體，所有字母頂部與底部整齊對齊，佔畫面寬度約96%、高度約50%。
使用精準的字母遮罩填景效果：Typography Masking、Image-filled Typography、Clipping Mask Lettering。香港城市風景只出現在字母的實心筆畫內，字母輪廓清楚銳利；字母外部、字母間隙與字母內部孔洞均維持乾淨米白色。每個字母是一幅精緻的小型城市風景插畫，所有場景共享一致畫風與配色。
【八個字母的場景】
第一個 H：香港街道，紅色雙層電車沿軌道行駛，兩旁高樓、直立中文招牌與行人。
第一個 O：青藍色維港海面、紅色中式帆船，背景為高樓與層疊山巒。
第一個 N：茂密綠色山坡，一列紅色登山纜車沿斜坡軌道行駛，遠處可見城市。
第一個 G：中式廟宇入口，綠色琉璃瓦、紅柱、紅燈籠、石階與石獅。
K：繁忙商業街，密集垂直招牌、商店立面、行人與黃色道路標線。
第二個 O：寧靜海灣、淺色沙灘、碧綠海水、沿岸山坡與前景粉紅花叢。
第二個 N：珊瑚粉與蜜桃色夕陽下的香港天際線，海面呈現柔和倒影，一艘紅帆船航行其中。
最後一個 G：淡粉與奶油白色的歷史風格鐘樓建築，拱形窗、柱廊、階梯與棕櫚樹。
【上方全景】
在巨型文字上方安排一條細長、橫跨畫面的香港城市全景帶。由左至右自然串連中式廟宇、樹木、紅色的士、紅色雙層巴士、渡輪、跨海橋樑、維港高樓、紅帆船與沿岸歷史建築。遠方是青綠山巒，天空留白充足，點綴幾隻飛鳥、少量淡粉雲朵與右上方一輪珊瑚粉色太陽。全景帶與中央字母之間保留米白色間隔。
【色彩與質感】
以湖水藍、青綠、珊瑚粉、蜜桃色、奶油白為主，少量朱紅作為電車、帆船與燈籠的視覺亮點，深藍灰用於局部陰影。配色柔和清爽，帶復古印刷感。建築透視合理，線條俐落，細節豐富但不凌亂。
【底部排版】
中央放置一行較小的深藍灰色英文「HONG KONG」，使用寬字距無襯線字體，左右各搭配一條纖細水平線。
下方以更小字級、寬字距排入：
「A CITY OF VIBES, A PLACE LIKE NO OTHER」
全部文字清晰、準確、水平置中。
【避免】
不要寫實照片、3D立體字、厚重陰影、金屬字體、霓虹招牌風格、油畫筆觸、過度飽和、雜亂拼貼。不要讓風景溢出中央字母邊界，不要填滿字母孔洞，不要變形字母、錯字、缺字、額外字母、裁切標題、水印或額外Logo。

Source: @bunny_digital on Threads; the prompt was shared in the replies by @ailuna4482.

2. Pixar-style 3D avatars

A consistent avatar set: keep the sentence structure and change the person. Replace MODEL with a role (software engineer, barista...) and adjust hair, glasses, expression and clothes.

`MODEL` = software engineer	`MODEL` = data analyst

GPT Image 2.5 Flare, 1024x1024, $0.018 each.

Create a head-and-shoulders Pixar-style 3D avatar of a cute, introverted MODEL with dark hair in space buns and oversized round glasses. She features a wide-eyed expression of wonder with a small "O" shaped mouth, wearing a chunky cream-colored knit sweater. Set against a seamless white background, the render showcases flawless 3D skin and soft cinematic studio lighting for a clean, minimalist aesthetic.

Create a head-and-shoulders Pixar-style 3D avatar of a sharp-witted MODEL with curly dark hair and thick-rimmed modern glasses. He features a skeptical expression with one raised eyebrow, a calculating smirk, and eyes looking sideways against a seamless white background. Wearing a dark charcoal hoodie, the render showcases flawless 3D skin and soft cinematic studio lighting for a clean, minimalist aesthetic.

Source: @designbysaqi_ on Threads. The prompts are printed under the original images; these two are transcribed from them.

3. Exploded food infographic

A dish split into floating layers, stacked vertically, with a label line for each layer. Change the food and the layer list for a burger, a ramen bowl or bubble tea.

GPT Image 2.5 Flare, 1024x1024, $0.018. All five labels are spelled as given.

Create a hyper-realistic exploded vertical infographic composition of tacos.
Top → Bottom structure:
Fresh Lettuce (crisp green texture with natural folds)
→ Tomato & Salsa Layer (juicy diced tomatoes and salsa mix)
→ Melted Cheese (smooth cheddar texture)
→ Grilled Meat Filling (juicy seasoned meat detail)
→ Taco Shell Base (crispy golden shell texture)
Perfect vertical alignment, rustic background, soft studio lighting, realistic shadows beneath each floating element.
Add clean infographic text labels with thin pointer lines using these exact labels:
"Lettuce" "Salsa" "Cheese" "Meat" "Shell"
Ultra-detailed food textures, premium commercial aesthetic, 8K.

Source: awesome-gpt-image-2, case 443, by @Strength04_X.

4. A country as a felt miniature world

One cohesive diorama of a country: daily life in front, streets and rivers in the middle, one landmark at the back. Fill in the country on the first line; we used Portugal.

GPT Image 2, 1024x1536, 78 seconds, $0.01. The layout follows the prompt closely (café life in front, a tram street in the middle, a castle and the bridge at the back), but the result looks more like a painted illustration than wool felt. If the felt texture matters, push it harder in the prompt or try another model.

Country: [INSERT COUNTRY NAME]

A miniature felt diorama made of fluffy yarn, wool, and needlework, designed as a single cohesive small world (not a collage), reflecting the real landscape, culture, and daily life of the country.

Structure:
- Select 4–7 naturally integrated elements (landscape, architecture, transport, street life, culture)
- Everything must flow together as one environment

Foreground:
Everyday life — small shops, cafes, markets, people interacting, local clothing, street details, subtle movement, warm human presence

Midground:
Connecting flow — streets, bridges, rivers, paths, transport, cultural spaces that guide the eye naturally from front to back

Background:
One strong identity anchor — landmark, skyline, mountain, or symbolic landscape clearly representing the country (keep it clean, not overcrowded)

Style:
Handmade wool felt, yarn, needle-felt textures, visible fibers, soft edges, miniature craftsmanship, premium diorama realism

Lighting:
Warm golden hour or bright noon, soft shadows, clear visibility, gentle glow enhancing depth

Color:
Soft but saturated palette reflecting the country’s natural tones (greens, sky blues, architectural hues, cultural accents), warm and balanced

Composition:
Vertical frame, balanced or centered perspective, slight top-down or immersive angle, clear foreground–midground–background depth

Mood:
Warm, emotional, calm, refined — like a handcrafted fairy-tale version of real life (not childish)

Rules:
- No logos or text overlays
- No collage-style composition
- No random symbolic clutter
- Keep it realistic but stylized as a handmade miniature world

Quality:
16K, ultra-detailed, hyper-realistic miniature textures, cinematic depth, sharp focus

output_goal:
A single, cohesive felt diorama world that instantly conveys the identity and atmosphere of the chosen country through integrated landscape, culture, and daily life

Source: awesome-gpt-image-2, case 390, by @volkan_iras.

5. A seed packet growing into its garden

A surreal product scene: the illustration on a seed packet turns into the real plant. Fill in the plant, two details and an insect. We used sunflowers, "A sunflower head", "A tight green sunflower bud" and honeybees.

GPT Image 2, requested 1024x1024, returned 1536x1024, 78 seconds, $0.01. The back of the packet even turned "sow in spring" and "full sun" into printed instructions.

Epic 3D scene: a weathered seed packet lying open on a potting bench, its promise erupting into the garden it describes. The illustration on the front becomes real. [PLANT / FLOWER] growing at full scale from the paper, roots visible through the packet's base pushing into soil below.
[DETAIL 1] in full bloom at one corner. [DETAIL 2] mid-growth at the other, not yet what it will be.
Tiny insects that belong to this plant, [BEE / BUTTERFLY / BEETLE], hovering at correct scale.
The written instructions on the back become garden calendar, "sow in spring" manifests as actual spring light. "full sun" manifests as a single shaft of it, hitting the tallest bloom perfectly.
Scattered seeds between packet and soil each showing their germination stage, split coat, first root, first shoot, first leaf.
The packet's torn top edge becomes a treeline.
Potting bench surface with soil scatter and water droplets.
Tilt-shift depth of field, greenhouse morning light, the packet as the garden it always intended.

Source: awesome-gpt-image-2-API-Prompts, case 143 (CC0), by @AllaAisling.

6. A miniature city hidden in hair

A macro photo with a tiny city between the hair strands. The run of "no glow", "no CGI", "no perfect surfaces" at the end is what makes it look like a real photo, so keep it.

GPT Image 2.5 Flare, 1024x1024, $0.018.

Macro photograph of a miniature city hidden in human hair, clearly on a real human head, with part of the forehead and hairline visible, realistic skin texture with pores, tiny people walking through the streets between the hair strands, extremely small but realistic proportions, macro photography, 85mm lens, shallow depth of field, natural lighting, neutral colors, no warm tones, ultra realistic hair with visible roots, natural imperfections, slightly messy strands, realistic materials, slightly dirty buildings, no perfect surfaces, photorealistic, looks like a real photo, no illustration, no CGI, no glow

Source: awesome-gpt-image-2, case 392, by @krafterlab.

7. Tiny text on a grain of rice

One sentence that tests how well a model handles very small text. Replace "wOw" with your own word.

GPT Image 2.5 Flare, 1024x1024, 23 seconds, $0.018. The word is on one grain just above the centre.

A massive pile of rice, and on one single grain of rice there is tiny text that reads "wOw"

Source: awesome-gpt-image, by @adonis_singh.

8. One-liners that fill in the layout themselves

Short prompts where the model invents the whole interface or document.

A YouTube video by a time traveller:

GPT Image 2.5 Flare, 1024x1024, $0.018. It invented the title, channel, view count and comments.

Screenshot of a YouTube video showing someone who time-traveled to the Middle Ages

A Chinese national exam paper (replace the subject; we used mathematics):

GPT Image 2.5 Flare, 1024x1024, $0.018. Header, instructions, numbered questions and a geometry figure, all in Chinese.

Generate an image of a 2026 Gaokao exam paper for [subject name]

Sources: YouTube screenshot by @flowersslop and exam paper by @MrLarus, both via awesome-gpt-image.

9. A quick test for text rendering

To see which model spells text correctly, this prompt is the fastest check: three lines on a coffee bag, so a wrong letter is obvious. These four images come from the same prompt with the same settings (size="1024x1024", n=1).

GPT Image 2.5 Flare	Qwen Image 3.0	FLUX.2 Klein	SDXL Turbo

All three lines correct	All three lines correct	All three lines correct	Garbled

Product photo of a matte black coffee bag standing on a wooden table. The front label reads "NORTHWIND ROASTERS" in large white capital letters, and below it, in smaller text, "Ethiopia Yirgacheffe" and "250 g". Soft studio lighting, shallow depth of field.

Source: our own test in Image generation API compared: 11 models, the same 3 prompts, which has the full results.

Tips for editing these prompts

Fill in every placeholder. [brackets], MODEL and similar markers get drawn literally if you leave them in.
Keep the structure of long prompts. In sections 1 and 4 each block controls one thing (layout, colour, what to avoid). Change the content, not the blocks.
Quote any text that must appear, for example "HONG KONG", so the model does not rephrase it.
Check the model's limits before you pick a shape. On QuickSilver Pro, GPT Image 2.5 Flare takes 1024x1024 and prompts up to 1,000 characters only. GPT Image 2 takes longer prompts and other sizes, but it does not always return the size you ask for: in our runs 1536x1024 came back as 1672x941 and 1024x1024 as 1536x1024.
Keep the "avoid" list. Listing what you do not want (watermarks, 3D text, oversaturation) is more reliable than describing only what you want.

Running them over an API

ChatGPT and Gemini work for one image at a time. To generate a batch (a poster for every city on a list, a full avatar set) or compare models on the same prompt, an API is easier. The examples below use QuickSilver Pro: one key for a dozen image models behind the OpenAI-compatible /v1/images/generations endpoint, billed per image.

Prices per image on 2026-10-26:

Model	Model ID	Per image
GPT Image 2	`gpt-image-2`	$0.01
GPT Image 2.5 Flare	`gpt-image-2.5-flare`	$0.018
Nano Banana 2.1	`gemini-nano-banana-2.1`	$0.036
Seedream 5.0 Pro	`seedream-5.0-pro`	$0.07

curl:

curl https://api.quicksilverpro.io/v1/images/generations \
  -H "Authorization: Bearer $QSP_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "gpt-image-2.5-flare",
    "prompt": "A massive pile of rice, and on one single grain of rice there is tiny text that reads \"wOw\"",
    "size": "1024x1024",
    "n": 1
  }' | jq -r '.data[0].b64_json' | base64 --decode > rice.png

Python, with the official OpenAI SDK and a different base_url:

import base64
import urllib.request

from openai import OpenAI

client = OpenAI(
    base_url="https://api.quicksilverpro.io/v1",
    api_key="YOUR_QSP_KEY",
)

result = client.images.generate(
    model="gpt-image-2.5-flare",
    prompt=open("prompt.txt", encoding="utf-8").read(),
    size="1024x1024",
    n=1,
)

image = result.data[0]
if image.b64_json:
    data = base64.b64decode(image.b64_json)
else:  # Seedream and Bria return a download link instead
    data = urllib.request.urlopen(image.url).read()

with open("out.png", "wb") as f:
    f.write(data)

For a batch, loop over a list of prompts and call client.images.generate for each.

Which model to use

From the comparison in section 9 and today's runs:

Images with text (posters, packaging, labels): GPT Image 2.5 Flare got the text and object counts right in every run of the comparison. In today's runs it took 23 seconds for a single request and 37 to 60 seconds with five requests in parallel.
Long prompts or non-square images: GPT Image 2 at $0.01 per image. It took about 78 seconds per image today and did not keep the requested size.
Seedream and Bria return a URL instead of the image. Download it straight away; we did not test how long the links stay valid.

Model list, prices and docs: quicksilverpro.io.

Claude Opus 5.5 vs Sonnet 5.5 for coding agents: is Opus worth it?

xiun xiao — Fri, 23 Oct 2026 04:51:39 +0000

Originally published on the QuickSilver Pro blog.

Claude Opus 5.5 costs $1.00 / $5.00 per million tokens on QuickSilver Pro, against $0.50 / $2.50 for Claude Sonnet 5.5. The question for anyone running a coding agent is whether Opus buys anything for that.

We tested it on 2026-10-20 with Claude Code, on six small but real coding tasks, and graded every run with tests the agent never saw. Short answer: on these tasks, no. Both models passed every hidden test in every run. Opus was slower and, per task, cost about two and a half times as much.

How we tested

Agent: Claude Code 2.1.301, non-interactive (claude -p), default settings, with --allowedTools "Read,Edit,Write,Bash,Glob,Grep" so it could read and edit files and run shell commands. The only thing that changed between runs was --model claude-sonnet-5-5 or --model claude-opus-5-5. ANTHROPIC_DEFAULT_HAIKU_MODEL was set to claude-haiku-5-5.
Tasks: six throwaway Python repositories, each with a one-paragraph prompt, a spec or bug report in the repo, and one visible test. Every task had a separate hidden test suite that we ran after the agent finished. Five suites were written by us before any run and checked against our own reference solutions; the sixth is the official Mustache spec suite.
Runs: each task twice per model, same inputs, 24 runs in total.
Graded on: the share of hidden tests passing. Also recorded: wall-clock time, number of API requests, input / cached / output tokens, and cost.
Cost: computed from the token counts of every request each run made, at QuickSilver Pro prices on 2026-10-20 — input, output, cache reads and cache writes each at their own rate.

The tasks:

Two-file bug fix. A shop module whose totals were off by a cent and whose discount was applied twice. The fix needed changes in both files plus a rule from the README that the bug report did not mention (a minimum order for one code). 17 hidden tests.
Implement from a spec. A duration parser ("1h30m", "2 hours and 5 min", "PT1H30M") with a page of rules on separators, unit order and what must be rejected. 57 hidden tests.
Refactor without changing behaviour. Split a long function full of duplicated code into helpers. The hidden tests compared the new output with the original on 300 random inputs and a set of edge cases, and checked that the function actually got shorter. 312 hidden tests.
Add input validation. A sign-up function with a written rule set: per-field error codes, rule order, and fields that interact (a password must not contain the username, but only if the username is valid). 52 hidden tests.
Parser for a config format. Sections, quoted values with escapes, inline comments, line continuation with correct error line numbers, and ${section.key} references with cycle detection. 34 hidden tests.
A Mustache template renderer from scratch, graded against the official Mustache spec test suite: interpolation, sections, inverted sections, comments, partials and delimiter changes. 136 hidden tests.

Results

Averages over two runs per model and task. Cost is per run, at QuickSilver Pro prices on 2026-10-20.

Task	Sonnet 5.5: tests passed	Sonnet 5.5: time	Sonnet 5.5: cost	Opus 5.5: tests passed	Opus 5.5: time	Opus 5.5: cost
1. Two-file bug fix	17/17, both runs	21 s	$0.048	17/17, both runs	37 s	$0.120
2. Duration parser	57/57, both runs	46 s	$0.093	57/57, both runs	62 s	$0.121
3. Refactor	312/312, both runs	30 s	$0.052	312/312, both runs	81 s	$0.156
4. Input validation	52/52, both runs	33 s	$0.056	52/52, both runs	36 s	$0.088
5. Config parser	34/34, both runs	55 s	$0.075	34/34, both runs	77 s	$0.127
6. Mustache renderer	136/136, both runs	82 s	$0.093	136/136, both runs	137 s	$0.438
Average	all passed	45 s	$0.069	all passed	72 s	$0.175

Where the tokens went, averaged over all 12 runs per model:

Per run	Sonnet 5.5	Opus 5.5
Requests to the chosen model	5.8	6.0
Input tokens to the chosen model	141,000	148,000
...of which read from the prompt cache	111,000	110,000
Output tokens	5,200	5,800
Cost of the chosen model's requests	$0.034	$0.074
Safety-check requests (see below)	1.4	4.0
Cost of the safety checks	$0.036	$0.101
Total cost per task	$0.069	$0.175

What the numbers say

Quality was a tie. Neither model failed a single hidden test in 24 runs, including the 136 cases of the official Mustache suite, which include the fiddly rules for whitespace around standalone tags and indented partials. These tasks did not find a ceiling for Sonnet 5.5, so they cannot show Opus clearing it.

Opus did not write much more. The two models used about the same number of requests and output tokens per task. The model-only cost difference (2.2 times) comes almost entirely from Opus's higher per-token price.

Opus checked its own work more, and that is where its extra time and cost went. It ran more shell commands. On the refactor, both Opus runs wrote a throwaway script that compared the old and new function on random inputs; one of the two Sonnet runs did the same, the other relied on the existing test. On the Mustache task, both Opus runs downloaded the official spec test files from GitHub and ran them before finishing — one of them started a sub-agent to do it — which made that task four times as expensive as with Sonnet. (Our hidden tests for that task are the same files, so Opus's score there is not independent. Sonnet passed all 136 without them.)

Opus was slower in every task, from about the same speed on the validation task to 2.7 times as long on the refactor. Averaged over all runs it took 1.6 times as long.

The extra requests you are billed for

Every run also sent requests to Claude Sonnet 5, a model we never selected. We logged one of them: it is Claude Code's own safety check, a "security monitor" prompt that receives the conversation so far and grades the shell command the agent is about to run. Each check sent about 49,000 input tokens and returned a few tokens of output.

Three things about these checks matter for your bill:

They do not appear in Claude Code's own usage summary, which in our runs listed only the model we picked. They are ordinary API requests made with your key, so they are billed like any other.
In our runs they cost about as much as the Sonnet 5.5 work itself ($0.036 against $0.034 per task).
They scale with how many shell commands the agent runs, not with the model you chose. Opus ran more commands, so it triggered almost three times as many checks; the two Opus Mustache runs, which downloaded files from GitHub, sent 9 and 15.

When Opus earns its price, and when Sonnet is enough

Sonnet 5.5 is enough for the kind of work we measured: bug fixes across a couple of files, implementing a function from a written spec, behaviour-preserving refactors, validation rules, parsers of a few hundred lines. It solved all of them, every time, at about 40% of Opus's cost per task and in less time.

Opus 5.5 is worth trying when Sonnet fails a task — and, judging by these runs, when you want the agent to go out of its way to verify its work, as it did by fuzz-testing its refactors and fetching the reference test suite. We did not find a task in this set that Sonnet failed, so we cannot tell you how much more Opus solves on harder work. Treat that as a reason to keep Opus one /model opus away, not to run it by default.

A practical setup: map Claude Code's sonnet alias to claude-sonnet-5-5 and its opus alias to claude-opus-5-5 (see Claude Code with QuickSilver Pro), work in Sonnet, and switch with /model opus for the task where Sonnet keeps going round in circles.

Limits of this test

Six tasks, two runs per model. Small, self-contained Python tasks of 20 seconds to 2.5 minutes each, not a multi-hour change in a large codebase.
Five of the six hidden test suites were written by us, so they reflect our reading of each spec. We checked each against a reference solution before running the agents.
Wall time includes network and server time, and two runs of the same model on the same task differed by as much as 55%. Read the time column as a rough guide.
Claude Code ran with its default settings, including the default effort level for each model.

Run it yourself

The settings we used, pointed at the public endpoint:

export ANTHROPIC_BASE_URL=https://api.quicksilverpro.io
export ANTHROPIC_AUTH_TOKEN=YOUR_QSP_KEY
export ANTHROPIC_DEFAULT_HAIKU_MODEL=claude-haiku-5-5

claude -p "Fix the failing test in tests/" --model claude-sonnet-5-5 --allowedTools "Read,Edit,Write,Bash,Glob,Grep"
claude -p "Fix the failing test in tests/" --model claude-opus-5-5 --allowedTools "Read,Edit,Write,Bash,Glob,Grep"

Each request shows up in your QuickSilver Pro dashboard with its model, token counts and cost, so you can compare the two models on your own tasks. Prices for every Claude model are in Claude API pricing in 2026.

Image generation API compared: 11 models, the same 3 prompts, real outputs

xiun xiao — Thu, 22 Oct 2026 04:13:44 +0000

Originally published on the QuickSilver Pro blog.

QuickSilver Pro sells a dozen image-generation models behind one OpenAI-compatible endpoint, /v1/images/generations. They are billed per image, and the price per image ranges widely: $0.003 for FLUX.1 Schnell, $0.07 for Seedream 5.0 Pro. The question is what the extra money buys.

So on 2026-10-20 we gave 11 of them the same three prompts and looked at every image.

Model	Price per image
GPT Image 2.5 Flare	$0.018
GPT Image 2.5 Sunburst	$0.018
GPT Image 2	$0.01
Seedream 5.0 Pro	$0.07
Seedream 4	$0.055
Qwen Image 3.0	$0.04
FLUX.2 Pro	$0.027
FLUX.2 Klein	$0.02
FLUX.1 Schnell	$0.003
SDXL Turbo	$0.003
Bria FIBO 1.5	$0.055

Prices as of 2026-10-20; current prices are on the pricing page.

Nano Banana Pro is also in the catalog; it is not part of this test.

How we tested

Three prompts, each testing something different:

Text on packaging: Product photo of a matte black coffee bag standing on a wooden table. The front label reads "NORTHWIND ROASTERS" in large white capital letters, and below it, in smaller text, "Ethiopia Yirgacheffe" and "250 g". Soft studio lighting, shallow depth of field.
Exact composition: Flat vector illustration on a plain white background: exactly three red apples on the left side of the image, and exactly one blue cup on the right side. Nothing else in the image.
Photoreal scene: Photorealistic photograph of a small wooden cabin beside a mountain lake at dawn, mist over the water, a red canoe tied to a wooden dock in the foreground, pine trees, no people.

Every request used the same parameters: size="1024x1024", n=1, nothing else. Each model ran each prompt once. We then ran the composition prompt a second time on every model, one request at a time, to get a cleaner latency figure and a second sample. We judged every image by eye: for the label, whether all three lines are spelled exactly right; for the illustration, whether there are exactly three apples on the left and one cup on the right; for the scene, whether every element in the prompt is there and physically plausible.

Results

Model	Median latency	Text on packaging	Three apples, one cup	Photoreal scene
GPT Image 2.5 Flare	11.5 s	All correct	2 of 2	All elements
GPT Image 2.5 Sunburst	17.5 s	All correct, plus a line we did not ask for	2 of 2	All elements
GPT Image 2	20.2 s	All correct	2 of 2	All elements
Seedream 5.0 Pro	40.8 s	All correct, brand name smaller than asked	1 of 1	All elements
Seedream 4	6.4 s	All correct	1 of 1	All elements, very saturated colours
Qwen Image 3.0	5.0 s	All correct	1 of 2 (four apples once)	All elements
FLUX.2 Pro	8.9 s	All correct	1 of 2 (two apples once)	All elements
FLUX.2 Klein	1.3 s	All correct	0 of 2 (two apples both times)	Canoe overlaps the dock
FLUX.1 Schnell	0.7 s	Brand correct, small text garbled	1 of 2 (two apples and two cups once)	Canoe lying on the dock
SDXL Turbo	4.1 s	Garbled	0 of 2	Two canoes, neither at the dock
Bria FIBO 1.5	8.9 s	"Yirgachefee", plus two lines of invented text	1 of 1	All elements

Latency is the median of four requests per model, measured from one client. The second composition run was not saved for Seedream 4, Seedream 5.0 Pro and Bria FIBO 1.5, so those have one sample. All 33 requests in the main run succeeded.

What stands out:

Text is mostly solved, except at the cheap end. Eight of the eleven models wrote all three lines of the label correctly. FLUX.1 Schnell and Bria FIBO 1.5 got the brand name right and garbled or misspelled the smaller lines; SDXL Turbo produced lettering that is not words.
Counting is where models differ. Only the three GPT Image models drew three apples and one cup in both runs. Qwen Image 3.0, FLUX.2 Pro and FLUX.1 Schnell got it right once and wrong once, so a single good image does not mean the model follows counts reliably. FLUX.2 Klein drew two apples both times.
The photoreal scene was easy for nearly everyone. Eight of eleven images had every element in a plausible arrangement. The failures were physical: a canoe merged into the dock, a canoe lying on top of it.
Latency spans nearly two orders of magnitude. FLUX.1 Schnell answered in under a second; Seedream 5.0 Pro took 28 to 51 seconds per image.

Text on packaging

GPT Image 2.5 Flare	GPT Image 2.5 Sunburst	Qwen Image 3.0

FLUX.2 Klein	Bria FIBO 1.5	SDXL Turbo

Three apples on the left, one cup on the right

GPT Image 2.5 Sunburst	Seedream 5.0 Pro	Bria FIBO 1.5

Qwen Image 3.0 (first run)	FLUX.2 Pro (first run)	SDXL Turbo

Cabin, lake and red canoe

GPT Image 2.5 Flare	Seedream 5.0 Pro	FLUX.2 Pro

Qwen Image 3.0	FLUX.2 Klein	SDXL Turbo

What the API actually returns

The models do not all answer a request the same way, and code that works with one can break on another:

Size is not always what you ask for. We asked for 1024x1024 every time. Seedream 4 returned 1280x1024 every time we checked. GPT Image 2 picks its own aspect ratio at about 1.57 megapixels: 1774x887 for the apples (twice), 1536x1024 for the lake, 1312x1199 for the coffee bag. Every other model returned 1024x1024.
Some models return a link instead of the image. GPT Image, Qwen Image, FLUX and SDXL Turbo put the image in b64_json. Seedream 4, Seedream 5.0 Pro and Bria FIBO 1.5 return a download URL in url instead, and still did when we passed response_format="b64_json". We did not test how long those links stay valid, so download the file straight away.
The format differs too. FLUX, SDXL Turbo and the Seedream models returned JPEG; GPT Image, Qwen Image and Bria returned PNG. Check the file's first bytes rather than assuming an extension.

Code that handles both response shapes:

import base64
import urllib.request

from openai import OpenAI

client = OpenAI(
    base_url="https://api.quicksilverpro.io/v1",
    api_key="YOUR_QSP_KEY",
)

result = client.images.generate(
    model="gpt-image-2.5-flare",
    prompt="Flat vector illustration: three red apples on the left, one blue cup on the right, plain white background.",
    size="1024x1024",
    n=1,
)

image = result.data[0]
if image.b64_json:
    data = base64.b64decode(image.b64_json)
else:  # Seedream and Bria return a download link instead
    data = urllib.request.urlopen(image.url).read()

with open("apples.png", "wb") as f:
    f.write(data)

Which one to use

GPT Image 2.5 Flare if the image has to match the prompt: correct text and correct counts in every run, at $0.018 per image and about 11 seconds. Sunburst gave the same accuracy here, more slowly, and added a line of text we did not ask for; GPT Image 2 is cheaper at $0.01 but slower and does not keep the size you request.
Qwen Image 3.0 or FLUX.2 Pro for good text and photoreal scenes in five to nine seconds, if you can retry when a count comes out wrong.
FLUX.2 Klein or FLUX.1 Schnell when speed and volume matter more than precision: drafts, thumbnails, many variations to choose from. Klein even got the label text right, in about a second.
Seedream 5.0 Pro produced accurate, natural-looking images, but at $0.07 and 28 to 51 seconds per image it is the most expensive and slowest model in this test.

The whole test, about 50 images including reruns and checks, cost about $1.45 at QuickSilver Pro prices on 2026-10-20.

Limits of this test

One or two images per model per prompt is a very small sample: the composition prompt showed that the same model can get it right on one run and wrong on the next, so treat every cell in the table as one observation, not a rate. Quality was judged by one person looking at the images, and "looks natural" is a matter of taste. We used default settings only; several of these models accept extra parameters (quality, seeds, prompt rewriting) that we did not try. Latency was measured from one client on one day, and in the first run all eleven models were working at the same time. Run your own prompts before choosing: every image request appears in your dashboard with its cost.

For setup in other languages and SDKs, see the quickstart and the model list.

I built CronBox: a local-first menu bar scheduler for scripts and coding-agent tasks

xiun xiao — Mon, 01 Jun 2026 09:31:22 +0000

I have a lot of small scripts that are useful only on my own machine: cleanup jobs, sync tasks, backups, local reports, quick data pulls, and lately a few coding-agent tasks.

Putting those on a server felt heavier than the problem. Plain cron or launchd works, but it is not very pleasant when I want to browse available scripts, attach JSON args, check whether a job is still running, or read stdout/stderr after the fact.

So I built CronBox: a local-first macOS menu bar scheduler for scripts and coding-agent tasks.

What it does

CronBox scans folders for executable entry scripts, lets you run them manually, and lets you schedule them as recurring cron jobs or one-shot runs.

It keeps the useful operational bits in one place:

script directories and selected entrypoints
aliases, cron expressions, timezones, JSON args, and environment variables
run history
live stdout/stderr logs
macOS notifications when scheduled jobs complete
skipped runs when the previous run for the same schedule is still queued or running

The main window can be closed while scheduled jobs keep running from the menu bar.

Why this exists

I wanted something between two extremes:

cron / launchd: reliable, but not friendly when iterating on local scripts
server-side job runners: powerful, but too much infrastructure for personal machine tasks

CronBox is meant for the messy middle: local automation that you actually want to inspect and adjust.

CLI examples

cronbox add ~/scripts
cronbox add ~/scripts --include daily-report.sh
cronbox schedules add ./daily-report.sh "0 9 * * *" --tz Asia/Shanghai
cronbox schedules add ./reminder.sh "* * * * *" --once
cronbox run ~/scripts daily-report.sh --args '{"date":"today"}'

It also has helpers for creating local Codex and Claude Code task scripts in the default ~/.cronbox workspace.

Install

The current install path is macOS:

curl -fsSL https://raw.githubusercontent.com/xiaoxiunique/cronbox/main/scripts/install-macos.sh | bash

Stack

CronBox is built with Tauri 2, Vue 3, TypeScript, and Rust. It is MIT licensed.

Website: https://cronbox.dev
GitHub: https://github.com/xiaoxiunique/cronbox

I am still polishing packaging and the coding-agent task workflows. I would be interested to hear how other people handle local scheduled scripts: do you prefer a GUI/menu bar tool, or do you keep everything in cron/launchd?