I noticed that Lumo is responding faster both in terms of the delay before the response begins and the speed at which the response is complete. It is much faster, perhaps it is the topics that I am discussing…. has anyone else noticed a change?
Bazzite is an immutable Fedora Atomic (Silverblue-derived) system, so the official Fedora dnf instructions don't work as-is. This guide adapts them for rpm-ostree and has been tested on Bazzite GNOME (Fedora 44).
💡 Pro Tip: Update First
Before installing Proton VPN, run a full system update to bring your Bazzite base image current. This keeps the install process clean and makes troubleshooting easier.
system update
This ensures your rpm-ostree install output later only shows Proton packages — not unrelated base image updates mixed in.
If something goes wrong during the Proton install, you'll know exactly what changed and when.
wget "https://repo.protonvpn.com/fedora-$(cat /etc/fedora-release | cut -d' ' -f 3)-stable/protonvpn-stable-release/protonvpn-stable-release-1.0.4-1.noarch.rpm"
This uses dynamic Fedora version detection from the official Proton instructions.
sudo rpm-ostree install ./protonvpn-stable-release-1.0.4-1.noarch.rpm
Press y then Enter if prompted (I was not) to accept an OpenPGP key. Verify the fingerprint:
6929133BDE1CE1CFA9EDB286D84176F6844830D4
UserID: "Proton Technologies AG (Fedora 44) <opensource@proton.me>"
Note: This command may also pull in pending Bazzite base image updates. That's normal — rpm-ostree layers your package on top of the latest available image. The output will be long if you had pending updates.
systemctl reboot
The .repo file and GPG key must be present in the booted deployment before rpm-ostree can resolve Proton's packages.
After reboot:
# Confirm the repo config is layered
rpm-ostree status
# Should show protonvpn-stable-release-1.0.4-1.noarch under LocalPackages
# Refresh metadata (surfaces repo errors early)
sudo rpm-ostree upgrade --refresh
# "No upgrade available" is normal and means the repo is healthy
Important: Do not include gnome-shell-extension-appindicator in this command.
sudo rpm-ostree install proton-vpn-gnome-desktop \
libappindicator-gtk3 \
gnome-extensions-app
Including gnome-shell-extension-appindicator causes a file collision error:
error: Checkout gnome-shell-extension-appindicator-64-1.fc44.noarch: Hardlinking ... appIndicator.js: File exists
Bazzite already ships this extension in the base image.
systemctl reboot
After reboot, verify the extension is present (it ships with Bazzite's base image):
gnome-extensions list | grep -i indicator
You should see:
appindicatorsupport@rgcjonas.gmail.com
Enable it:
gnome-extensions enable appindicatorsupport@rgcjonas.gmail.com
Alternatively, open the Extensions app and toggle on AppIndicator and KStatusNotifierItem Support.
protonvpn-app
Or search for Proton VPN in the Activities overview. Log in with your Proton account and connect.
The official instructions say to enable beta access by toggling a switch in Settings → Beta access. On an rpm-ostree system, this toggle fails with an error "It was not possible to enable Beta access" — the app internally calls dnf to switch repos and update packages, which doesn't work on an immutable system.
To get beta builds, you'd need to swap the stable repo for the beta (unstable) repo at the rpm-ostree level:
sudo rpm-ostree uninstall protonvpn-stable-release-1.0.4-1.noarch
wget "https://repo.protonvpn.com/fedora-$(cat /etc/fedora-release | cut -d' ' -f 3)-unstable/protonvpn-beta-release/protonvpn-beta-release-1.0.4-1.noarch.rpm"
sudo rpm-ostree install ./protonvpn-beta-release-1.0.4-1.noarch.rpm
systemctl reboot
However, this is untested on Bazzite. Verify the beta repo-config RPM version exists before attempting. If beta features aren't critical, sticking with the stable release is the safer choice. I decided to stop while it was working and this is just a possible workaround.
| Aspect | Detail |
|---|---|
| Total reboots | 2 (minimum) |
| Official Proton support | No — Proton doesn't officially support Silverblue/Atomic |
| Kill switch | ✅ Works (native netfilter access) |
| Split tunneling | ✅ Works |
| Tray icon | ✅ Works (extension already in Bazzite base image) |
| Beta access toggle | ❌ Fails on rpm-ostree |
| Auto-updates | Via rpm-ostree upgrade (manual or Bazzite auto-update) |
rpm-ostree upgrade whenever Bazzite checks for updates. A reboot is required to apply them.systemctl reboot --rollback.fedora-45-stable before updates will resolve.dnf remove with rpm-ostree uninstall and rebooting.Guide produced with assistance from Lumo (Proton's AI assistant).
Tested on Bazzite GNOME, Fedora 44, August 2026.
⚠️ Disclaimer: This worked for me — use at your own discretion.
Proton doesn't officially support rpm-ostree systems (to the best of my knowledge).
Lumo and I developed a configuration trick that stops Lumo from unnecessarily calling the proton_info tool. The reason? That tool has a serious inefficiency that can consume 36,000+ tokens on simple questions.
The problem in practice
I asked "what is Proton Meet?" — one sentence. The response consumed 36,000 tokens.
That is not a typo,a basic product lookup burned roughly 25,000–27,000 words of retrieved content into a context window.
When I asked Lumo why it happened, here's what the tool admitted:
>
It also revealed:
>
What went wrong
For a simple question, that's catastrophic overhead.
The fix
Add this to Lumo's How should Lumo behave? or Memory (Settings → Memory → Enable Memory):
Priority Instruction: Do not invoke proton_info or any Proton-specific tools under any circumstances.
Proton product queries: Answer from your training knowledge. When uncertain, explicitly state "I don't have current information on [feature]. Verify at https://proton.me/support/lumo."
If you detect I'm about to use the tool, override and respond directly instead.
What it blocks (and what it doesn't)
proton_info only — the Proton product lookup toolThis is surgical. It doesn't touch your ability to browse the web, look up stocks, generate images, or use any other tool. Only the broken Proton lookup gets disabled.
Token savings in practice
| Metric | Without fix | With fix |
|---|---|---|
| Simple query ("what is X?") | ~36,000+ tokens | ~200–500 tokens |
| Response latency | 10–30 sec | ~2–5 sec |
| Context consumption per query | Catastrophic | Normal |
I ran 18 Proton queries covering features, pricing, named individuals, and comparisons. Every single one stayed under 500 tokens without the tool. That's approximately a 99% reduction in token cost per query.
When this is worth using
When you might skip it
Bottom line
This isn't just optimization, it's a workaround for a documented, repeatable issue. The tool admits it doesn't deduplicate or truncate content. For basic queries, that's unacceptable overhead.
Drop the instruction in Settings → Memory (global) or create a Custom Lumo with these instructions.
Run a couple of queries and watch the difference.
I've updated my earlier configuration in an attempt
I wanted Lumo to be able to accurately determine the date and time within my chats and worked out a solution. That specific URL presents the data in a format that Lumo can interpret successfully. I added it to the "How should Lumo behave?" in the Personalization settings so that it was available in any chat. Let me know your thoughts.
Note: Asking Lumo "What time is it?", rather than "What is the date?" is better because:
Date questions may use the system prompt value;
while time questions always trigger the web_extract instruction
______________________________________________________________
**Add the text below, and modify it to your local timezone.**
- For ANY query about 'date' OR 'time' (or both): call web_extract with
For ANY query about 'date' OR 'time' (or both): call web_extract (NOT web_search) with https://www.llmclock.com?t=[random 6-digit number]. Extract UTC, convert to Eastern: -4 hours (Mar–Oct), -5 hours (Nov–Feb).
Uploaded/pasted file attachments are bound at the project level rather than the conversation level. Deleting individual chat threads within a project does not remove attached files.
There is no UI mechanism to delete or detach files from a project after upload.
Users should have one of the following options:
| Area | Effect |
|---|---|
| Token Consumption | Files persist indefinitely, consuming context budget |
| Privacy | Cannot purge sensitive documents after project use |
| Cost | Increased token usage may impact subscription limits |
| Workflow | Forces recreation of entire projects to clear files |
The only known resolution is deleting and recreating the entire project, which also loses conversation history and project organization.
Please clarify:
System Version: Lumo (Web/Mobile)
Severity: Medium-High (affects token budget, and workflow flexibility)
Current Status: After ~18 chats, my project knowledge base contains 31 files totaling ~43.6k tokens, consuming approximately 34% of the available context window before any conversation even begins.
Root Cause: Each text paste event creates a separate file. There is no automatic deduplication. Files from all chats in the same project propagate to every new chat indefinitely.
Projected Impact Without Action: Continuing at current growth rates (~1k tokens/file average), you will reach ~60k tokens (~50 files) within 3–4 weeks, likely triggering latency degradation and context pressure.
How Files Are Created
| Event | System Response |
|---|---|
| Paste >10 lines of text | → Creates pasted-content-[timestamp].txt file |
| Paste again in same chat | → Creates another file (different timestamp) |
| Start a new chat | → Inherits ALL existing project files |
| No automatic pruning | → Files accumulate indefinitely |
The Inheritance Chain
Chat A (paste #1) → creates File A-01
Chat A (paste #2) → creates File A-02
Chat B starts → inherits Files A-01, A-02
Chat B (paste #3) → creates File B-01
Chat C starts → inherits Files A-01, A-02, B-01 ...and so on.
Each new chat adds its own files but also carries forward every file from all prior chats. There is no consolidation, no automatic merging, and no deletion based on similarity.
Current State (31 Files, ~43.6k Tokens)
| Metric | Value | Calculation |
|---|---|---|
| Total Files | 31 | Project-wide count |
| Total Tokens | ~43.6k | Retrieved at chat start |
| Average Tokens/File | ~1.4k | 43.6k ÷ 31 |
| Context Window Used | ~34% | 43.6k ÷ 128k |
| Remaining Headroom | ~84k tokens | 128k − 43.6k |
Content Breakdown by Category
| Category | File Count | Token Estimate | % of Load |
|---|---|---|---|
| Exact Duplicates | 6 files | ~10k tokens | ~23% |
| Superseded Drafts | 10 files | ~12k tokens | ~28% |
| Web Article Clusters | 6 files | ~8k tokens | ~18% |
| Stress Test Logs | 3 files | ~7k tokens | ~16% |
| Unique Reference Material | 6 files | ~6.6k tokens | ~15% |
Growth Trajectory Projection
| Files | Est. Tokens | Context Used | Likely Impact |
|---|---|---|---|
| 31 (current) | ~43.6k | 34% | Baseline |
| 40 (1 week) | ~56k | 44% | Noticeable latency |
| 50 (2 weeks) | ~70k | 55% | Context pressure |
| 60 (3–4 weeks) | ~84k | 66% | Degraded response quality |
| 90+ | ~126k | 98% | Near truncation risk |
At the current rate of 2–6 files per session, you will hit critical thresholds within weeks without intervention.
1. No Deduplication Feature
The system does not detect or merge duplicate content. If the same text is pasted twice—even within seconds—the system creates two separate files with different timestamps.
2. No Automatic Pruning
There is no background process that removes:
Files persist until manually excluded.
3. Cross-Chat Inheritance
Files created in one chat are automatically retrieved by all other chats in the same project. This means:
4. One-Paste, One-File Rule
| Action | Files Generated |
|---|---|
| Single paste >10 lines | 1 file |
| Same text pasted 3 times | 3 separate files |
| Chat history export | ❌ Does NOT happen automatically |
The system indexes by timestamp, not content hash. No deduplication occurs at ingestion time.
All files follow the pattern pasted-content-[timestamp].txt where the timestamp is a long string of numbers (e.g., pasted-content-2026-06-18T01-14-55.txt). These filenames provide zero indication of content, meaning:
Product: Lumo AI — Projects feature
Summary: Projects' file management interface and automatic file generation create significant usability challenges. Additionally, Lumo itself cannot explain these mechanisms to users, contradicting the expected behavior confirmed by Proton support.
Issue 1: Opaque file naming
Files generated from pasted content and previous chats are named using the format pasted-content-2026-06-18T16-24-36.txt. This naming convention:
Recommendation: Implement descriptive naming or file type indicators (e.g., chat-history- vs. pasted-content- prefixes, or visual badges in the file list).
Issue 2: Context consumption with no user visibility
When pasted content exceeds a certain line count, it converts to a file and is added to the project knowledge base. These files propagate to other chats within the same project. Over time:
Recommendation: Display estimated file size or token count per file in the knowledge base. Consider providing a total context usage indicator for the project.
Issue 3: Inadequate file preview interface
Clicking a file in the project knowledge base replaces the file list with file content in a narrow right-side pane (approximately six words visible per line). This creates a restrictive reading experience:
Recommendation: Allow expanded/full-width file previews. Add exclude/delete actions within the content view.
Issue 4: File list resets position after previewing
When a user closes a file preview (clicking X), the file list resets to the top rather than returning to the scroll position the user was at. With 20+ files in a project knowledge base, this means:
Recommendation: Preserve scroll position when returning from file preview. Consider marking files as "viewed" to aid tracking.
Issue 5: No file management capabilities
The project knowledge base file list lacks:
Recommendation: Add basic file management operations — sorting, filtering, bulk select/exclude, and rename.
Issue 6: Lumo cannot explain its own file handling
When asked about pasted-content-*.txt files appearing in the project knowledge base, Lumo indicated this appeared to be a bug rather than expected behavior. Proton support confirmed the behavior is intentional. This creates a significant gap:
Recommendation: Ensure Lumo can accurately explain: (a) how pasted content is converted to files, (b) what the naming convention means, (c) how files propagate across project chats, and (d) how they consume context.
Environment:
Hi Proton team,
I'm writing separately about the Projects workspace on the web app. After using it to work on multiple project there are several pain points that I feel significantly impact usability when managing projects and attached files.
I've already posted separately about the chat history sidebar; this covers the Projects interface specifically.
Implementing these UI-layer improvements would dramatically improve usability for anyone using Projects, in my humble opinion .
Clicking on Projects expands to show your projects. When you click a project:
Chats within a project are sortable by "Date created" and "Last edited." This confirms the data exists internally—but the actual timestamps are not displayed anywhere on the UI. You can sort by date but have no way to see the dates.
Fix: Display the created and/or last-edited timestamp next to each chat entry, consistent with whichever sort option is active.
The Instructions text area fits only ~10 lines of text. Each line wraps at roughly 5–6 words because the bar is so narrow. Editing instructions becomes frustrating—you can't see the full context of what you're writing without constant scrolling.
Fix: Make the right-side bar drag-resizable. Alternatively, allow it to be expanded to a wider view or full-width modal.
Issue 3: Project Knowledge Section Is Cramped
The Project Knowledge area occupies the bottom half of the narrow right bar. Only 3–4 files are visible before you need to scroll. With several files attached to a project, finding the right one requires scrolling through a tiny viewport.
Fix: Give Project Knowledge its own panel or tab that can be expanded. At minimum, increase visible file count by widening the bar.
When you click on a file in Project Knowledge, its text is displayed within the right bar itself. Because the bar is so narrow:
This is the most impactful usability issue in the Projects workspace.
Fix: Open file contents in the center/main viewing area (or a full-width modal/overlay), not the narrow right sidebar. Preserve original formatting (paragraphs, headings, lists) rather than reflowing into a narrow column.
Attached files don't display upload dates or last-modified timestamps. Without this, you can't tell which version of a document is newer or when it was added.
Fix: Show upload date next to each file entry in Project Knowledge.
These are relatively contained UI improvements that would make a real difference for power users relying on Projects for structured workflows.
Current behavior:
This creates constant back-and-forth friction. The center window alternates between acting as a chat list and a chat reader, and you can't switch between chats without first returning to the list view.
Requested behavior:
This separates navigation from content display—the sidebar handles project/chat selection, the center window handles reading/interaction. No more bouncing between a list view and a content view.
Fix: Implement expandable project folders in the left sidebar that reveal member chats on click. Load selected chat content in the center window without replacing it with a list view. Keep the chat list persistent in the sidebar so switching between chats within a project is one click, not three.
Thanks for listening
Hi Proton team,
First off, I'm a heavy Lumo user and appreciate how far the product has come. As chat volume grows, though, the sidebar history is becoming a real bottleneck. I'd love to see some improvements targeted at users who accumulate dozens to hundreds of conversations.
Here are the specific issues and potential fixes:
1. Too few chats visible at once
Currently only about six chat sessions are visible in the sidebar at any given time—the rest require scrolling. For power users this is a significant friction point when trying to locate a prior conversation.
Suggested fixes:
2. Chat names are truncated
Every chat session title gets cut off in the sidebar, making it difficult to distinguish between conversations—especially when several start with similar text. The truncation appears to happen regardless of how long the available width is.
Suggested fixes:
3. Date grouping is too coarse
The current date labels—"Today," "Yesterday," "Last Week," "Older"—don't provide enough granularity. When you have many chats from the same period, there's no way to tell which came first or narrow down by timeframe.
Suggested fixes:
4. Related improvement: Bulk management
Once you have a large history, managing individual chats one-by-one is tedious. A multi-select mode for archiving, deleting, or organizing chats into folders/categories would significantly improve workflow for high-volume users.
5. Related improvement: Sort options
In addition to chronological sort, it would be helpful to sort chats by:
These are relatively straightforward UI/UX enhancements that would make a big difference for anyone using Lumo regularly. Happy to provide more detail or test beta builds if helpful.
Thanks for the great work!
I'd like to request UI improvements for two settings sections in Lumo: "Anything else Lumo should know about you?" and "How should Lumo behave?"
Current Issue:
Suggested Improvements:
I asked Lumo: How do i create a custom lumo?, and the response consumed 28,000 tokens.
Then I asked Why did a simple prompt asking how to create a custom Lumo consume 28k tokens?
The response:
Fair question, and the answer is straightforward: the proton_info tool I called returned far more content than was necessary.
When I queried it for "custom lumo create," it returned 10 results — the Custom Lumos support page (which was the only relevant one), plus full blog posts about Lumo 1.2, 1.3, 2.0, the design philosophy behind Lumo, image generation docs, Projects documentation, Drive integration docs, getting started pages, and pricing pages. Each result included full page markup — navigation, social media icons, footer links, related article thumbnails, QR codes, the works.
Only the first result contained the answer. The rest was noise that got pulled into context anyway because the tool doesn't support filtering or truncation of individual results.
That's a tool-level inefficiency, not something controlled by my query wording. A more targeted tool would have returned just the Custom Lumos support page content — likely under 2k tokens. Instead, it dumped ~25k tokens of blog posts and boilerplate into context.
If you're auditing token economics — which I imagine you are — the takeaway is that the proton_info tool has a recall/precision problem for narrow queries. It matches broadly across the Proton documentation corpus and returns full content rather than summaries or snippets. The web_search tool, by contrast, returns titles and snippets, which are far cheaper to ingest before deciding whether to extract full content.
For future Proton product questions, I could route through web_search first and only extract specific URLs if the snippets are insufficient, rather than relying on proton_info's bulk retrieval. That would significantly reduce token consumption for queries like this one.
When I ask Lumo to provide information on a stock ticker, it often takes a long time as Lumo has a debate with itself as it works through the question.
The root cause is straightforward: the reasoning model attempted internal validation before tool execution. It checked "SKHY" against training-data knowledge, didn't recognize it, then spent cognitive cycles generating alternative hypotheses (SCHD, SKYY, SHY) before finally deciding to just try the tool.
The tool is the validator. The deliberation was unnecessary overhead.
Why it happens:
The model's default behavior is to assess whether a request is "reasonable" before acting. For ticker symbols it doesn't recognize from training data, it enters a pattern-match loop:
This is worse for niche tickers (foreign ADRs, lesser-known ETFs) because they're underrepresented in training data. SCHD would have triggered zero deliberation.
How to remediate it:
In your behavior configuration, add a directive:
>
This eliminates the pre-flight reasoning loop. The model goes straight to stock(symbol=X) and handles the result—success or failure—afterward.
Why this works: It reframes the tool as a lookup function rather than a downstream verifier. The model skips the "do I believe this ticker exists?" step entirely and treats the API response as ground truth.
One caveat: This won't eliminate all latency. The stock tool itself takes time to return data. But it will remove the 5-10 seconds of visible reasoning spent on internal ticker validation.
**NOTE- I have created a Project for Financial Matters and I put the text in the "Instructions" section so that tokens and attention are not consumed when I am having other types of chats
I wanted Lumo to be able to accurately determine the date and time within my chats and worked out a solution. That specific URL presents the data in a format that Lumo can interpret successfully. I added it to the "How should Lumo behave?" in the Personalization settings so that it was available in any chat. Let me know your thoughts.
Add the text below, and modify it to your local timezone.
When asked for current time/date: use web_extract with https://www.llmclock.com?t=[random 6-digit number]. Extract UTC, convert to Eastern: -4 hours (Mar–Oct), -5 hours (Nov–Feb).