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

[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:

• [Bug]: OpenCode provider hangs opening/resuming a large thread — readThread pulls full session history unpaginated, no timeout #3601 — OpenCode: large thread open/resume pulls full history unpaginated
• [Bug]: Degraded performance of the remote webapp on large threads. #2761 — Degraded performance of the remote webapp on large threads
• [Bug]: Packaged web assets are served uncompressed and without cache headers, causing slow remote/mobile startup #4398 — Packaged web assets / slow remote-mobile startup (adjacent cold-start cost)

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.

[sprintthunder-dotcom]

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.

[sprintthunder-dotcom]

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.