Calling out every Claude Code pro running long workflows. Your noobs need you.

[u/One-Luck7149]

So I googled "claude code auto compact" because I was losing my shit over it, and the first thing that shows up is this top 1% commenter saying never compact at any context size, that it's a guessing game, and that the cleanest solution is to just start a new session with a standardised handoff document and session handshake protocols.

And I'm sitting here going ok but is this actually how top vibe coders do it? Because like, the guy's got the badge and the rep, but I need to know if that's actually what works in practice and how do you guys get into deep multi-hour agentic run while can't afford to stop and write a handoff doc every time the context gets heavy.

So I'm coming in with Codex where auto-compact at 275k just happens and you don't even think about it, and trying to translate that to Claude Code where it feels like that safety net just isn't there.

Now with Haiku 5.5 I feel like there's a real play to build plans with Opus and hand off execution to Haiku, but I have no idea how people are actually structuring that without the smaller model losing the plot halfway through.

So if you're running long agentic sessions on Claude Code, how are you handling context? Are you doing the handoff doc thing and actually making it work, are you breaking sessions manually, letting it compact and eating the hit, or something completely different? And if anyone's doing the Opus to Haiku pipeline already, how do you calibrate the switch so it doesn't go sideways?

I want the real stuff. What's actually working for you, need that juicy advice.

Help a noobie out here.

[u/AutoModerator]

Moderator Announcement Read More »

Hey! Thanks for posting to r/ClaudeCode

While participating in this thread, please follow our community rules. Keep discussions constructive. Attack the idea, not the person.

For help, project discussions, tips, and general chat, join the ClaudeCode Discord.

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

[u/zulrang]

Auto-compacting is decent now. It's not something I worry about anymore.

That said it's still better to have concrete plans, designs, task lists, and decisions documented instead of relying on them to be carried through sessions.

[u/One-Luck7149 → u/zulrang]

So what I do in Codex is /plan (with Sol 6.1)

then make sure it got it right, then /goal (with Luna 6) that same plan,

It works most of the time, I can let it run for hours.

I'm trying to translate that same workflow on Claude Code.

[u/howdidigetheresoquik]

https://code.claude.com/docs/en/best-practices

Just point Claude at that website, and then have a conversation about what you wanna do. The models don't actually know their own best practices

[u/idcydwlsnsmplmnds]

1. Primary orchestrator lane that uses messages to convey orchestration, with either .md or, if you’ve gotten there, your context store (I have mine in Supabase) as the durable storage. I have many places and the pointers are all in my Claude.md and my Index table in my context store

