Proposal: session-aware commands for the 5-hour message limit (turns / resume / batch)

[fiorentinjoao]

Proposal: session-aware commands for the 5-hour message limit (turns / resume / batch)

TL;DR

I'd like to gauge interest before opening a PR, per the "discuss core features first" note in CONTRIBUTING. I have three small commands that target a problem RTK doesn't touch today: the 5-hour message-window limit on Claude subscription plans. They're session-aware (they read ~/.claude/ transcripts) and I'd love your read on whether this fits RTK's scope or belongs behind a feature flag / separate surface.

The problem RTK doesn't solve yet

RTK optimizes token volume per tool call — brilliantly. But Claude Code subscription plans (Pro/Team) also enforce a message-count limit per 5-hour window. That limit counts turns, not tokens. So you can be nowhere near a token cap and still get cut off mid-task because you sent too many messages.

These two limits are independent, and RTK currently only helps with the first. The commands below attack the second.

What I'm proposing

Three commands, all read-only over the local Claude Code session transcript:

rtk turns — turn-budget predictor.
Reads the current session's JSONL transcript, counts user messages, computes velocity (msgs/hour), and estimates how long until the 5H window is exhausted. Output is a few compact lines: 43 msgs (86% of window) · ~18 min left at this pace.

rtk resume — session summary for continuation.
When you get cut off (or close the terminal), it generates a compact ~/.rtk-resume.md from the transcript: files edited, commands run, recent user intents. You paste it into the next session to resume without re-explaining — saving the turns you'd otherwise spend rebuilding context.

rtk batch — task compiler.
Takes N short tasks and emits one structured message, so a sequence of small asks costs one turn instead of N.

Why this isn't foreign to RTK

RTK already reads ~/.claude/ session data — rtk discover mines Claude Code history for missed savings, and rtk learn mines it for CLI corrections. These commands use the same data source, just for a different optimization axis (turns instead of tokens). So the "is RTK allowed to read sessions?" question is already answered by the codebase.

Open questions for maintainers

1. Scope fit — does "turn-window optimization" belong in RTK's mission, or is RTK strictly about per-command output filtering? I can see arguments both ways.
2. Coupling — these are Claude-Code-specific (the transcript format is Claude's). discover/learn already are too, but if you'd prefer these gated behind a flag or namespaced (rtk session turns, etc.), I'm happy to follow whatever pattern you prefer.
3. Appetite — if there's interest, I'd open one small PR per command rather than a single large one, each with tests and the standard quality gate.

Happy to adjust scope, naming, or output format to match the project's conventions. Just didn't want to build PRs blind. Thanks for considering — and for RTK; it's become core to my daily workflow.