Patch Better Auth today; the rest of the week deleted code you wrote by hand

Better Auth is my first pick for serious apps on Postgres because your users live in your own database and cost nothing per user. The price of that is this week: on 3 November the project published twelve advisories at once and shipped the fixes in 1.7.16 (1.8.0-beta.5 on the beta line). One is critical, two are high, eight are medium and one is low. Better Auth's own team says it now runs frontier models over its code for security review, which explains the volume: 39 advisories this year.

Who is exposed, in plain words. Most of the twelve only hit you if you turned on the plugin concerned:

• Critical, CVSS 9.1, @better-auth/expo: a public endpoint would sign any value a caller gave it with the app's secret, the same secret behind email-verification links and the cookie cache. If you ever registered expo(), assume someone could have forged a signed value.
• High, the phone-number plugin: a number could be claimed before it was verified.
• High, the Electron plugin: desktop sign-in could return the auth secret and the social client secrets, and skip two-factor.
• The ones that hit a plain Postgres app with email and OAuth: an OAuth provider sending email_verified as a string (Cognito's userinfo is the named example) was treated as verified; email-change links stayed valid after the address changed hands; and "sign out everywhere" could miss a session cached in Redis or KV.

What to do, in order. Bump better-auth and every @better-auth/* package to the same version, 1.7.18 (1.7.17 and 1.7.18 fixed more session and Expo state bugs), and redeploy. Then:

• if expo() was registered, rotate the app secret, knowing that it logs everyone out;
• if the Electron plugin ever ran, rotate everything, social client secrets included;
• delete phone numbers saved without verification, because the patch doesn't;
• if you use the Stripe plugin, look for Stripe customer ids linked to more than one user;
• add set-phone to any custom admin access-control statements, or phone edits break.

Never run anything below 1.7.16.

Against Cognito. This is the trade, stated plainly: with Cognito, AWS patches the service and you ship nothing. With Better Auth, you own the library and its Tuesday afternoons. I still take that trade for a serious app, because Cognito's limits (no organisations, a second user store) cost more over a project's life than an upgrade a month. If you want Better Auth without the patching, Neon's managed Better Auth already runs 1.7.16 and needed nothing from its users. That's the strongest argument for it I've seen.

My verdict: no change to my pick. Upgrade to 1.7.18 today, rotate the secret if you used Expo, and put Better Auth's advisories feed in front of whoever owns your dependencies.

My data lake is S3, Glue and Athena, and I call it "the lake that works, not amazing". The not-amazing part is Hive-style Parquet: you hand-manage partition folders, small files pile up, nothing can be updated or deleted, and a second way to query the data means a second copy of it. Iceberg fixes most of that, and it's been on my list for months. What stopped me was the migration: one pipeline per table.

What shipped on 4 November. S3 Tables now migrates a Glue-registered Hive Parquet table into a managed Iceberg table as a job: Start, then Sync as many times as you like (only changes are copied), then Complete, when the new table becomes writable. The old table keeps serving the whole time. On the way it converts types, recompresses Snappy to ZSTD and compacts small files to 512 MB. It's in 10 Regions at launch, Sydney included.

What it costs in Sydney.

The conversion itself is free: you pay for the data copied, and $2 per million source objects on each sync. The trap is the monitoring fee on a table of tiny files: a million objects cost $25 a month, as much as the data. Compaction should bring that count down, but count your objects before you start; the compatibility report lists every one.

Gotchas, each with its fix.

• Lake Formation tables aren't supported. Check which databases are governed before you plan.
• Same account and Region, Parquet only. ORC, Avro, JSON and Hive ACID tables need an Athena CTAS first.
• A sync fails any source object that was overwritten. Keep writes append-only during the migration.
• Your partitioning comes across as it is. The second-index pain needs a second step: partition transforms such as day(ts) and bucket(N, id), and sort or z-order compaction.
• Writers must move at the end. Sync, pause writers briefly, sync once more, Complete, then point Athena and your jobs at the table bucket.

DuckDB, which I pair with Athena, reads S3 Tables through ATTACH … ENDPOINT_TYPE s3_tables, so the laptop half of my setup survives. IaC creates the table bucket, namespace and role; the migration itself is a CLI or SDK call, which is right for a one-off job.

This is how I'd run it for a client: one table that hurts, not the crown jewels, synced for a week next to the old one, with Athena queries compared on both before anyone flips a writer.

My verdict: worth a pilot on one non-critical table. It removes the migration project that kept me on Hive, in Sydney, for about 15% more storage.

Decision models, which return a probability per option instead of a paragraph, are the paradigm shift I keep pointing at: they make AI reliable in software without paying for more intelligence. Last week's edition showed them reading images. This week the field got wider.

Sarvam Prism (3 November). An Indian lab's decision model, a LoRA on its 105B model, with Apache 2.0 weights. You send a state and typed questions (yes or no, pick one, a score) and get a probability for each answer in one pass, timed by Sarvam at 44 ms on a B200. Sarvam claims the answer never flips when you shuffle the options, which is exactly the bug that makes prompted labels untrustworthy. On Sarvam's own average of three indices it scores 71.8, ahead of Perplexity's Decider v1.2 at 68.0 and Jev 1.14 at 64.5. Baseten's models, my pick, aren't in that table, so there's no like-for-like comparison yet.

The catch is size. Hosted, it's ₹4 per million input tokens with free output, about $0.045 by my conversion, on Sarvam's API only, with no stated region or retention terms. Self-hosted, you're running the whole 105B base: about 106 GB of weights on one 120 GB FP8 GPU such as a B200 or H200, loaded with Sarvam's own script, not vLLM. For an Australian client that's a dedicated, scarce GPU for a classifier. Baseten's MIT weights on a Sydney GPU remain the realistic way to keep a decision in Australia.

Perplexity's Decisions API can now search before it decides. Its web_grounding mode runs a search per question and returns the results it used, so a decision can rest on facts newer than the model, at $0.02 per million tokens for Decider v1.2 plus $0.001 per search. That's useful for "is this claim still true?" and dangerous for anything confidential: the question text goes to a web search. Never ground a question that contains client data.

The honest numbers from the field. Hightouch tested the design I'd recommend, a cheap decision model first and Opus only for the doubtful middle, and the headline says "over 4x cheaper". On its harder test it's 1.8x, on synthetic data, with thresholds tuned on the same set. Still a real saving, and still the right shape: let the decision model take the confident majority (78% in Hightouch's test) and pay for intelligence on the rest. Google's developer blog showed the same idea routing coding tasks between Gemini tiers with Jev, on a single run of 50 prompts.

When Microsoft, OpenAI, Perplexity and now Sarvam all ship the same new kind of model within six weeks, the idea is real. What isn't settled is who wins, and self-reported tables don't settle it.

My verdict: watching Prism, a real open-weight option with only its maker's numbers behind it. No change to my pick: Baseten for production, Jev to play with. Run your own labelled cases through all three before you believe any league table.

I keep AI Gateway on my watch list as the free layer in front of OpenRouter: caching, rate limits, spend caps, fallback, even from Lambda. Two changes this week make it more useful and slightly more work.

Aliases (4 November). An alias is a nickname for a list of models. Your code calls custom/support-fast; the gateway tries the first model in the list and moves down it on failure, or picks one per request in smart mode. You edit the list in the dashboard or the API, and the app never redeploys. Up to 100 aliases per gateway, 1 to 50 models each, all speaking the same request format. Core features cost nothing.

The timing matters: Workers AI retires 16 models on 20 November and answers HTTP 410 from then on. If an id like deepseek-v4-pro-0813 is hard-coded in a Lambda today, that's a deploy under pressure. With an alias, it's a dashboard edit. Put a model that isn't on Workers AI last in every pool, so a retirement can never take the whole alias down.

Authentication you can't turn off (3 November). Every new gateway must require a Cloudflare API token, and the setting can't be disabled afterwards. Before, an open gateway answered anyone who knew the account and gateway ids. Existing gateways are unchanged. This is the right default, with one sharp edge: the "AI Gateway Run" permission is account-wide, so one token reaches every gateway and every stored provider key. Keep it server-side, in Secrets Manager for a Lambda, and if two clients must never share keys, give them two Cloudflare accounts.

Gotchas. Aliases are documented on the REST path, api.cloudflare.com/…/ai/run with Authorization: Bearer and a cf-aig-gateway-id header, while provider-native URLs on gateway.ai.cloudflare.com take cf-aig-authorization. Don't assume aliases work on the OpenAI-compatible endpoint until you've tested it. Alias edits propagate with a delay, so a switch isn't instant in an incident. And Pulumi and Terraform manage the gateway and its authentication but not aliases, which live in the API for now.

Against OpenRouter. The two stack rather than compete: alias, then OpenRouter model, then provider. OpenRouter's rebuilt Auto Router (also this week) picks a model for you on its own scoring; Cloudflare's alias picks from a list you wrote. I prefer the list I wrote.

My verdict: no change, still watching, but this is the week to move hard-coded model ids behind an alias, before 20 November does it for you.

Durable Objects are my referee for live, shared state, and the code that calls them has always carried a little tax: a retry loop with backoff for "object restarting" and "moved machine" errors, plus a nagging doubt. When a connection drops mid-call, did the method run or not? Retry, and you might add the item to the cart twice.

What changed on 5 November. The runtime now retries a call that fails before it reaches the object: up to four more attempts within 10 seconds, with backoff and jitter, on by default with no flag. For the dropped-connection case, the retry carries the same request identity and the object refuses it if the first attempt arrived. So the default is "retry, but never twice". If a method is idempotent, setting a quantity rather than adding one, you can mark it with retryable() from cloudflare:durable-objects, and then it may run again. Per stub, retry: { maxRetries, timeoutMs } tunes or disables it. You need Wrangler 4.158.0 or later for the new API; the default needs nothing.

What it doesn't retry: errors your own code throws, overloaded errors (rightly: retrying an overloaded object makes it worse), HTTP 500s, calls with streams, pipelined calls and stubs you received over RPC. If those matter, they're still yours.

This connects to last week's item: deploys now defer code updates, and calls that hit an object mid-restart now retry by themselves. Deploying a Worker full of Durable Objects is quietly becoming a non-event.

Gotchas, each with its fix.

• Your loop stacks on theirs. Three attempts of yours become fifteen. Set maxRetries: 0 on stubs where you keep a loop, or cut your loop down.
• retryable() on the wrong method doubles a side effect. Only mark methods that set absolute values or check an idempotency key stored in the object.
• A method that called an outside API, then lost the connection, will call it again if it's marked retryable. Pass that API an idempotency key.
• Ten seconds is the window. For work that must survive minutes, use an alarm or a queue, not a retry.

Billing for retried attempts isn't stated on the pricing page. At $0.15 per million requests after the first million, it won't matter unless something retries in a storm, and then you have a bigger problem.

On AWS, the closest equivalent is SQS redelivery, which promises at-least-once and makes every handler prove it's idempotent. Cloudflare took the other side: retry only what never arrived, and block the duplicate. For a referee, that's the right side.

My verdict: no change to my pick, one less thing to write. Remove or shrink your retry loops, and mark only truly idempotent methods.

My stack puts Workers at the edge and the business logic on AWS, and tracing across that line has been ugly. CloudWatch only took OpenTelemetry traces signed with SigV4, so a Worker, a CI job or a SaaS webhook needed a collector, a signing proxy, or AWS access keys stored at the edge. All three are worse than the problem they solve.

What shipped on 3 November. The X-Ray OTLP traces endpoint now accepts an API key in an Authorization: Bearer header. The key is an IAM service-specific credential for xray.amazonaws.com: it belongs to an IAM user, it can only write spans to /v1/traces, and it can't read anything or call any other API. Each IAM user holds two, so you rotate without downtime, and revoking takes about 5 minutes. It's GA in every commercial Region with the endpoint, Sydney and Melbourne included. Cloudflare's Workers can already export traces to an OTLP destination with custom headers, in JSON, which X-Ray accepts, so in principle a Worker can now post spans straight to xray.ap-southeast-2.amazonaws.com. Send a test span before you trust it.

What it isn't. Traces only: there's no bearer option for OTLP logs or metrics, so my logs advice stands (CloudWatch for what you alarm on, Firehose to S3 for the chatty bulk). Transaction Search must be on first, and spans are billed as its ingestion, $0.35 per GB in us-east-1; the pricing page doesn't publish the Sydney rate. AWS itself still recommends SigV4 with short-lived credentials where you can sign. That's correct: this is for the places you can't.

The risk is the key itself. It's long-lived and static, and it never expires unless you say so. A leaked key lets anyone push spans into your account and run up the ingestion bill. So:

• create it with --credential-age-days and enforce a maximum with an IAM condition or an SCP;
• one IAM user per integration, so one leak is one revocation;
• store it as a Worker secret or in Secrets Manager at creation, because it can't be read back;
• alarm on CloudTrail events for bearer-token calls.

Creating it through Terraform puts the secret in state, and the provider has an open issue on that resource, so I'd create it with the CLI and keep only the IAM user in code.

My verdict: worth a pilot for anything outside AWS that should trace into CloudWatch. Medium risk, all of it in how you handle a static key.

A long-running agent on Lambda has a silly cost: every turn uploads the entire conversation again. At 40 turns and 150K tokens of history, that's a big JSON body that the API re-validates and re-tokenizes each time, and time to first token grows with the session. Prompt caching already cut the token bill on those old turns; it never cut the upload.

What shipped on 2 November, as a beta. Message threads keep the conversation on Anthropic's side. The first request creates a thread with the full history, system prompt and tools; each later request sends only the new messages plus the previous message id. The request stays a few KB however long the session gets.

What it doesn't do, which the headlines skip. It doesn't save tokens: Anthropic says plainly that threads change neither prices nor rate limits, and caching inside a thread still needs cache_control. You pay the same, and get the answer sooner. And it's fragile by design:

• a thread expires 5 minutes after its last request, and lives an hour at most. After that, a continue returns 404 thread_not_found and you resend everything;
• each message id can be continued once, so concurrent invocations on the same session collide;
• the system prompt, tools and model are fixed when the thread is created;
• ZDR and HIPAA organisations can't use it at all, and compaction, Batches and token counting don't work with it.

On Lambda, that means you still keep the full history yourself, in DynamoDB or S3, plus the last message id per session, and you serialise turns per session. The thread is an optimisation on top of a design that works without it.

Where it runs, and where it doesn't. The Claude API, Claude Platform on AWS, Google Cloud and Foundry. Not Bedrock, and not OpenRouter, which are the two routes I'd actually use for a client: Bedrock because it keeps Claude's data in Australia, OpenRouter because it fails over across providers. A thread fails over nowhere. OpenAI's equivalent, previous_response_id, survives idle gaps because it stores responses for 30 days by default, which is the opposite trade on retention.

My verdict: watching. A real latency win for very long sessions on Anthropic's own API, with no saving on the bill and no Australian route. Come back when it reaches Bedrock.