Anyone have experience using Lumo for this?

If Lumo is so private and they have no interest in our data / prompts, why do they make us sign up for an account to get past the weekly limit?

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:

• Both text input windows are undersized, making it difficult to compose detailed responses and review the current text
• Scrolling within these fields is challenging on both the web interface and iOS app
• The constrained space creates difficulty for users attempting to configure the customization these sections are designed for

Suggested Improvements:

1. Increase default height of text areas
2. Add resize handles or expandable/full-screen input modes
3. Improve touch targets for scrolling on mobile (larger scroll areas, smoother momentum)
4. Separate the settings into two tabs.

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.

hi is there a CLI or API coming out? definitely the top of my list -- i don't care too much about the website chat, i want something in terminal and with tool calling

please make the chat names editable from the automatically generated ones

I mean I maybe get - somehow - why lumo doesn't want to keep history and push people towards subscription. I was fine with it buying it in the next few weeks when my other LLM runs out. Now I have to think about it twice. It has a bad taste right now... Meanwhile I was testing lumo if it would work and it looked well enough. In lumo 1.x it just hid old chats which were not used for more than 7 days but now it literally nukes them after 7 days no matter what? Well, now I lost data which I can't recover and redo, I have to begin from scratch. Lost 2 weeks of literally unrecoverable data because I used a project folder... Wtf is this business idea behind this? Maybe make a red timer on top of the chat when it will be gone. That's not a very well-thought-out idea. Just wanted to vent tho... And make people aware of this strange behavior...

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:

1. Is this a known ticker? → No match in training data
2. What could it be a typo for? → Generates candidates
3. Should I ask for clarification or just try? → Debates
4. Eventually tries the tool → Gets valid data back

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).

Whenever I use Lumo on my PC in the browser and give it a prompt I always see it 100% only 1 core at a time (probably CPU's heat management that makes it move from one core to the other). Is there a way for the devs to give it multithreading or is that the limitation of using a browser?

Hey everyone,

I just wanted post to post about how good the Visualization feature in Settings -> General is to display data in charts and other visualization formats. The Lumo Team really overdid themselves on this one! It is amazing! I only had to tell him once to use them dynamically and he uses them perfect now. I asked him to compare some open weight models that were upcoming and he instantly started researching. After he had all the data he made a perfect structure. First of all the different things a model was best at (e.g. Parameters: Kimi K3 because of 2.8T, Cost of the API: GLM-5.2 (yeah he included GLM-5.2 even though it is already here because I asked him to)) Benchmarks, then the parameters and how much RAM they take, third he got me the cost of the API and created profiles of the model with all the data he could find and even differentiated between confirmed sources and speculations, finally he made some summaries as info cards.

Thank you, Proton/Lumo Team for your Job!!