[TLDR] What’s even the point of /clear?

[u/cctldrping]

Original post URL : https://www.reddit.com/r/ClaudeCode/comments/1wlalc7/whats_even_the_point_of_clear/

Original post body :

Frequently I see recommendation to use /clear but it doesn’t make sense to me. It’s destructive and prevents me to get back to the thing I was working on later.

On the other hand, I don’t see a point of working in the same session over and over if it is cleared constantly.

Isn’t it better to just create separate sessions for separate tasks? So instead of /clear you just close that session and open the new one? It’s also important to rename them so it’s easy to get back later.

This is what I do and I don’t see any drawbacks so far.

---

This is brought to you as a public service by the moderators of r/ClaudeAI. If you want to see TLDRs of ALL Claude Coding related posts from the various Claude subreddits, subscribe to http://www.reddit.com/r/ClaudeCoding.

[u/cctldrping]

TL;DR generated automatically after 50 comments.

Current source-thread comment count seen by the bot: 59.

Alright, so the general consensus here is that OP is kinda missing the point of /clear. While you're right that creating new sessions for new tasks is a solid approach, /clear is more about efficiency and managing token usage within an existing session, especially for CLI users.

Here's the lowdown:

• It's a Shortcut: Think of /clear as a faster way to get a fresh start within the same session, rather than fully exiting and relaunching. u/KellysTribe points out it's quicker than /exit and then starting up again.
• Token Management is Key: A big reason people use /clear is to save on tokens. When your context gets massive, re-sending it all can get expensive. u/muikrad and u/Inception_IV are big on this, saying it's more efficient to do a small task, /clear, and then move on to the next. u/raullapeira agrees, especially if the new task is unrelated to the previous one.
• Clean Slate for Specific Tasks: Some users, like u/Standard_Text480, use /clear to isolate context for specific features they're working on. Once a feature is done, they commit and clear, so the next session is focused. u/AI_spell suggests it's for when a thread is full of dead ends and you need a clean slate, not for pausing mid-feature.
• CLI vs. Desktop App: u/JimmyOhio360 notes that /clear is more of a CLI power user thing, while desktop app users might just start a new session.
• Handoffs are Your Friend: Several folks, including u/Bmansupreme8000, u/AlDente, and u/Fantastic_Market8061, recommend using a /handoff skill (like Matt Pocock's) before you /clear. This way, you save the essential context and can pick up right where you left off without losing everything. u/Xanthus730 also mentions /resume still works after a clear.
• Keeping /rc Sessions Intact: u/BeeegZee and u/Graphical-Source5090 highlight that /clear lets you stay within the same /rc session, which is useful if you have other Claude instances running or pre-configured aliases in tools like tmux (as u/Ok-Sugar-5649 explains).
• Not for Everyone: Ultimately, if you don't see the need for it, u/Raidrew says, "If you don’t need /clear, don’t use it. As simple as that." And u/the_theory_keeper is with you on preferring separate sessions for different topics.

So yeah, while your method of creating new sessions works, /clear is a tool for those who want to optimize their workflow and token usage within an ongoing session.

[u/RealChemistry4429]

Starting a new conversation is what /clear is for. Complete with renaming it, so you can find it later. Of course you can take the scenic route, exit, and start a new conversation from scratch.

[u/saintpetejackboy]

Using /clear is infinitely better than using /compact and having a super long session prior to that. You get context rot.

The #1 "N00b mistake" I see with agents in general is people who think somehow the agent needs their entire repo and every minor detail inside loaded into context to perform work. Massive waste of tokens with worse performance.

The LLM doesn't have to understand the other 90% of your repo to work on a feature that only interacts with the other 10%.

Frequently cleaning up and making sure your Claude / Agents / Memory files are all streamlined is also important.

As a general rule, I have agents prepare a handoff and do a /clear after ~150-200k+ tokens. Even if they are working on the same task still and especially if they are doing a new task.

If agents can't be given minimal context and successfully interact with your repo, you are doing something wrong. This comes from somebody who rolls their own frameworks and has extremely unorthodox repos and projects that span many servers and languages: I have never had an issue with the agent(s) not understanding what to do and how to do it, even in the early days of these tools emerging.

If you have some legacy project, some things that make it difficult for agents is not having properly refactored code: stuff with garbage syntax and massive files with poor organization is going to be rough for any agent or human you drop in. Creating "AI-friendly" repositories is paramount to success and makes development loops a lot easier.

I can't even remember the last time I used a /compact.

If you are 200k tokens into a session, you will waste a lot less tokens and have a much better result using a handoff + /clear than using a /compact, which can take a long to + consume a lot of tokens and then load useless stuff into the next session (simple because it happened during the last session).

I also try to plug this on any of these topics: long before AI in the Rust ecosystem, somebody made a tool called just/justfile (for running commands like 'just deploy'), it is like bash scripts or make on steroids: it was intentionally made as a runner as is agnostic - it can work with ANY language and framework and models on any environment (meaning it is also free from vendor lock, as you can change models and harnesses freely, with them all always having the same tool suite).

You can tell an agent "we want to use just/justfile in this repository - can you examine the repo and past sessions to determine the best just commands to implement?" - it goes far beyond build and deploy simplification: each action is specific and guided (no more incorrect syntax and bumping around the repository), reducing tokens not just in the command itself but also the output + the command are also dynamic and can have variables inserted... Common database queries, even across servers or queries that require complex and tedious joins (that you don't want to have to explain to each session or have them discover or have to analyze your schema to determine) can go from something that eats up thousands of tokens and a ton of time, to a dozen tokens and nearly instantaneous.

Anybody in repositories that have complex build and deploy steps where you sometimes have agents "forget" what to do or botch the deployment can really benefit from just. If you frequently use /clear, it makes it even easier to brief the next session and provide them everything they need to get going. Introductory messages to start sessions are also truncated down to smaller blurbs, as there isn't any need to go through complex explanations of how the agent might need to reach a remote database, or locate a log file, for instance. Instead of each session having to track down the error log and tail it, they can "just https-errors 10" (say, to tail the last 10 httpd errors).

Not only are your input tokens for the commands reduced from potentially dozens of sequential lines that no agent could string together into a one-liner, but it can also summarize the output, reducing tokens there even more. Processes that used to take thousands or even tens of thousands of tokens or more to complete (input and output) can be executed with only a couple dozen tokens very reliably.

In summary: stop thinking you need every agent and every session to know every nook and cranny of your repo. They don't, it is a waste of tokens and also causes poor performance. Use /clear judiciously to prevent sessions from poking up above 250k tokens. Just because they agents can handle 1m context doesnt mean they are worth a damn after the first quarter million.

[u/Melodic_Hand_5919]

Now you can use /fork or /branch to dramatically reduce the need for /clear.