The price per token is the wrong number, and three vendors showed it this week

What happened

On 26 October, OpenAI shipped GPT-6.1 Terra, the third step on its ladder: Astra at $10 / $50 per million tokens, Sol at $2 / $10, Terra at $1 / $5, Luna at $0.10 / $0.50. Its predecessor, GPT-5.6 Terra, cost $2 / $12. It's GA on the API, on Bedrock, in Copilot and on OpenRouter, with a 1.05 million token context. It isn't frontier: 51 on the Artificial Analysis index leaves it one point outside the top ten. I'm covering it because that's about where most production features live, and because this is the week the index moved to v5.

The numbers that matter

Scores and cost per task are from the Artificial Analysis leaderboard, index v5:

Against Sonnet 5.5, the case is easy. Terra at max matches Sonnet at xhigh for about a quarter of the money, and Terra at high matches Sonnet at high for about a sixth. Close, not equal: Sonnet at max is still 3 points above anything Terra reaches, at ten times the cost.

Now the part OpenAI's price sheet hides. Sol costs twice as much per token and only 32% more per task at max, for 4 more points. So Terra must be burning about one and a half times the tokens (my inference from those figures). Further down, Sol at medium scores 46 for $0.36, and Terra needs xhigh to reach 45 for $0.40. At the same spend, the dearer model wins. Terra earns its place in high-volume work at the low end, where $0.26 a task is enough. If reliability is what you're buying, and it usually is, I'd test Sol first.

Gotchas

• No Australian route. From Sydney, Bedrock reaches Terra only through the Global profile, which can process anywhere. OpenAI's Australian setting stores data here and doesn't process it here. Sonnet 5.5 has an AU profile at $2.20 / $11. That alone decides it for any client whose data must stay here.
• The default effort is medium, which scores 38. Set reasoning.effort yourself, and compare models at equal scores, not at equal settings.
• Above 272K input tokens, the price jumps to $2 / $7.50. The 1.05 million window isn't the headline price.
• It takes more liberties. OpenAI's own safety addendum has Terra taking unauthorised actions in 13.75% of one evaluation, against 1.25% for Sol. For agents, use least-privilege tools and approval gates on writes.
• Zero data retention on OpenRouter means Azure EU, at $1.20 / $6. And Terra Pro has the same token price but spends far more tokens.

How I'd wire it for a client

Split by data. Client data that must stay in Australia stays on Sonnet 5.5 through Bedrock's AU profile, and you accept the bill. Everything else runs through OpenRouter with AI Gateway in front for spend caps, with Terra and Sol tested side by side on the client's own prompts. Above a score of about 45, I'd expect Sol to win.

My verdict

Pilot, next to Sol. Medium risk, since it's a week old with no Australian route, and its numbers swing hard with effort. It doesn't change my pick for Australian data, and it makes "Sonnet by default" harder to defend everywhere else.

What changed

Until now, OpenRouter's default ranked hosts almost entirely by input price. About 77% of its requests go to models served by more than one host, so that default set the price and the quality for most of its traffic. Since 28 October, it scores each endpoint live on what a good answer costs: effective price (from measured cache hits and token mix), throughput, time to first token, rate limits, errors, and whether tool calls come back well formed. Traffic is shared among the hosts near the best score, and laggards keep a trickle so they can recover. It applies to every request that has no explicit sort or order, and you didn't get a vote.

Here's OpenRouter's own test, one week and 24 million requests of open models:

These are the vendor's numbers, and I'd want to see them on your traffic. But the logic is sound: a cheap token on a host that throttles you isn't cheap.

Why the cheapest host was never that cheap

Look at DeepSeek V4.1 Flash on the live endpoints list. There are about 38 of them, from $0.035 per million input tokens to $0.45, which is about 13 times apart. The cheapest serve fp4 quantization, and the block at $0.30 mostly doesn't say. So the old default could buy you more than a flakier host: possibly a different build of the model from the one you evaluated.

Gotchas

