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.

  • I’ve played around with Lumo… it uh, generates some text.

    Maybe I’m missing the point of why someone would pay for that?

  • I personally like Lumo. There aren’t many other services that offer privacy out of the box. And it’s not some integrated solution so that I don’t have to worry about data being shared with other services.

  • I don’t think Qwen 27B would make much sense. I’m pretty sure Deepseek is cheaper to serve at scale (because of the small active parameter set) and is “smarter.” At least that’s what is reflected by 3rd party provider pricing on Openrouter.

    Reliable Proton Mail, Drive, Calendar and Contacts integration

    I think this could cause major problems for privacy guarantees.

    • how? aren’t all of them already hosted on Proton’s server. you are already trusting them for your data. how does Lumo make it worst?

      • Proton can’t read your mail (big “*”); it’s decrypted client-side. Feeding it to their LLM would violate that. I’m unsure about their other services.

    • Deepseek, Minimax, GLM, Kimi etc are all massive and take serious compute and storage. Active parameter count and MoE tricks not withstanding, does Proton have the capacity and infrastructure to offer them at scale (let’s say, 1 million subscribers) in good quality? Dunno.

      Unlike Kagi, Proton hosts in house, not API. Lumo lite is very plausibly Qwen 27B based on what Proton have stated and shared.

      It could be Qwen 3.6 35B-A3B or Qwen3.5-397B-A17B (but that makes no sense for a “lite”). Nothing else really matches the AAII scores they have stated.

      https://proton.me/support/lumo-privacy

      https://proton.me/blog/lumo-2

      So, if the intention is to provide a proton product, a bigger LLM is going to cost them a lot more to operate, concurrency, MoE tricks and network effects notwithstanding.

      Lumo is already capped at --ctx 128K at an unknown quant.

      Proton is vary cagey about the details, for reasons you can imagine.

      I think this could cause major problems for privacy guarantees.

      Why? Either the privacy protections are legitimate and effective - in which case, a smaller, more capable product becomes a genuine USP.

      It would costs less to run, costs less to buy, and is genuinely more useful than a bare LLM (or whatever thin harness or system prompt Proton uses

      Else the entire Proton premise is a house of cards from the jump.

      Either it’s all private or none of it is.

  • “Given that many of us use Proton services and are privacy conscious” ~ oxymoron

    • Cute.

      I’m unaware of any broad PII leaks or privacy issues specifically pertaining to Proton.

      If there are some, please cite them. I have no fealty to Proton or anyone else.

      Irrespective, my comment was meant as a foot in door / bridge, as most people (when encountering a privacy-based services) begin with Proton.

      Certainly, if you are concerned about them becoming a mini-Google (convergence of services wise), that’s fair, but at present, I’m unaware of any specific data breaches etc.

      If there’s a broader pattern of data insecurity, that’s worth discussing as well.

      Lumo is supposedly cryptogenically end to end encrypted on top of Lumo hosting the infrastructure in GDPR friendly locale, with zero data retention (ZDR) policies.

      The unique selling point of Lumo should be that it uses open weight models (GLM 5.2, Qwen 3.5 27b) with strong privacy policies. You could see why that might be an appealing competitor to something like chat GPT or Claude.

      In practice, it’s hamstrung and poorly integrated and it feels to be about one to two years behind the big providers.

      Given Proton’s infrastructure and ecosystems, I think they are probably bringing a knife to a gunfight if they go that route.

      • An email and vpn provider promoting themselves as privacy conscious, and then developing ai should set off alarm bells. I was previously a customer of proton (email and vpn), you don’t have to pay attention to their products, social media, and customer service for long to realise that marketing is their strong point. Purple-washing may become a term for faux privacy companies in future.

        • Convegence of services under one provider is a real risk, but if you’re thinking that Proton will somehow use their AI to data mine their users emails / photos / IP traffic, that’s something else.

          I haven’t seen a proton do anything overtly in that direction… yet.