Don't try to carry a session into Fable. Write the session down — state, rules, facts, an ordered task list, and the transcript — into one durable page, and point a fresh Fable run at it. Your first session stays untouched as a fallback; Fable starts already knowing everything.
The situation
You've been working in one long session. It's rich with context — decisions made, files touched, facts established, the shape of the whole project in its head. Now you want to hand a big overnight build to Fable, the heavy model, because that's exactly what it's for.
But Fable burns roughly twice the budget per token, so you want the run to be deliberate. And you don't want to lose everything the first session knows — or pay to rebuild it from scratch. So the natural instinct is: "let me keep the first session warm and run Fable off the back of it."
Why "keep it warm" doesn't do what you think
Here's the thing most people get wrong. Two different things are quietly being confused, and only one of them is portable.
Prompt-cache warmth is tied to a specific model and a specific session. A fresh session on a different model can't inherit it. Keeping session one warm gives session two nothing.
Everything the first session "knows" lives in its own history. A brand-new session — Fable or otherwise — starts with none of it. There is no shared pool of understanding between two windows.
So "keep the session warm and run Fable off it" is a category error. A new Fable session isn't standing on the old one's shoulders — it's starting cold, in the dark, however warm the other window is.
The trick: turn the session into a document
The move is to stop treating context as something trapped inside a session and start treating it as an artifact you write down. Before you start Fable, spend a few minutes producing one durable handoff — a page, a doc, a file — that captures what a fresh agent needs to be immediately useful. Then the fresh Fable session reads that and it's caught up in one pass. No cache required, no history inherited, nothing lost.
A good handoff has five parts. Miss any one and the new session wastes its first hour re-discovering it:
- Current stateWhat's already done and live, so it builds on your work instead of redoing it.
- The rulesThe non-negotiables a fresh agent breaks by default — what never to do, what always to verify. This is the part that keeps an unattended run safe.
- Facts & locationsThe specifics it would otherwise burn time re-deriving: where things live, what's true, the numbers that are settled.
- An ordered task listNot "do good work" — a numbered queue of concrete prompts, most valuable first, each with a clear "done when" condition.
- The transcriptThe full record of the session behind the handoff, for when the summary isn't enough and it needs to see how something was decided.
The first four are the actionable brief; the transcript is the deep reference. Together they turn "everything I know" into something another session can absorb in minutes.
Now the original session stays warm — and that's the bonus
Here's the elegant part. Because Fable is running off the written handoff, your original session doesn't have to feed it anything. So you can just... leave it alone. Keep the window open, don't send it anything, and it stays warm within its cache window — sitting there as your fallback. If Fable goes sideways, you drop back into the original session, still fully in context, and course-correct. You've lost nothing.
That's the whole trick in a sentence: the handoff is what makes the warm session safe to leave alone. Without it, you'd be forced to babysit the first session to keep the knowledge alive. With it, the knowledge is on paper, and the warm session is a spare — not a lifeline.
Close the loop
Finish the pattern by asking the Fable session to do for you what you did for it: when it's done, have it write its own handoff back — a session log and a transcript of what it did — to a known place. Now the flow is symmetric. You handed Fable the context going in; Fable hands you the results coming out. You review its work from your still-warm original session, and nothing was ever lost in the gap between two windows.
- Session one writes the handoff (state · rules · facts · task list · transcript).Then goes idle — warm, untouched, held as fallback.
- Fable reads the handoff, works the task list, verifies as it goes.Fully briefed from the first message; no cold-start guesswork.
- Fable writes its own report + transcript back to a known place.The results are now an artifact too — reviewable, not trapped.
- You review from session one, still in context.Course-correct or continue. Nothing lost across the handoff.
Why this is the best trick of all
Because it changes what a "session" is. Most people treat a session as a fragile, unrepeatable thing — a warm bath you can't afford to drain. This trick treats context as what it actually is: information, which can be written down, moved, reviewed, and resumed. Once you externalize it, the model behind any given session stops mattering. You can run the cheap model to plan, hand off to Fable to build, hand back to review — each session a fresh, briefed start, none of them a hostage.
The warm-session instinct isn't wrong, it's just aimed at the wrong target. You don't preserve a session by guarding it. You preserve it by writing it down — and then you're free to open as many as the work needs.
One caution worth keeping: if you ever run two sessions at once, don't let them edit the same files. Two windows writing the same file will silently clobber each other. Different tasks, different files — and the handoff pattern above keeps them cleanly separated by design.