• Your bill can rise with no code change. If a client's budget is tight, set provider.sort to price, add :floor to the slug, or set the account default. Or keep the new router and cap it with max_price.
• provider.order and any explicit sort bypass the new router, so old pinned setups quietly miss its back-off. If you only want to limit the field, only and ignore keep the new algorithm choosing among what's left.
• It doesn't pin the build. The router optimises for cost and speed, not for the quantization you tested. Use quantizations: ['fp8'] with require_parameters: true, or name the host.
• Privacy defaults haven't moved. data_collection still defaults to allow. Send deny and zdr: true on client data. The candidate pool shrinks, and that's the point.
• Baselines from before 28 October are stale. Each request picks a host by weighted chance, so log which host answered, and pin one for evals. Chat stays sticky while the prompt cache is warm; one-shot jobs with a shared prefix don't, so pin those too.
• There's no stability policy for routing defaults. It changed once without asking, and it can change again. Pin explicitly where cost is critical.

This fixes a line in my own stack entry, which still says "weighted towards the cheapest". Vercel's AI Gateway shipped virtual models the same day, a stable ID with fallbacks you change without touching code, at no markup. That's a good answer to the same problem, for teams already there.

My verdict

No change: OpenRouter stays my default, and I'd keep the new router for anything user-facing. Low risk. For batch jobs, where nobody is waiting and you've tested the build, pin sort: price.

What happened

Google announced Gemini 4 Carbon on 28 October, a bigger sibling of Argon tuned for finding, exploiting and patching vulnerabilities. It went to "a subset of cyber defenders". Developers get it "as soon as possible", with no date. It isn't on the Gemini API's model or pricing pages, and it isn't on OpenRouter. I couldn't confirm a Vertex listing either. So whatever follows is about a model you can't call.

It also landed the same week Artificial Analysis rebuilt its index. Version 5 puts 60% of the score on private datasets, and it moved everything. The numbers in earlier editions of this report used the old scale, so don't compare across editions: Kimi K3.1 Pro was 55 in last week's edition and is 46 now. The gap between the best closed model and the best open one went from 3 points to 12.

Why it matters anyway

