Just wanted to share my review and experiences of using Lumo 2.0, which is Proton's new LLM.
Given that many of us use Proton services and are privacy conscious, I thought this might be of interest.
The below is a lightly edited from another post.
It broadly speaks to the integration (or lack thereof) of Lumo with other Proton services, rather than the privacy angle (which I am sure you're aware of), though I can speak to that too. EDIT: see my below follow up.
I see no reason at this point to continue with my subscription, and if anything, I'm thankful for the shot in the arm to improve my self hosted stack / create an equivalent or better service for myself.
TL;DR: With some elbow grease and know how you can probably create something equivalent or better home.
I keep seeing suggestions here that Proton should adopt Kimi K3, or otherwise move to a much larger and more fashionable model.
I am increasingly unconvinced that model capability is Lumo’s primary problem.
Lumo Lite appears very likely to be based on a Qwen 27B-class model, judging from the behaviour and the Artificial Analysis results Proton have stated.
(That identification is not proven, obviously, but it is plausible enough for my broader point).
A model in that class should already be an excellent all-round foundation for Lumo.
My humble suggestion:
Serve it at FP8 or comparable precision. Optimise it properly. Keep latency reasonable. Increase the context length.
Then spend the engineering effort on the things that would actually distinguish Lumo from every other chatbot:
-
Reliable Proton Mail, Drive, Calendar and Contacts integration
-
Authoritative and current Proton product information
-
Deterministic tools for calculations, dates, prices, plan limits and account features
-
Exact-span retrieval rather than loose paraphrasing for proton_info
-
Visible source dates and document versions
-
A clear distinction between retrieved evidence and the model’s interpretation.
At present, Lumo can (apparently) retrieve information about Proton’s own products and then produce an answer that reverses or mangles the source.
Something like “it is not $12.99” becoming “$12.99” is not a problem that Kimi K3 or GLM inherently solves.
It is a grounding and validation problem.
A larger model may paper over some failures. It may phrase uncertainty more elegantly. It may recover from poor retrieval more often.
But it does not make stale information current, and it does not make an unreliable tool pipeline deterministic.
IMESHO, Proton’s strategic advantage is not that it can host the largest open model.
Other companies will always have larger models, more compute and faster release cycles.
Its advantage is that it owns a private productivity ecosystem, with only one real mind share competitor.
A smaller model that can reliably search my mail, locate a Drive document, understand my calendar, retrieve the correct Proton support information, chat, OCR (native ability with latter Qwen models iirc), image manipulation and perform bounded actions would be considerably more useful than a stronger general-purpose chatbot with shallow integration.
I would much rather Proton solidify Lumo Lite into a dependable, deeply integrated assistant than keep changing the model underneath it in pursuit of benchmark gains.
The model is probably already good enough.
The product around it is not.
ICBW and YMMV.
The best thing about Lumo is that it isn’t integrated with their core services. I hate seeing ✨bullshit everywhere.
Hah, I dont mean integrated like Micro$hit. I mean "is aware and can communicate with your other Proton services".
I like Lumo too but right now it's just...a collection of open weight llms, with missing features, low context and poor utility (bad web app, poor integration with Proton drive, can't create artifacts etc).
If Proton's intention is to create a privacy-based alternative to chat GPT or Claude, they're going to be chewing off a hell of a lot more, and nothing in how Lumo is currently served offers any confidence in that.
On the other hand, if their intention is to offer a Proton based product, that could be tightened up and made much more useful in a short order. Without spending a lot more.
But I'm not doing Proton's homework for them. As an end user, Lumo isn't quite "there" for me as a product, so I will discontinue. YMMV.
If Lumo had access to the contents of your mailbox, wouldn't that be breaking a core feature of the whole Proton stack? E2EE/zero knowledge is fundamentally incompatible with integrating a provider-operated chatbot that can access your data
Zero-access means Proton cannot independently read stored mail (*). It does not prevent users from authorising selected decrypted emails / folders for temporary Lumo processing.
A server-side AI would temporarily see plaintext (which Lumo does anyway when it uses Proton drive etc), so Proton would need strict opt-in, minimisation, no retention, and clear disclosure, but it would not necessarily break zero-access storage.
Again, we (users) shouldn't be the ones doing the homework on this. Let Proton work it out (or not). Given it's taken 4+ yrs to get Proton drive to work with Linux.... well....
Are you new to corporate lies about privacy?
Proton is beholden to Swiss disclosure law, and swiss law caves to international requests pretty often.
Just assume your emails are being read by proton.