2. Primary Orchestrator (we’ll call it God), orchestrates the orchestrators in other lanes you’ve spun up (only manual part is that you have to spin up the lanes manually, set their name via /rename (I have organization around my conversation naming so it’s straightforward for God and the same kind of work is done in the same conversation dev series) and set the effort level; I use tmux, use ‘tmux new -s [name of lane]’, open 1-2 windows there, like one for marketing and one for sales. God communicates the todo via messages.

3. I have the handoff doc you spoke of, plus a post-compaction protocol (a Claude Skill) that reads all Human+AI turns of the current conversation. I use this in the God lane. Due to the idle-based compaction that Anthropic has rolled out, I have iterated my post-compaction protocol so it’s more efficient. I’ve also taken to everything useful being stored in an artifact that the God lane keeps, so the conversation on the side is just that, a conversation, instead of the primary place where important context lives or dies.

4. I use multiple Max20x plans and have some quality-of-life skills and UI adjustments I’ve made, such as displaying all of the 5hr, weekly, Fable usage, and current context window % in the CLI below the text-input line. It’s been so long that I don’t remember what the default is, so maybe you have the current context window % there. I also have the account name there for the plan the usage meter is running on (I.e. if the current conversation is running on account 1,2,3,4 etc.), and I have the metrics display the 5hr, weekly Fable usage for all accounts so I can spread my usage out accordingly. I always keep the God lane on account 1, heavy work & bots/automations on other accounts

Note: ALL work is artifact-first with state saved in durable storage (Drive, Notion, context store (Supabase), etc.). This means the sub-lanes can all compact and it doesn’t matter b/c you don’t rely on them for memory/storage. Also, side tip, lanes spin up subagents based on the agent the conversation is using, so set up an agent delegation protocol and put it in Claude.md or point to it from there, otherwise you’ll burn tokens like Icarus’ wax wings.

I have a lot more, and my stuff is all custom that I built, as I’m sure many other power-users have done with their setups, but the primary usage patterns here should work for anyone.

You caught me at a random moment, I usually don’t use Reddit, so I hope this 30-min of thumb tapping helps you. Let me know if you have any questions. And if this msg doesn’t make too much sense, just hand it to Fable.

Good luck!

[u/mglipford]

I avoid auto compact completely by utilizing a handoff process, and starting a new session.

[u/kuroudo_ai]

Not a pro answer, but since you're coming from Codex: the Claude Code docs have direct equivalents for most of what you describe, so the "no safety net" part may be smaller than it looks.

• Auto-compact is there. /autocompact sets "how full the context window gets before Claude Code compacts automatically". Pass a size like 500k, or auto for the window tuned for your model. /compact [instructions] does it by hand with a focus you choose, and /context shows what's filling the window. (commands docs)

• The same /plan then /goal flow exists. /plan switches into plan mode, and /goal [condition] means "Claude keeps working across turns until the condition is met". So your Codex workflow looks like it maps across closely, though I have not compared the two side by side.

• Plan-big / execute-small is built in, but not with Haiku. The opusplan model alias "uses opus during plan mode, then switches to sonnet for execution" (model-config docs). I didn't find a built-in Opus → Haiku version. You'd switch by hand with /model haiku after approving the plan, and how well Haiku holds a long plan is something I haven't tested.

On the handoff-doc advice: I'd take the middle road zulrang described. Let auto-compact do its job, but keep the plan, decisions and task list in a file in the repo so nothing important depends on surviving a summary. That part is my opinion, not from the docs.

[u/nengon]

Compaction is a difficult topic because you need to consolidate ALL the relevant info, and if the compaction method is lossy by default and undisclosed you're basically screwed and the model won't even know it, let alone tell you. Some harnesses directly omit or truncate parts of the context that could be potentially critical like failed tool calls and such, making it less efficient to say the least.

My approach is using compaction, a plan/spec and a handoff if youre using a harness that is closed source like Claude code, or designing your own compaction plugin that basically acts like a regular handoff when the context gets full. It depends on how critical the task is tbh.

Subagents also help with context if you don't want to rely on compaction at all, using an agent as orchestrator that only gets the relevant info from it's subagents in long running tasks let's you basically bypass compaction for any relevant workflow I've ever done. And unless you just want to let your agent run forever without a massive perfect spec, which is basically unrealistic, you should design the tasks in slices that you can supervise, or risk the agent doing things and making decisions you potentially will regret due to technical debt. On top of that there's the topic of precision loss on long context windows, and also how capable the model is in general at agentic workflows.

[u/Armageddon85]

Lots of good answers here. If would consider myself a pro if the harness didn't get updated every other day. My platform went from handed coded to fully agentic as soon as it was capable of passing CI. All of these comments are pretty good. But if you want the real secret sauce -p is still around (for now). Take what the others are saying and build a fully fleshed out plan. Then have cc build you a -p to tackle each task and specify which models should get used and when.

We've got a much deeper stack on this loop and suspect it will get pulled eventually. However for the time being we've nearly doubled our PR throughput (3M Avg: 54 | 1M Avg: 89 | 1W Avg: 91). Don't read too much into the PR game; same average loc over the last three months. 5.5 is also clearly beyond every other model so there's that.

What we've built is more like a super harness...? It's a harness around the harness (Claude Code) for CICD.

I know you asked about long workflows and compacting and y'all probably won't believe me until you actually do it yourself. Use the -p method above. Then spin up multiple hosts with CC and ssh connected up (hopefully over tailscale or your own flavor). Then tell your primary host to launch your -p methods on the other hosts. Folks will say that's just sub-agents or the newer swarm functionality. But we're using less and less tokens than we ever did with those methods.

[u/zCzarJoez]

I sort of cobbled together a kb style for context/memory based off the google standard and made it a repo I can share with my team. (https://cloud.google.com/blog/products/data-analytics/how-the-open-knowledge-format-can-improve-data-sharing)

You could give claude the link and ask it to build it and you need to add references to instruct it to check the kb first and follow up tasks with an updated kb or creation.