I wished OpenAI and Anthropic IPOd already. They just try to outcompete each other by finding the most splashy headlines undercutting prices in unhealthy and unsustainable means long-term.
That may not matter that much, as even if you run a relatively strict policy about where you send the reply, you can still easily get bitten by external mistakes there: Because of the huge number of individually administered departments that might each become authorized recipient of such data, a malicious party only needs to find one suitably dangling DNS delegation to score a "…@attacker-controlled-subdomain.legitimate.example" mailbox. The sender would not be able to prevent this.. unless its regulatory oversight body is very patient about repeatedly delaying legitimate requests for seemingly-minuscule formal defects.
(Mentioning just for context. Probably not the mechanism at play here, Revolut would have tried to shift blame in the press release if it was.)
I think you missed the point - delivery of sensitive data should involve public key encryption of some sort and it should ideally be done through an application or website that's purpose-built for this.
It should be made impossible for someone at Revolut (and every other org) to deliver this data into the wrong hands by accident.
Public key encryption as in DANE already achieves what can be achieved given the constraints.
I have seen some purpose-built apps that use email for auth and then establish a different channel to exchange the documents. But that just nets the security properties that you already had with email.. just with some added methods of sideloading trojans past those pesky email attachment scanners. Turns out, you cannot just sprinkle some "encryption of some sort" magic on top of an already encrypted channel (which was inadequate in auth, not in confidentiality) and get a meaningful improvement from that. Instead, it subtracts from the already way too limited budget that people trying to get actual work done can spend on establishing who they are talking to through distinct comms channels. Not sure what the purpose of those apps even is, other than generating some $$ for the provider (in the most egregious case, Cisco).
Christ, ease off the condescension, I'm very obviously not talking about "sprinkling in" domain name authentication, but encrypting the data for an eligible recipient using a suitable root of trust.
You're discussing this as some inachievable science fiction that would require every employee to learn how to use gpg. In reality this could be achieved through a simple to use website.
In fact this is a solved problem. My doctor is not legally allowed to email me my own medical records, not even the most mundane blood test result. Instead they send them through the government-operated portal which employs suitable authentication and prevents any sort of transport-level hijacking.
There is no excuse to be using non-e2ee email for this in 2026. None.
What is the difference between making sure an HTTPs endpoint does not leak and making sure an IMAPs endpoint does not leak? I do not see much of a fundamental difference.
Except, it makes the user experience worse: I can certainly make it infinitely more tedious to open the document exchange site of $superimportantcompany on superimportantcompany.co (or was it .com? or .co.uk? or important-company-le.ai?), and spread out "my" inbox across 30 different sites and spend additional time navigating their unique interfaces to not just read, but also add each document into the appropriate local archive. But what have I gained in making it more likely that each correspondence is kept confidential between the only parties that should read it? Nothing beyond what I started with. Could have stayed with email, no?
I can see the appeal of mitigating part of the usability problem by pivoting straight to bundling up all thematically related messages into centralized repositories to limit the number of pseudo-mailboxes one has to maintain simultaneously, as done in the recent "everything medical related" cases. But someone would grab a full copy in the inevitable compromise, and that is a risk that should rather stay scoped to smaller groups of senders and/or recipients. It seems like a bad tradeoff to force every blood test of everyone into the danger zone for that, given that one could have instead spent 3% of the budget on.. merely policing away the DNS warts in public authorities (or, in the medical example, insurance companies) while keeping data custody unchanged.
The document exchange site isn't hosted by each individual company, that would obviously be ridiculous. There's only one and it's hosted by the government. I already said that in my previous comment but you chose to attack a straw man instead.
Perhaps not the server-side components, unless they directly link AGPL covered code there too. No one that I've seen seems to be asking for the server side parts, just the client parts so they can use the printers locally they way they want without hacking around.
Studio is fully release IIRC, it is that "external" part which is the issue.
The linkage between that and the client should be soft enough otherwise for the server side not to inherit the responsibilities of the client. Though if part of their claims attempting to defend their current position suggest that linkage is more direct, then they are taking aim at their own foot somewhat.
Even the simplest router that differentiates models between plan & execute will ensure that this is consistently followed. Folks have too high FOMO to choose themselves.
The breaking changes vs. Opus 4.8 are interesting [1]
1. Thinking on by default: On Claude Opus 4.8, requests without a thinking field run without thinking; on Claude Opus 5, the same requests run with adaptive thinking.
2. Disabling thinking is capped at high effort: You can still turn thinking off with thinking: {type: "disabled"}, but only at an effort level of high or below.
I love how there is a "Please do not discontinue gemini-2.0-flash[-lite], 2.5 is NOT an equivalent" from Feb 20th. Getting too attached to models is a smell.
It's not a smell. Why should these developers rebuild a core piece of their stack every few months. Switching out a model requires a new round of testing and validation when we should be able to rely on a piece of software the behave the same way since the last time we touched it.
If they were on open weights, at some point the provider would deprecate it, probably with worse notice
And self-hosting would probably have been more expensive unless they had massive volume: Deepseek V3.x would have been the comparable open weight model for the performance and isn't that cost effective until hosted across multiple nodes with large batch sizes
This is how development looks like for many years now, constant rewrite on the horizon. I think LLM development hype surpassed Blockchain and JS frameworks craze of decade ago.
Its almost a given considering how fast this field moves. Also, what kind of workflow structure would someone have that a single specific model is the only one that would perform acceptably?
Programs are tightly shaped to their dependencies and software frequently breaks when bumping a dependency versions. That's why we have package managers that are carefully built around lock files. Models should be thought of like a dependency, not just an endpoint to a workflow.
These are AI models designed to be non deterministic. If upgrading from GPT 5.5 > 5.6 breaks your entire workflow, you shouldn't be using AI to begin with
> Why should these developers rebuild a core piece of their stack every few months. Switching out a model requires a new round of testing and validation when we should be able to rely on a piece of software the behave the same way since the last time we touched it.
Because fuck you, that's way. /s
There's a massive amount of contempt from a lot of software businesses for their customers, and it's just getting worse with LLM models.
In the post the issue is performance. Are you saying that getting too attached to performance is a smell? That sounds very odd.
It's not because a model performs better in some applications (often by fine-tuning to get better scores at specific tests) that it is better across the board or that we have to believe the company releasing the model with a high number 3 > 2 so that it is commonly accepted as better.
Pushing the reasonnning further: f you need an Opus level performance then not accepting GPT 3 isn't a smell.
The smell is about folks being attached to the same model because they're used to it. Just like any UI change in an app that one uses everyday is annoying.
What's often missing is the actual engineering. If you have evals for your use case, you use these to adjust to the new model. DSPy has great prompt engineering constructs it ships with.
The smell is all about vibing, where a model feels better because the structure of the answers is more familiar to a person, instead of engineering where given constraints and input/outputs one is using/bending the system to fulfil the requirements.
the 1.5 and 2.0 flash models were absolute beasts. They were very cheap, and _very_ fast. We contemplated moving some of our fine tuned workloads to them because we would have gotten very substantial total latency reductions for our workloads.
However, they are aggressively deprecating them (OpenAI is as well), and replacing with newer models. These newer models are all reasoning models, and importantly, only bear the flash name. They are not fast. And they are very expensive!
We have benchmarks for our use cases, and every generation after Gemini 2.0 Flash has been a grim hit on price/performance. Costs have gone up, throughput has gone down, and performance has improved very slightly (and regressed on a few things).
I built some BigQuery workflows on 2.0 and 2.5 flash lite that are something like 6x more expensive with 3.1 flash lite.
I tried 3 flash for months and it didn’t work using Googles own vertexai integration because it’s been in preview mode for months.
Not wanting to pay significantly more and do a bunch of rework isn’t a smell.
They left a large gap in their new pricing vs the prior generation, and if you had a working use case that sucks. The model is >99% reliable for my use case so there’s nothing to gain from a smarter model.
There is literally no more reason to use their service. I don't need a monthly expiring token pool drained at API pricing which I can get from any provider.
Wonder if this is a product decision or rather a limitation on GPUs. Their Inf2 instances require AWS Neuron [1]. Maybe porting models to run on their hardware takes too much time.
reply