Simon Willison has released version 0.35 of llm-gemini, the plugin that connects his command-line tool LLM to Google's models. The reason: support for Gemini 4 Argon, which Google opened up the same day via its API and to anyone on the hundred-dollars-a-month subscription plan.
What happened
The usual ritual: Willison asks the model for a pelican riding a bicycle drawn in SVG, at all three effort levels — low, medium and high — and all three come out well. He notes that Google has a solid record here, and that it's the only lab he knows of whose staff have deliberately worked on SVG. The high-effort illustration cost him 17.166 cents.
The pricing numbers, which are what interest me:
- At launch, two dollars per million input tokens and ten per million output.
- That puts it level with GPT-6 Sol. Opus 5.5 charges twice as much for the same thing; Fable 5.1 and GPT-6 Astra, five times as much.
- On 1 December the price doubles. From then on, Argon costs the same as Opus 5.5.
- On Artificial Analysis, which publishes the total cost of running its full suite with each model, Argon lands at 2,407 dollars: close to GLM-5.3 and well below the latest from OpenAI, Anthropic and Meta. Even at double the price it will still sit a touch under GPT-6 Astra.
And one aside that says a lot about the moment we're in: he tidied up the comparison chart with ChatGPT because one of the data boxes was overlapping another. He checked the figures afterwards.
Why it matters
The key line in the original post deserves a slow read:
Prices like this aren't really comparable these days since what really matters is how many tokens a model takes to achieve a goal within an agentic harness.
In day-to-day terms: price per million tokens barely tells you anything now. What you pay at the end of the month is price per token multiplied by tokens consumed, and that second part varies hugely between models. A cheap one that goes round five times before getting it right costs you more than an expensive one that nails it first time. That's why the Artificial Analysis figure — total cost to complete the same suite — is more useful than any tariff table.
If you run something that calls a model in production, two concrete jobs come out of this:
- Measure cost per task, not per token. Cost per invoice processed, per ticket classified, per case resolved. It's the only number that survives a model swap. If you haven't instrumented it, today's a good day: the API itself returns per-call usage in the response metadata.
- Put 1 December in the diary. Any profitability sum you do with Argon over the coming weeks is wrong by a factor of two from that date. This isn't small print: it's an announced increase with a name and a day attached.
One detail I like about llm-gemini: same-day support, in a plugin maintained by one person. A new model stops being a three-week integration and becomes changing a string. That's what makes portability between providers real rather than a paragraph in a proposal.
What doesn't change
A model drawing lovely pelicans doesn't predict that it will read your delivery notes properly. Willison's test is a fun and honest thermometer — he says as much himself — but it has been circulating for years and the labs know it: once a lab is boasting about its pelicans, the test has stopped being independent. Textbook Goodhart.
Nor does it change that a public benchmark figure is a figure for that benchmark, not for your workload. Argon looks good on total cost there; on your case, with your prompts, your tools and your retries, it may land somewhere else. And a launch price is exactly that, a launch price: we already know it expires in December.
Our take
What bothers me here isn't the increase, it's the shape of it. Launching at half price with an expiry date is an acquisition promotion, and acquisition promotions work because moving provider is expensive. By the time December arrives, anyone who has built their agent chain on Argon will think twice about rebuilding it. It isn't evil: it's the same playbook as cheap first-year hosting. But it's worth calling it what it is and not mistaking an offer for a trend.
That said, announcing the rise three months ahead is far healthier than slipping it into a documentation note. I'd rather have a provider telling me "this goes up on the 1st" than one who tells me in the invoice.
We've seen the pattern already this autumn with the GPT-6 and Opus 5.5 price cuts: tariffs move every few weeks, and whoever ties their architecture to one specific model wears every swing. What I'd do — what I do — is keep the model call behind my own layer, with the model name in configuration, and a suite of twenty or thirty real cases with their expected output. Switching provider becomes an afternoon of testing rather than a project.
This is exactly what we run into when someone asks us to put a model inside a business process: the conversation starts with which model is best and ends, every time, with how many times you have to repeat the call because the input data came in dirty. That's where the money goes, not in the tariff.
The source, pelicans and chart included, is on Simon Willison's blog.
Any questions, tell me and we'll go through it.
Best, Vicente.