Elyra 0.9.53: Gemini 4 Argon, and Asking Each Model What It Can Do
Gemini 4 Argon is now Elyra's Google default. Thinking levels now come from each model's own capabilities instead of name patterns, Vertex is generated from models.dev, and economy mode stops trusting the word batch.
Google released Gemini 4 Argon this morning. By this afternoon it was Elyra's default for Google. That part was quick. Making sure Elyra talks to it correctly took longer, and that work is most of this release.
The headline: Argon is the new Google default
If you use Elyra with a Gemini API key or Google Vertex, new sessions now start on gemini-4-argon instead of gemini-3.1-pro-preview.
Gemini 3.1 Pro Preview Gemini 4 Argon Input / output $2 / $12 per million $2 / $10 per million Cache read $0.20 $0.10 Context 1M 1M Max output per response 65,536 32,768 (Gemini API), 65,536 (Vertex)
Output is a bit cheaper and cached reads cost half as much. Long coding sessions are mostly cached reads, so they get noticeably cheaper. It is also the first Gemini default in a while that isn't labelled "preview".
The one thing to know: on the Gemini API, Argon caps a single response at 32,768 tokens, half of what 3.1 Pro allowed. For most coding turns that makes no difference. If you regularly ask for very long single answers, Vertex keeps the 65,536 limit. To stay on 3.1 Pro:
{
"defaultProvider": "google",
"defaultModel": "gemini-3.1-pro-preview"
}
Existing sessions keep the model they were started with.
The real story: every Gemini model thinks a little differently
Since Gemini 3, you control how hard Gemini thinks with a thinkingLevel: minimal, low, medium or high. Elyra maps its own /thinking levels onto these. The catch is that not every Gemini model accepts every level. Google's documentation has a table, and it isn't uniform:
Model Levels it accepts Gemini 4 Argon low, medium, high Gemini 3.8 Flash low, medium, high Gemini 3.6 Flash minimal, low, medium, high Gemini 3.1 Pro Preview low, medium, high Gemini 3.1 Flash Lite Image minimal, high
Until now, Elyra decided which level to send by looking at the model's name. Anything matching "gemini-3 something flash" was treated the same way. That worked while the Gemini 3 family behaved uniformly, but it doesn't any more:
Gemini 3.7 and 3.8 Flash were sent
MINIMAL, which they reject. They received it whenever thinking was off, and that is the default for many users.Gemini 3.1 Flash Lite Image was sent
LOWandMEDIUM, which it doesn't support.Gemini 3.1 Pro was sent
HIGHwhen you asked for medium. That isn't an error, but it is more thinking, and more cost, than you asked for. The rule dated from Gemini 3 Pro, which really did support only low and high.The
gemini-flash-latestaliases fell through to the Gemini 2.x path entirely and were sent token budgets instead of levels.
And Argon? Its name starts with gemini-4, which matched none of the patterns. The first version of Argon support would have sent it Gemini 2.x budgets, including "budget zero" to turn thinking off, something Argon cannot do. We caught that before shipping. Still, it showed the problem clearly: guessing from names breaks with every new generation.
How it works now
Instead of guessing, Elyra now asks. models.dev, the catalogue Elyra builds its model list from, records which levels each model accepts:
"gemini-3.8-flash": {
"reasoning_options": [{ "type": "effort", "values": ["low", "medium", "high"] }]
}
When the model list is generated, each Gemini model gets its own map of which levels it supports. If you ask for a level the model doesn't have, Elyra moves you to the nearest one it does. If a model can't turn thinking off at all, "off" becomes its lowest level.
In practice, with /thinking minimal:
Model Before Now Gemini 3.8 Flash MINIMAL, rejected LOW Gemini 3.6 Flash MINIMAL MINIMAL (unchanged, it supports it) Gemini 4 Argon — LOW
And /thinking medium on Gemini 3.1 Pro now sends MEDIUM.
Of the 40 Gemini models with thinking, 24 send exactly the same requests as before. The other 16 now send something the model accepts. When Google ships Gemini 4.1, this should work without anyone having to write a new name pattern.
A note on honesty: these changes follow Google's documentation and models.dev, and a test checks every Gemini model against them, but we haven't run them against Google's live API ourselves. If you see a 400 error from Gemini,
/bugsends us a report in about ten seconds.
Google Vertex catches up
Most of Elyra's model list is generated automatically. Google Vertex was the exception: a short list written by hand, which had quietly fallen behind. It stopped at Gemini 3.1 Pro, while Google had shipped 3.5, 3.6, 3.7 and 3.8 Flash.
Vertex now comes from models.dev like everything else. The list grew from 14 to 21 models, including Argon and the whole Flash series. Older models that models.dev no longer lists (Gemini 1.5, 2.0 and 3 Pro Preview) stay available, so a project config that pins one of them keeps working. Nothing was removed, and nothing changed price.
Batch models, under two names
This part is for anyone who uses /goal with a budget and goalBatchModels turned on. In that mode, Elyra switches unattended goal work to half-price "batch" variants of a model. They are slower, but cheaper, and an unattended loop doesn't mind waiting.
Two things had gone wrong.
Vercel AI Gateway uses a different name. OpenRouter writes batch variants as model:batch. Vercel AI Gateway just added 50 of its own and writes them as model-batch. Elyra only recognised the colon version. That meant two problems: the gateway's batch models could win interactive turns because they were cheapest, which is exactly what should never happen to a turn you are waiting on, and economy mode could never find them. Elyra now recognises both spellings.
"Batch" doesn't always mean cheaper. While checking the batch models, we found five on OpenRouter where the batch variant costs more:
Model Normal input Batch input moonshotai/kimi-k3 $0.73 $2.28 z-ai/glm-5.3 $0.079 $0.45
OpenRouter sometimes prices the normal model at one underlying provider and the batch variant at another. Economy mode trusted the word "batch" and would happily have tripled your input cost.
The rule is now strict: Elyra only switches if the batch variant costs no more on any price component (input, output, cache read, cache write) and less on at least one. Comparing a single total isn't enough. GLM 5.3's batch variant is cheaper on output, but a coding turn is mostly input, so in practice it costs more. Five swaps are now blocked, and the other 121 work as before.
Behind the scenes
While preparing this release, we also ran the full test suite and found eight tests that had gone out of date without anyone noticing. Some pointed at models that providers had retired. Three only passed while Elyra's version number was below the one published on npm. None of them were bugs in Elyra itself, but they show that the release process doesn't run tests. That is on the list.
Upgrade
npm install -g @elyracode/coding-agent@latest
or
elyra updateThen start a new session with Google and try:
/thinking minimal
/model gemini-3.8-flash
Before this release, that combination would have been rejected. Now it just thinks a little less.