Dear Proton Support Team,

I would like to propose a set of related enhancements concerning temporal information in Lumo, together with a suggested deployment model aligned with your existing subscription structure.

Current Situation
Lumo currently receives the calendar date in its system prompt (e.g., "Today's date: 07 Oct 2026"), but does not have access to:
1. The day of the week
2. The ISO week number
3. The local time of day
4. Any record of when previous messages in a conversation were sent

The weekday and week number are mathematically derivable from the date, but this derivation must be repeated on every message — unnecessary overhead for facts that never change within a day. The time of day cannot be inferred from the date at all without indirect methods (such as invoking a tool purely to extract a timestamp from its response), which is inefficient and unreliable. And since past system prompts are not retained in the conversation context, Lumo cannot perceive any elapsed time between messages, no matter how precisely the present is known.

Proposed Enhancements

1. Weekday and ISO Week Number (all users)
   Append both to the existing date injection.
   • Token cost: minimal, roughly a dozen characters per message.
   • Benefit: eliminates redundant per-turn computation and guarantees consistent calendar awareness.

2. Current Time Injection (Lumo Plus)
   Additionally inject the user's local time of day into each prompt, as an opt-in setting.
   • Cost: requires a client-side time handshake or similar per-session mechanism, comparable to existing infrastructure-backed Plus features such as web search.
   • Benefit: enables time-aware behavior such as tone adjustment to the hour, and rules that trigger at specific times.

3. Per-Message Timestamps (Lumo Plus, probably)
   Append the send time to each message, persisted in the conversation transcript.
   • Cost: unlike the fixed-size injections above, the accumulated token overhead of per-message timestamps grows with conversation length — effectively consuming a small surcharge on every historical turn in every subsequent prompt. For long-running conversations this is a recurring and increasing cost, which suggests the Plus tier.
   • Benefit: this is the only mechanism that provides elapsed-time reasoning. Knowing the current time alone does not tell Lumo when a previous message was sent; a timestamped transcript does.

Use Cases

Personal use case — alternating shift schedules: I work alternating early and late shifts based on ISO week parity. In odd-numbered weeks (early shift), I should be asleep by 20:00; in even-numbered weeks (late shift), I arrive home at 21:30; weekends are unconstrained. A functional reminder rule ("after [20:00 or 02:00, depending on shift] on a work night, tell me to go to bed") requires the weekday, the week number, and the current time — all three layers together. Today, only the date is provided, and the derivation of calendar facts is reasoning-intensive and unreliable enough that such a rule cannot be trusted.

Commitment tracking: time-relative statements ("I'll check back in five minutes") only become meaningful if the assistant can compare a previously stated time against the present. Without per-message timestamps, this class of verification is structurally impossible — the assistant knows only "now," with no record of "when."

Conversation integrity: with automated summarization of long conversations, timestamps serve as structural markers. Elapsed-time gaps carry real meaning (a thirty-second reply versus an overnight pause), and preserving that information makes compacted summaries substantially more faithful.

Implementation Notes
Timestamps can be captured client-side at send time and attached to the message payload, requiring no server-side clock synchronization. All four proposals operate entirely within the existing privacy model: no data sharing, no training usage, and timestamps originate from the user's own device. Users implementing parity-based rules (as in my schedule) could additionally anchor their rotation to a reference week in persistent memory, keeping such rules debuggable when the underlying roster changes.

Closing
These proposals would give Lumo a coherent sense of time that currently requires awkward workarounds to approximate. I believe the split between near-free calendar facts and infrastructure-dependent time data fits your existing tier structure well.

Thank you for considering this suggestion.

P.s.: Yes, Lumo wrote this on my behalf. I did proofread all and edited some of it, though.