Skip to content

[Feature]: Mobile — cache session history locally so long-lived sessions open faster (with clear/delete local cache) #5477

Description

@sprintthunder-dotcom

Summary

On T3 Code mobile, opening a session that has accumulated a long history (e.g. actively used for ~a week) is noticeably slow every time the session is reopened. It feels like the full history has to be re-fetched / re-hydrated from the host each open.

Request: Cache session history on the device after first load, so reopening is fast, and let the user view / clear / delete that local cache when they want to free storage.

Problem

  1. Long-lived sessions (multi-day / multi-week agent work) become heavy on mobile.
  2. Each reopen incurs a long wait before the chat is usable.
  3. There is no obvious control to manage local storage used by session history.

This is especially painful on mobile networks and when switching between a few large sessions during the day.

Related issues

Likely overlaps with large-thread performance work, but this is specifically about mobile client-side persistence + user control:

Even with server/pagination fixes, a local cache would still help repeat opens of the same session.

Proposed behavior

Cache

  • After a session is successfully loaded on mobile, persist message/history (or a compact local representation) on device.
  • On subsequent opens of the same session: load from local cache first, then sync only deltas / new messages from the host.
  • Prefer showing cached history immediately (skeleton / “syncing…” for the tail) rather than a blank long spinner.

User controls

  • Settings (or per-session menu) to:
    • Clear local cache for this session
    • Clear all local session caches
    • Optional: see approximate local storage used by cached history
  • Clearing local cache should not delete the real session on the host — only the phone’s offline/local copy. Next open re-downloads.

Nice-to-haves (optional)

  • Cap per-session / total cache size (LRU eviction of least-recently-opened sessions).
  • “Keep offline” pin for a few important sessions.
  • Pagination / windowed render even when cache is local (don’t mount the entire week of messages into the UI at once).

Expected outcome

Scenario Today (observed) Desired
Reopen week-old busy session on mobile Long load every time Near-instant from local cache, then quick tail sync
Free phone storage No clear control User can delete local history cache selectively
Host session Unchanged Unchanged (local clear ≠ remote delete)

Environment

  • Client: T3 Code mobile (native app)
  • Trigger: sessions with large / long-lived history (example: ~1 week of continuous work)
  • Repro pattern: open session → wait long load → leave → open again → wait long load again

Notes

Happy to provide approximate history size / message counts or screen recordings if useful for triage.

Activity

  1. sprintthunder-dotcom commented on Aug 6, 2026

    @sprintthunder-dotcom
    Author

    Clarification / offer to implement

    This is not a duplicate of #3601 or #2761.

    Issue Problem
    #3601 / #2761 Large history is slow/hangs because the server/client hydrates too much (pagination / snapshot size)
    This issue On mobile, long-lived sessions are slow every reopen, and there’s no local history cache or way to clear it

    Server pagination would help first load; this asks for device-side cache + user-controlled clear, so reopening the same session is fast after the first load.

    Happy to open a small, scoped PR for mobile local history caching (load from cache → delta sync → clear per-session / clear all) if maintainers want this direction. Prefer design/API notes first so the PR stays small and reviewable.

  2. sprintthunder-dotcom commented on Aug 6, 2026

    @sprintthunder-dotcom
    Author

    Additional repro / comparison (same network path)

    When the host is reached over Tailscale:

    Client Session open / sync speed (long-lived sessions)
    Safari (T3 Code web UI over Tailscale) Noticeably faster
    T3 Code mobile app (same machine / sessions) Noticeably slower every reopen

    So this doesn’t look like “Tailscale is slow” alone — same remote path, native app is much slower than Safari on large/history-heavy sessions.

    That points more at mobile app history load / lack of local persistence (or app-side hydration) than pure network latency. Happy to add device/OS/app version numbers if useful.

  3. locked and limited conversation to collaborators on Aug 15, 2026
  4. converted this issue into a discussion #6879 on Aug 15, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions