There's a failure mode in multi-server Laravel apps that never shows up as an error. It shows up as a customer asking why they got the same email three times. The cause is almost embarrassingly simple. Every server with a cron entry for schedule:run evaluates the whole schedule on its own. Each one asks which tasks are due this minute, gets the same answer, and runs them. Nothing coordinates between servers, because the scheduler has no idea the others exist. onOneServer() fixes that with a cache lock: the first server to start a task takes it, and the rest skip. The catch is that it's per task. The pull request behind Laravel 13.35 describes how people usually patch it: wrap the whole routes/console.php in a group. That works until someone adds a task outside the braces. The author's own phrasing was that it relies on everybody remembering it forever. A protection that depends on code structure and reviewer vigilance erodes silently, because an unprotected task behaves identically to a protected one on a single-server dev machine. 13.35 replaces the convention with a default. Schedule::alwaysOnOneServer() in your service provider covers every task, including ones defined after the call. What I'd actually spend time on is what it depends on. Closures without a name() are skipped silently, so they still run on every server with no warning, which is the exact symptom you were trying to cure. The lock lives in the cache, so a per-server file store means every server wins its own lock. And there's no per-task opt-out, so a schedule with real per-machine housekeeping shouldn't use the flag at all. The practical move is ten minutes of proof: grep your Schedule::call( closures, confirm the cache store, and log gethostname() from a before() hook on one real run. One hostname means it worked. The same release adds a clean way for long runInBackground() commands to stop during a deploy. That's a smaller change with the same shape: it only works if the command is written to be stopped. Full breakdown in comments.

There's a bug I keep seeing in AI features, and it never shows up as a bug. It shows up as a decision that was quietly wrong with full confidence. A moderation check flags a comment. Nobody asks how sure the model was. By the time the result reaches the if statement, a 51% guess and a 99% guess have both become the same true. The uncertainty didn't get handled badly. It got thrown away somewhere upstream, in a parsing step nobody examined closely, before your code ever had the chance to see it. I spent some time with a different approach this week. Jev, an AI model from TypeSafe, answers a typed yes/no question with a calibrated probability instead of text you then parse. The Decide with Jev course on Laravel News builds a content preflight checker around it, and the example makes the contrast concrete: a complete draft scores 0.96, a thin one that never gives a concrete step scores 0.02, and a genuinely mixed one lands somewhere that doesn't resolve to either. That mixed case is where it earns its keep. Instead of forcing it into true or false, the SDKs expose isTrue(), isFalse(), and isUncertain() with thresholds you set. Three outcomes instead of two, because the third one actually exists in the model's output. It also surfaced the cost, and it's real. You now have to decide what happens to the uncertain middle. Human review is the obvious answer, but not every feature can afford it at volume. And the threshold itself, whether 0.75 is the right line for denying a refund, isn't a technical default. It's a business decision about which mistake you'd rather make, and a boolean API let you avoid ever having to make it consciously. One honest caveat: the course is weeks old and the Laravel packages are unofficial. I found three independent wrappers published in the same short window. That's a sign of interest, and also of an ecosystem that hasn't settled yet. Full breakdown in comments.