You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I searched existing issues and did not find a duplicate.
I am describing a concrete problem or use case, not just a vague idea.
Area
apps/server
Problem or use case
I find myself dumping dollars on a request when i come back after too long and the tokens have dropped out of cache
Proposed solution
I want a lock feature on threads that make it read only. And a stretch goal I want threads to autolock after cache is dead. There should be a manual workaround for resuming a locked thread. The UI could also provide an indicator of the cost to resume the conversation
Why this matters
This can save accidental large conversations from being fully reprocessed, reducing costs and increasing efficiency.
Aside, it also provides a convenient "end of session" boundary that doesn't really exist in t3code and is something some automation I have built around codex/cc rely on.
Smallest useful scope
A lock feature in the UI
Option to autolock threads after a period of time
Alternatives considered
I currently work around this by manually avoiding large old conversations
Risks or tradeoffs
Difficult to track cache liveness and resume costs across providers.
enhancementRequested improvement or new capability.needs-triageIssue needs maintainer review and initial categorization.
1 participant
Converted from issue
This discussion was converted from issue #3117 on August 15, 2026 09:44.
Heading
Bold
Italic
Quote
Code
Link
Numbered list
Unordered list
Task list
Attach files
Mention
Reference
Menu
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
Before submitting
Area
apps/server
Problem or use case
I find myself dumping dollars on a request when i come back after too long and the tokens have dropped out of cache
Proposed solution
I want a lock feature on threads that make it read only. And a stretch goal I want threads to autolock after cache is dead. There should be a manual workaround for resuming a locked thread. The UI could also provide an indicator of the cost to resume the conversation
Why this matters
This can save accidental large conversations from being fully reprocessed, reducing costs and increasing efficiency.
Aside, it also provides a convenient "end of session" boundary that doesn't really exist in t3code and is something some automation I have built around codex/cc rely on.
Smallest useful scope
Alternatives considered
I currently work around this by manually avoiding large old conversations
Risks or tradeoffs
Difficult to track cache liveness and resume costs across providers.
Examples or references
No response
Contribution
All reactions