Carbon's list price is the same as Opus's, $4 / $20. It costs 23% less per task because it writes 29% fewer output tokens: 123,000 against 173,000 for a task on the index. There's the week's theme again. Two models at the same token price, and one is nearly a quarter cheaper to run. Google quotes an introductory $2 / $10 with no end date, which would roughly halve that $7.76 (my arithmetic: the index's cost uses the $4 / $20 list price). Don't budget on it.

The more useful line in that table is one you can buy today. Sol at max scores 55 for $1.27. That's a point above Sonnet at max, at about an eighth of the cost per task. Sol launched on 29 September, so that's context, not news, but the new index makes it hard to ignore. If you think, as I do, that reliability in software comes down to intelligence for now, the best deal in intelligence isn't this week's winner. Astra at max is the other one: 57 for $6.24, already cheaper per task than Carbon.

Gotchas

• Google's launch benchmarks are its own, run without the guardrails the shipped model will carry. Wait for the index to run it on a public endpoint.
• The Fairwind Program's page names Argon, not Carbon, as what it gives access to, and it asks for background checks and works through a Google Cloud account team. It isn't a side door for you.
• If you're on Argon, your bill doubles on 1 December. It's $2 / $10 until 30 November, then $4 / $20. At that price, its score of 50 is hard to defend.
• Nothing is stated for Australia. For data that must stay here, this doesn't exist yet.

What would change my mind

Carbon listed on OpenRouter or the Gemini API at a stated price, with a score that holds on the guarded model. Then it's a pilot on the day. Until then, it's a good chart.

My verdict

Watch. Medium risk, because neither access nor price is settled. Nothing changes in my stack, and if you want the frontier's economics today, test Sol.

What happened

On 26 October, Cloudflare published a detailed report on an incident on Workers AI. GLM-5.3 launched on 27 August with an advertised context of 1,048,576 tokens and a memory pool that held only 681,280. A prompt bigger than the pool was marked rejected, but a bug in SGLang's disaggregated serving, where prefill and decode run on separate GPUs, let the request carry on. It then read memory pages left behind by earlier requests. Those pages are never wiped between requests.

Result: 155 responses, over 13 days, contained data from other people's prompts. An outside researcher's report through HackerOne brought it to light, not Cloudflare's own monitoring. Once the incident was declared on 9 September, the model was offline within 38 minutes, and it came back fixed the same day. Cloudflare says it found no sign of deliberate exploitation. The public report came 47 days after that.

Read it carefully, in both directions

Don't overstate it. It's one model, and only prompts over 681,280 tokens, which almost nobody sends. If you never sent those to GLM-5.3 between 27 August and 9 September, there's no known exposure. Cloudflare also wrote an unusually honest post-mortem, with the cause, a timeline and its own mistakes, which is more than most vendors publish.

Don't understate it either:

• You can't check. The report offers no log query and doesn't describe notifying customers directly. SGLang's own post says this corruption leaves no error or log line. If you need certainty, ask Cloudflare in writing.
• The bug isn't Cloudflare's alone. SGLang says the race affects disaggregated deployments from v0.4.x through v0.5.21, with no backports. Other hosts run this engine, and none has said anything. I found no evidence either way on the hosts behind OpenRouter's GLM-5.3.
• Isolation isn't a line item. Page zeroing is still a draft pull request upstream, and Cloudflare's report offers no isolated tier to buy.

What the alternatives actually promise

What I tell clients

Zero data retention covers what a host keeps. It says nothing about what the GPU still holds when the next request arrives. So sort the data, not the models. Regulated or truly confidential data goes through Bedrock in Sydney. Anything else can use a shared host with zdr: true, and with prompts well under the host's stated limits, since the edge of a limit is where this one lived. Don't read this as "OpenRouter is safe and Cloudflare isn't". Nobody has shown that, and the same engine may sit behind a host you use.

My verdict

No change: Workers AI stays a skip for me, now with a data-isolation reason next to price and rate caps. Medium risk, and most of it is the class of bug, not this incident.

What happened

Six weeks after Jev opened the category, the price of a decision hit a penny. On 29 October, Baseten's lab released joey-1: a 2B model with open MIT weights that you send a state and typed questions (yes or no, a choice, a score), and it returns probabilities in one pass, with no generated text. It costs $0.01 per million input tokens, output free. Baseten's own example: 10 million tickets of 500 tokens a month is about $50. It's the third in a family, after elephant-1 (9B) and mammoth-1 (27B), which share one request shape you swap by name.

It isn't alone. Liquid's d1-2B weights appeared on 24 October under its own licence, and its LFM3 family followed on the 27th. Microsoft-Decision-1 went to public preview on 9 October, and AWS's Strands Decider 2B was out by 2 October. In W43 I said an idea copied this fast is real. A penny per million is what that looks like a few weeks later.

Cheap isn't the same as good

Base Labs' Hugging Face card has its own run of the Jev Decision Index: joey-1 63.3, Clef 61.71, Jev 1.14 60.7, and elephant-1 72.24. All vendor-run, so read them as a rough order. They flatter it. On the Decision Index's private tests, joey-1 scores 35.91, against 44.43 for Clef Flash and 60.26 for elephant-1, and only 15.25 on domains it hasn't seen. So this isn't level with Clef. And elephant-1's nine more points cost 3.5 times as much, at $0.035, which is still next to nothing. I'd start testing there unless your volume is enormous.

The same card lists an AUROC of 0.48 on a judge benchmark for safe agents. That's a coin toss, published by the vendor itself. So don't let joey-1 approve anything dangerous. I found no independent evaluation of any of these models, and nothing that tests how easily misleading text sways them.

Gotchas

• Hard limit of 16,384 tokens on Model APIs. Longer requests are refused, not truncated. Trim the state first.
• Low default rate limits: 15 requests a minute unverified, 120 verified or on Pro. Verify the account, and batch several questions into one request.
• No region list, and no sign of Sydney. Serving regions on the shared endpoint can change. For Australian data, self-host the weights on a GPU in ap-southeast-2. That's what MIT is for.
• The latest slug moves when Base Labs refreshes the weights. Keep your labelled test set and re-run it on every change, or self-host a pinned revision.
• Don't compare latencies across vendors. joey-1's 20 ms is Baseten's own figure, and Clef's 38.8 ms from W43 came from another setup.
• Untrusted text belongs in state, never in instructions. Add an abstain threshold and a human for anything consequential.

My verdict

Watch. Medium risk, and high for approvals or anything safety-related. Label 200 of your own cases and run joey-1, elephant-1 and Clef Flash against them. Open weights are still your exit, and now there's a second one.

What I should have told you in W43

Added to this edition on 2 November, after it first went out. On 14 October, TypeSafe turned on images for Jev, and in W43 I reduced that to a warning about experimental headers. That undersold it. A decision model that can look at a picture is a new tool for a whole class of jobs: is this parcel damaged, is an error on this screen, which team should get this form. And it isn't only Jev. Cloudflare's Clef takes images, and so does last week's joey-1. OpenAI's Decisions API does too, so this is a category, not a feature.

You send an image and typed questions, and you get probabilities back in one pass, with no text to parse. Above your threshold, you act. Below it, a person or a bigger model looks.

Side by side

The costs are my arithmetic. Only Cloudflare publishes how an image becomes tokens. TypeSafe doesn't, so its 1,000 tokens is my assumption, and one tester's real run came to about $0.11 per 1,000 screenshots with questions. Baseten's 394 comes from one screenshot in its docs. Clef's bigger models cost more: $0.154 per 1,000 for Clef-omni, which also takes audio and video, and $0.246 for Clef, which scores 58.1 at 1.18 s. Image speeds and scores are from Image JevBench, a beta benchmark and one person's project, so read them as a rough order.

The price isn't the point

For comparison, by the same arithmetic, 1,000 images of that size cost about $2.59 on Claude Sonnet 5.5 and $0.13 on Haiku 5.5, plus the output. So Clef Flash is about 66 times cheaper than Sonnet, but only about three times cheaper than Haiku. At these prices the bill rarely decides. What you're buying is a calibrated number you can set a threshold on, with no output to pay for or parse.

The one hands-on test I found shows why that matters. On 1,000 synthetic ticket screenshots, Jev 1.14 got 934 right. With a 65% confidence gate, 899 went through automatically, all correct, and the 66 errors all landed in the 101 sent for review. It's one author and synthetic data, but that's the shape of the promise.

Gotchas

• jev-latest got worse at images. It now points at 1.14.0, which scores 60.2 against 72.4 for 1.13.0 on Image JevBench. Pin a version, and test both on your own images.
• Jev images are off by default. Without the TypeSafe-Danger-Zone-Images: true header, the request returns 400, and TypeSafe says format and limits can change. Play with it, don't marry it.
• A Jev box always comes back, even when the thing isn't there. Ask a yes-or-no question first. One out-of-range image also fails the whole request, so normalise them first.
• Your gateway may not carry this. OpenRouter lists neither joey-1 nor Clef, and Vercel lists joey-1 as text-only. Call Baseten and Cloudflare directly.
• Words inside the picture can steer the answer. In DecisionRobust, an academic test, a planted instruction inside an image won 57% of the time on Jev 1.13 and 53% on OpenAI's Decisions API. Clef and joey-1 weren't tested. Never make one of these the only gate on anything consequential.
• Nobody has shown joey-1 on images. It has no image benchmark, and Baseten publishes no size limits or token rule. Measure usage.input_tokens yourself.
• Nothing is documented for Australia. For data that must stay here, self-host joey-1 or Clef in ap-southeast-2. Jev is closed, so it can't do that.

How I'd wire it for a client

Pick one job with a real cost, such as damaged-parcel photos. Label 200 of the client's own images, and run Clef Flash and joey-1 against them, and Jev 1.13.0 to see what you're missing. Set the threshold from those results, and send everything below it to a person. Clef Flash is my starting point, for its documented limits, its token rule and open weights you can leave with. joey-1 is the one to beat on price, once someone shows what it does on images. Every decision model, on every measure, is in Which decision model?.

My verdict

Pilot, behind a confidence gate with a review queue. Medium risk: it's all under two months old, with one beta benchmark between them. Jev has the best image score and the only bounding box, and it stays an experiment until TypeSafe takes it out of the danger zone.

What changed

Durable Objects used to apply a deploy on the spot. Every active object reset, in-flight requests touching storage errored, and every WebSocket dropped. My catalog's advice was blunt: don't deploy during a live event.

As of 30 October, on every Durable Object with no flag or compatibility date, a busy object keeps its current code until it hibernates (about 10 seconds idle), then wakes on the new code. If it never goes quiet, it's reset after 5 minutes by default; you can set anywhere from 0 seconds to 24 hours. Clients on the Hibernation API stay connected through the swap. An object runs one version at a time, so there's no double billing and no fee for this. Duration is only billed while an object is active.

The bug you just inherited

The old pain was loud. The new one is quiet: two versions of your code now run at once, for minutes, and a new Worker can call an object still on the old code. This is where a deploy will bite you:

• RPC between Workers and objects must work both ways. Add methods and optional fields first. Remove the old ones in a later deploy, after max_delay has passed.
• SQLite schema changes need expand and contract. Add first, make both versions tolerate both shapes, and drop later. Run migrations idempotently in the constructor. The docs give no recipe for this, so that's my advice, not Cloudflare's.
• Versions get skipped. Each deploy starts its own timer, and the first to expire jumps the object to the latest code. An object can go from v1 to v3, so v2's migration may never run on it. Make migrations cumulative.
• Emergency fixes need the flag. A security fix can't wait 5 minutes: deploy with --durable-objects-code-update-mode immediate. Rollbacks accept it too.
• Gradual deployments stretch the mixed period. Keep the compatibility rule for the whole rollout, plus max_delay.
• The strategy is per Worker, not per class, and doesn't carry over between deployments. You can't read it back from the API either. Keep it in the wrangler config under version control.

What it doesn't do

It's best effort. A Workers runtime update can still reset an object early, and there are no shutdown hooks. Objects on the standard WebSocket API, or holding timers or open outbound connections, never hibernate, so they sit there until max_delay and drop anyway, and they keep paying duration while they wait. Keep your client's reconnect logic. Use the Hibernation API and alarms if you want the benefit.

On AWS, API Gateway WebSockets have long kept connections through a Lambda deploy, because the connection lives in the gateway, but then all your state lives somewhere else, and in the auction example in my catalog that costs an order of magnitude more. That's still the trade, and this change tips it further toward Durable Objects.

The Pulumi and Terraform releases I checked predate this and don't expose the setting. The default should apply when the field is omitted, by my reading of the docs; I haven't tested it. If you need to override it through IaC, expect a wrangler step for now.

My verdict

No change: still my pick for live, shared, short-lived state, and a better one. Medium risk, not because of the feature, but because a mixed-version bug is now possible on every deploy and nobody opted in. Read your RPC surface this week.

What happened

Two things landed on 28 October around the same pain. AWS shipped the Durable Execution Telemetry Exporter for Lambda durable functions, at no charge, with a local read-only MCP server so an agent can query what happened. Temporal published a write-up of Serverless Workers on Lambda and Cloud Run. Don't mistake that one for a launch: Lambda workers went to public preview on 13 October, and I'd already skipped them in W43's window. What's new is the Cloud Run half and the combined pitch.

The exporter, which is the part I care about

When I covered durable functions in W43, I liked the model: per-step retries in plain code, inside the account, without hand-tuning SQS. But AWS keeps the history for 14 days by default and 90 at most. The exporter sends each step's status, timing, input, output and errors to one of 13 destinations: the function's log group by default, with no stack or IAM needed, or CloudWatch Logs, S3, DynamoDB, Aurora, Redshift, OpenSearch, EventBridge, Firehose, SQS, OTLP, HTTPS or a file. You bring the destination and pay for it. The TypeScript package also ships an optional CDK stack for Athena. It's in every region durable functions run in, and the Sydney price list carries them, at $8.70 per million operations, which settles what I left open in W43.

This is how I'd wire it for a client: start with S3 and Athena, redact first, and sample nothing at low volume. That's a one-afternoon change, and it answers "what happened to order 4417?" without opening a console.

Next to Temporal

The first two prices come from my catalog. Temporal's is my own arithmetic: at least 4 or 5 billable Actions per run, at $50 per million. I haven't checked Temporal's billing rules against this exact workload.

Temporal is a serious product, and as a workflow engine it's more mature than durable functions. But for a client on AWS, this adds a paid outside control plane, an IAM role that Temporal assumes in the client's account, mandatory Worker Versioning, and a preview. Temporal's Terraform module only covers that role. The provider has no resource for the worker configuration, so that step is CLI or console, and infrastructure as code or it doesn't exist. I keep it for the client who's already on Temporal.

Gotchas

• The exporter sends step input and output unredacted by default. That's personal data in your log bucket. Set content transforms before production.
• It can't see STOPPED or TIMED_OUT executions. Add an EventBridge rule on the status-change events.
• The log-group exporter's lines vanish at log level WARN or higher. Keep INFO.
• AWS doesn't say GA or preview on the announcement. The plugin is open source, so read what you install.
• Temporal on Lambda: the default 3-second timeout is too short, so use the docs' 600 seconds; and from a VPC, your worker still has to reach Temporal Cloud over the internet.

My verdict

Pilot for durable functions on multi-step jobs, as in W43, and now with Sydney settled and the history yours to keep. Medium risk: the product is new. One-step jobs stay on SQS and Lambda. Temporal on Lambda is a skip while it's in preview.

What happened

Last week I told you to hold Tailscale SSH because eleven findings were public and no fix had shipped. On 28 October, Tailscale released 1.104.4 on all platforms, with bulletins TS-2026-014 to 017, and a clear post on what happened. (Skip 1.104.3: it was internal only.)

Who was exposed

Tailscale's account matches what I said last week: exploitation needs a device already authorised on your tailnet, and SSH allowed by your policy. If you run plain Tailscale to reach private AWS resources, with Tailscale SSH off and no Serve, nothing here applied to you, and subnet routers were never in scope.

What's still open

By the Tailworm site's own tally, 1.104.4 closes findings 1, 2, 3, 5, 7, 8 and 11, plus the client part of 6. Three remain:

• Finding 4, egress through the pre-release app connector, is only partly fixed, on main and unreleased. Tailscale says stable app connectors aren't affected. Don't give pre-release connectors to users you don't trust.
• Findings 9 and 10 stay as they are: Tailscale calls them working as designed. Bypassing the Funnel check needs local admin, and TS_SERVE_ALLOW_ALL_INTERFACES is an opt-in. Don't set it, and keep local admin short.

What to do

1. Check every node: tailscale version must say 1.104.4 or later. The sources don't settle how clients auto-update, so look rather than assume.
2. On headscale, upgrade the server to 0.29.7 (30 October) as well. The server part of finding 6 lives there.
3. Where you don't need forwarding, set TS_SSH_DISABLE_FORWARDING=1 in the tailscaled environment and restart, even after patching.
4. Use check mode and non-root users in your SSH rules, in the policy file, under version control. Four bulletins in one release tell you SSH and Serve are the layers to keep small.

Credit where due: from report to fix took about four days (Tailscale dates the report 24 October, a day before I did), with a straight account of what happened. That's how I want a vendor I depend on to behave, and it's why this stays my default.

My verdict

No change. Tailscale stays my default, and the hold on Tailscale SSH comes off once your nodes are on 1.104.4. Low risk.