WEBVTT 00:00:00.000 --> 00:00:02.080 You're deep into a coding task, right? Oh, yeah. 00:00:02.100 --> 00:00:04.919 We've all been there. The flow state is absolutely 00:00:04.919 --> 00:00:07.120 perfect. You probably have about 50 tabs open. 00:00:07.820 --> 00:00:11.080 That complex API integration is finally making 00:00:11.080 --> 00:00:13.640 sense in your head. You type out the final command 00:00:13.640 --> 00:00:16.359 for your terminal. You ask Claude code to write 00:00:16.359 --> 00:00:19.219 the function. You hit Enter. And then? And suddenly, 00:00:19.539 --> 00:00:22.300 boom, you get a really cold, hard error message. 00:00:22.519 --> 00:00:25.019 You just completely ran out of AI credits. It 00:00:25.019 --> 00:00:27.280 feels like hitting a brick wall. You're going 00:00:27.280 --> 00:00:30.079 at 60 miles an hour. You are just so close to 00:00:30.079 --> 00:00:33.039 the finish line. It really is a brutal wall to 00:00:33.039 --> 00:00:35.579 hit. It almost feels like a nasty subscription 00:00:35.579 --> 00:00:38.159 trap. You're heavily tempted to just pay a little 00:00:38.159 --> 00:00:40.579 more. You just really want to finish the job. 00:00:40.780 --> 00:00:43.780 I completely agree. Welcome to the deep dive. 00:00:44.020 --> 00:00:46.159 We are genuinely so glad you're here with us 00:00:46.159 --> 00:00:48.920 today. OK, let's unpack this. Let's do it. Today, 00:00:48.939 --> 00:00:51.859 we're looking at a comprehensive guide on managing 00:00:51.859 --> 00:00:55.799 clawed code costs. We will explore why those 00:00:55.799 --> 00:00:58.530 costs sneak up on you so quickly. Yeah, they 00:00:58.530 --> 00:01:00.509 really do sneak up. We'll dive into the actual 00:01:00.509 --> 00:01:02.609 mechanics of prompt caching, and we'll cover 00:01:02.609 --> 00:01:04.750 the specific commands to keep your credits from 00:01:04.750 --> 00:01:07.329 draining. This is a vital topic for literally 00:01:07.329 --> 00:01:10.010 any developer, especially if you use command 00:01:10.010 --> 00:01:14.090 line AI tools. Those API costs can spiral incredibly 00:01:14.090 --> 00:01:17.329 fast. Right. So we need to start at the root 00:01:17.329 --> 00:01:20.159 of the problem. We have to understand what we're 00:01:20.159 --> 00:01:23.560 actually paying for. We can't optimize the system 00:01:23.560 --> 00:01:26.379 otherwise. That makes perfect sense. The fundamental 00:01:26.379 --> 00:01:28.400 currency we are dealing with here is tokens. 00:01:28.680 --> 00:01:32.120 Words or code chunks the AI reads and writes. 00:01:32.400 --> 00:01:34.840 Exactly. Now, most of us know tokens are the 00:01:34.840 --> 00:01:37.319 basic processing units, but we often treat them 00:01:37.319 --> 00:01:40.099 like unlimited tap water. Yeah, guilty as charged. 00:01:40.400 --> 00:01:42.840 In Claude code, they act way more like a taxi 00:01:42.840 --> 00:01:45.459 meter, and that meter speeds up the longer the 00:01:45.459 --> 00:01:47.299 ride goes on. That's a really great way to frame 00:01:47.299 --> 00:01:49.989 it. The critical thing to grasp is the asymmetric 00:01:49.989 --> 00:01:52.780 pricing structure. Output tokens almost always 00:01:52.780 --> 00:01:55.879 cost more than input tokens. But the real hidden 00:01:55.879 --> 00:01:58.760 danger isn't just the output. It is the dangerous 00:01:58.760 --> 00:02:01.579 illusion of a short prompt. Let's explore that 00:02:01.579 --> 00:02:03.620 illusion a bit. I type a short question into 00:02:03.620 --> 00:02:06.760 my terminal. I use maybe five or six words. Naturally, 00:02:06.879 --> 00:02:08.840 I assume the transaction is super cheap. You 00:02:08.840 --> 00:02:11.199 would definitely think so. But Claude isn't just 00:02:11.199 --> 00:02:14.639 reading that one tiny sentence. It's processing 00:02:14.639 --> 00:02:17.639 a massive amount of hidden context behind the 00:02:17.639 --> 00:02:21.039 scenes. Two secs silence. The invisible baggage. 00:02:21.259 --> 00:02:23.599 I always assume the AI just looked at my current 00:02:23.599 --> 00:02:25.659 active file. Not at all. It's actually pulling 00:02:25.659 --> 00:02:28.219 in the entire conversation history. It reads 00:02:28.219 --> 00:02:31.199 multiple file contents. It parses all your recent 00:02:31.199 --> 00:02:34.900 command outputs. It scans your entire KaliU .md 00:02:34.900 --> 00:02:38.340 file. It looks at loaded skills. And it constantly 00:02:38.340 --> 00:02:40.860 processes overarching system instructions. It 00:02:40.860 --> 00:02:43.319 carries literally all of that every single time 00:02:43.319 --> 00:02:46.039 you press Enter. Wow. So even a tiny follow -up 00:02:46.039 --> 00:02:48.460 prompt can be incredibly expensive. If your coding 00:02:48.460 --> 00:02:50.319 session has been running for hours, it's bad. 00:02:50.539 --> 00:02:52.879 The model processes all that background data 00:02:52.879 --> 00:02:55.319 all over again. The common analogy is stacking 00:02:55.319 --> 00:02:58.120 Lego blocks of data. Every prompt just adds to 00:02:58.120 --> 00:03:00.979 the tower. But I feel like it's actually worse 00:03:00.979 --> 00:03:03.060 than that. It's like carrying a massive Lego 00:03:03.060 --> 00:03:06.379 tower with you. But you have to physically inspect 00:03:06.379 --> 00:03:08.460 every single block. You have to check them all 00:03:08.460 --> 00:03:10.139 before you're allowed to place the next one on 00:03:10.139 --> 00:03:13.539 top. That's a remarkably accurate visual. The 00:03:13.539 --> 00:03:15.599 tower just keeps growing in the background. You 00:03:15.599 --> 00:03:18.460 don't actively see it, but your wallet is paying 00:03:18.460 --> 00:03:20.960 the toll to carry it. So let me ask you this, 00:03:21.319 --> 00:03:24.800 why do output tokens cost so much more than input 00:03:24.800 --> 00:03:28.020 tokens? It comes down to the underlying architecture 00:03:28.020 --> 00:03:31.300 of large language models. Reading data, which 00:03:31.300 --> 00:03:34.219 is the input, can be heavily parallelized. The 00:03:34.219 --> 00:03:36.879 model processes those tokens simultaneously. 00:03:37.180 --> 00:03:40.620 It is highly computationally efficient. But generating 00:03:40.620 --> 00:03:45.039 brand new reasoning and code, that is an autoregressive 00:03:45.039 --> 00:03:47.020 process. Meaning it happens one step at a time. 00:03:47.139 --> 00:03:49.879 Yes. And that requires much more active processing 00:03:49.879 --> 00:03:52.719 power. The model generates one token, feeds it 00:03:52.719 --> 00:03:55.520 back into itself, and generates the next. Generating 00:03:55.520 --> 00:03:58.000 takes real computational heavy lifting. But generating 00:03:58.000 --> 00:03:59.860 new text is much harder than just reading it. 00:04:00.599 --> 00:04:03.379 Yes. Generating demands continuous sequential 00:04:03.379 --> 00:04:06.199 processing power. building directly from that 00:04:06.199 --> 00:04:09.439 heavy burden of context. If reading old context 00:04:09.439 --> 00:04:13.000 is expensive, how do we mitigate that cost? We 00:04:13.000 --> 00:04:15.500 make the AI remember the context for cheaper. 00:04:15.759 --> 00:04:17.759 We leverage something called prompt caching. 00:04:18.170 --> 00:04:20.889 Let's clarify how that works. Saving past data 00:04:20.889 --> 00:04:23.470 so the AI remembers it instantly. Precisely. 00:04:24.110 --> 00:04:26.509 And Anthropic notes this feature is a massive 00:04:26.509 --> 00:04:29.329 game changer for developers. Cash read tokens 00:04:29.329 --> 00:04:31.930 cost significantly less than normal input tokens. 00:04:32.509 --> 00:04:35.170 Sometimes they're up to 90 % cheaper than starting 00:04:35.170 --> 00:04:37.850 from scratch. I saw some users on X talking about 00:04:37.850 --> 00:04:41.709 this exact workflow. A developer named DXR explains 00:04:41.709 --> 00:04:43.910 it beautifully. He says it dramatically reduces 00:04:43.910 --> 00:04:46.889 both cost and latency. What's fascinating here 00:04:46.889 --> 00:04:49.529 is how much it scales. Another username, truffle, 00:04:49.670 --> 00:04:52.430 notes a very similar experience. Cachex stretched 00:04:52.430 --> 00:04:54.689 your usage allowance much further than cache 00:04:54.689 --> 00:04:57.329 misses. Right. It is basically the secret to 00:04:57.329 --> 00:04:59.850 making your daily quota actually last. Yeah, 00:04:59.930 --> 00:05:02.730 wait, whoa. Imagine caching massive enterprise 00:05:02.730 --> 00:05:04.970 code bases instantly without reprocessing, just 00:05:04.970 --> 00:05:07.410 having gigabytes of context sitting there, perfectly 00:05:07.410 --> 00:05:10.009 primed and ready to go. It really is magic when 00:05:10.009 --> 00:05:12.569 it operates correctly. The speed difference is 00:05:12.569 --> 00:05:15.110 incredible. You ask a question about a massive 00:05:15.110 --> 00:05:18.750 repository, and the answer feels instant. That 00:05:18.750 --> 00:05:22.449 sounds ideal. It is. But there is a real danger 00:05:22.449 --> 00:05:25.589 lurking here. The cache is actually quite fragile. 00:05:25.769 --> 00:05:27.689 Fragile in what way? What actually breaks it? 00:05:28.009 --> 00:05:30.990 The cache relies on strict sequential matching. 00:05:31.449 --> 00:05:34.670 It uses something called prefix caching. The 00:05:34.670 --> 00:05:37.730 AI stores a continuous mathematical representation 00:05:37.730 --> 00:05:40.370 of your context. OK, follow. If you change anything 00:05:40.370 --> 00:05:42.069 at the beginning of that sequence, it's over. 00:05:42.370 --> 00:05:44.870 The prefix corrupts the entire chain that followed. 00:05:44.930 --> 00:05:46.670 It just dumps the memory and starts over from 00:05:46.670 --> 00:05:49.709 scratch. It has to. Changing your setups forces 00:05:49.709 --> 00:05:52.910 Claude code to rebuild the cache entirely. If 00:05:52.910 --> 00:05:55.209 you tweak the cache prefix mid -session, for 00:05:55.209 --> 00:05:58.170 example, it ruins your savings. Ouch. The AI 00:05:58.170 --> 00:06:01.149 has to process that giant LEGO tower from scratch 00:06:01.149 --> 00:06:03.470 again. What is the most common mistake? people 00:06:03.470 --> 00:06:06.069 make that breaks this cache? Fidgeting with their 00:06:06.069 --> 00:06:08.470 environment variables, people change their settings 00:06:08.470 --> 00:06:11.209 or tweak system pre -throws mid -session. They 00:06:11.209 --> 00:06:13.670 do this when they don't absolutely need to. They 00:06:13.670 --> 00:06:16.509 think they are optimizing their workspace, but 00:06:16.509 --> 00:06:19.529 they're actively forcing cache misses. Basically, 00:06:19.790 --> 00:06:21.730 don't change your settings if you don't have 00:06:21.730 --> 00:06:24.949 to. Exactly. Keep your hands off the configuration 00:06:24.949 --> 00:06:27.930 dials once you start working. But we know caching 00:06:27.930 --> 00:06:30.959 doesn't last forever. Sessions inevitably get 00:06:30.959 --> 00:06:33.600 bloated over time, regardless of cash hits. They 00:06:33.600 --> 00:06:36.160 always do. The context window eventually fills 00:06:36.160 --> 00:06:39.720 up. The Lego tower gets too tall and unwieldy. 00:06:39.920 --> 00:06:43.079 So we have to actively prune the history. This 00:06:43.079 --> 00:06:45.279 brings up a really fascinating psychological 00:06:45.279 --> 00:06:47.899 barrier. How do we drop the baggage without losing 00:06:47.899 --> 00:06:50.800 our progress? The guide outlines three specific 00:06:50.800 --> 00:06:53.160 commands for context management. The first is 00:06:53.160 --> 00:06:55.939 a simple command, slash clear. Right, I know 00:06:55.939 --> 00:06:57.879 slash clear. It just starts an entirely empty 00:06:57.879 --> 00:07:00.420 context. But I have to admit something. Oh, yeah. 00:07:00.899 --> 00:07:03.459 I still wrestle with holding onto old context 00:07:03.459 --> 00:07:06.959 myself. I'm kind of a bit of a digital hoarder. 00:07:07.139 --> 00:07:08.920 Yeah, you are definitely not alone in that feeling. 00:07:08.980 --> 00:07:11.079 It is a really hard habit for developers to break. 00:07:11.220 --> 00:07:13.199 I always fear I might need that one random idea 00:07:13.199 --> 00:07:16.019 from an hour ago. I worry the AI will forget 00:07:16.019 --> 00:07:18.399 the nuanced architectural decision we made 20 00:07:18.399 --> 00:07:21.050 prompts back. We treat chat history like a safety 00:07:21.050 --> 00:07:23.930 net because human memory is flawed, but we have 00:07:23.930 --> 00:07:26.750 to learn to trust our actual code base. That's 00:07:26.750 --> 00:07:29.350 tough. If your code base files already hold the 00:07:29.350 --> 00:07:32.149 current project state, the code speaks for itself. 00:07:32.329 --> 00:07:34.189 You just don't need the chat history anymore. 00:07:34.490 --> 00:07:37.310 That requires a real shift in mindset. You have 00:07:37.310 --> 00:07:40.149 to trust that the code contains the truth. But 00:07:40.149 --> 00:07:42.069 what if the code doesn't explain the reasoning? 00:07:42.910 --> 00:07:45.480 What if I really need to preserve the why? behind 00:07:45.480 --> 00:07:47.379 a recent change. Then you move to the second 00:07:47.379 --> 00:07:51.040 method. You use the slash compact command. Ah, 00:07:51.040 --> 00:07:53.139 slash compact. I've seen developers using that 00:07:53.139 --> 00:07:56.439 to shrink their sessions. Yes. Cloud Code essentially 00:07:56.439 --> 00:07:58.439 summarizes the current conversation for you. 00:07:58.699 --> 00:08:01.639 It's ideal for keeping reasoning or architectural 00:08:01.639 --> 00:08:03.779 decisions, especially ones that aren't visible 00:08:03.779 --> 00:08:06.920 in the syntax of the code itself. The guide gives 00:08:06.920 --> 00:08:09.800 a highly specific prompt example for this. You 00:08:09.800 --> 00:08:12.939 type slash compact focus on the API changes, 00:08:13.439 --> 00:08:16.180 key technical decisions, current bugs, and next 00:08:16.180 --> 00:08:18.819 steps. Providing specific instructions to the 00:08:18.819 --> 00:08:21.339 compact command is brilliant. It gives the AI 00:08:21.339 --> 00:08:24.920 a clear constrained focus. This ensures the resulting 00:08:24.920 --> 00:08:27.379 summary doesn't become too general or overly 00:08:27.379 --> 00:08:30.779 vague. It keeps what actually matters and dumps 00:08:30.779 --> 00:08:33.720 the conversational filler. It effectively compresses 00:08:33.720 --> 00:08:36.399 the timeline. But what about when I'm done for 00:08:36.399 --> 00:08:39.519 the day? The third method addresses that scenario 00:08:39.519 --> 00:08:42.299 perfectly. It's called the handoff file. This 00:08:42.299 --> 00:08:45.080 is an incredibly powerful workflow for cross 00:08:45.080 --> 00:08:48.200 -session continuity. You literally prompt Claude 00:08:48.200 --> 00:08:50.960 to create a markdown file. It's typically called 00:08:50.960 --> 00:08:54.080 handoff .md. Let's walk through that scenario. 00:08:54.340 --> 00:08:56.940 It's Friday evening. I'm completely exhausted. 00:08:57.360 --> 00:08:59.639 I have half -finished functions scattered everywhere. 00:08:59.940 --> 00:09:02.580 I ask Claude to write the handoff file. What 00:09:02.580 --> 00:09:04.679 goes into it? You instruct the AI to document 00:09:04.679 --> 00:09:07.659 the exact project status. You have it list all 00:09:07.659 --> 00:09:10.179 completed work from the session. Right. You meticulously 00:09:10.179 --> 00:09:13.039 list any unresolved bugs, failing tests, and 00:09:13.039 --> 00:09:15.080 clear next steps. It's like leaving a detailed 00:09:15.080 --> 00:09:17.620 technical note for your future self. Yes, exactly. 00:09:18.240 --> 00:09:19.980 Then when you start a brand new clean session 00:09:19.980 --> 00:09:21.860 on Monday morning, you just ask Claude to read 00:09:21.860 --> 00:09:24.700 that handoff .md file first. It gets the new 00:09:24.700 --> 00:09:27.639 session up to speed instantly. And it does it 00:09:27.639 --> 00:09:30.639 without carrying 50 pages of Friday's conversational 00:09:30.639 --> 00:09:33.639 baggage. It creates a clean slate while preserving 00:09:33.639 --> 00:09:36.399 your technical momentum. How do you decide between 00:09:36.399 --> 00:09:39.059 using Compact and just making a handoff file? 00:09:39.679 --> 00:09:42.039 Compact is really for mid -session spring cleaning. 00:09:42.879 --> 00:09:45.039 It's for when you want to keep coding right now. 00:09:45.379 --> 00:09:48.059 A handoff file is for pausing your work entirely. 00:09:48.679 --> 00:09:50.399 You use it to pick up the work in a brand new 00:09:50.399 --> 00:09:53.279 session tomorrow. Compact is for right now. Handoff 00:09:53.279 --> 00:09:56.000 is for a fresh start. That perfectly captures 00:09:56.000 --> 00:09:58.100 the functional difference between the two commands. 00:09:58.620 --> 00:10:01.419 So we've cleaned out the chat history. Our context 00:10:01.419 --> 00:10:04.580 is pruned. But you could still be bleeding credits 00:10:04.580 --> 00:10:06.820 before you even type your first prompt. We have 00:10:06.820 --> 00:10:08.980 to look at your baseline environment. A perfectly 00:10:08.980 --> 00:10:11.360 pruned history doesn't matter if your foundational 00:10:11.360 --> 00:10:14.120 setup is bloated. Which brings us to model routing. 00:10:14.740 --> 00:10:17.179 Throwing the heaviest, most expensive AI model 00:10:17.179 --> 00:10:20.279 at a simple task. is a massive waste of credits. 00:10:20.600 --> 00:10:22.860 Model routing is rapidly becoming a mandatory 00:10:22.860 --> 00:10:25.879 developer skill. You simply cannot use the strongest, 00:10:25.960 --> 00:10:28.320 most expensive option for every single thing 00:10:28.320 --> 00:10:31.220 you do. The guide suggests using Clot Opus for 00:10:31.220 --> 00:10:34.580 complex bugs. It's highly capable for architecture 00:10:34.580 --> 00:10:37.820 and broad project planning. Opus is an absolute 00:10:37.820 --> 00:10:40.299 powerhouse. But once the plan is set, you need 00:10:40.299 --> 00:10:42.879 to switch to a lighter model. Like Sonnet. Yeah, 00:10:43.080 --> 00:10:45.139 use Sonnet for simpler execution. It's kind of 00:10:45.139 --> 00:10:47.139 like hiring a senior architectural engineer to 00:10:47.139 --> 00:10:49.519 come paint your fence. The engineer will definitely 00:10:49.519 --> 00:10:52.360 get the job done, but their hourly rate is going 00:10:52.360 --> 00:10:55.440 to bankrupt you. That is a hilarious and painful 00:10:55.440 --> 00:10:58.960 reality. Sonnet is fantastic for routine execution. 00:10:59.299 --> 00:11:01.419 It handles standard refactoring and boilerplate 00:11:01.419 --> 00:11:04.460 generation beautifully. Right. Reserve opus for 00:11:04.460 --> 00:11:07.120 when you are truly stuck on a deep logical flaw. 00:11:07.559 --> 00:11:10.149 We also need to talk about setup hygiene. Let's 00:11:10.149 --> 00:11:12.129 look at what's silently loading in the background. 00:11:12.769 --> 00:11:15.549 Your clayRD .md file shouldn't just repeat your 00:11:15.549 --> 00:11:18.029 repository data. Your system prompts need to 00:11:18.029 --> 00:11:20.919 be relentlessly concise. If your markdown file 00:11:20.919 --> 00:11:23.259 endlessly repeats data the AI can already read 00:11:23.259 --> 00:11:25.419 in the code base, you have a problem. You are 00:11:25.419 --> 00:11:28.440 wasting tokens on every single interaction. Use 00:11:28.440 --> 00:11:30.919 the slash context command constantly. It helps 00:11:30.919 --> 00:11:33.279 you see exactly what files and instructions are 00:11:33.279 --> 00:11:36.139 actively eating your token budget. Another fantastic 00:11:36.139 --> 00:11:38.440 tool mentioned in the guide is the slash doctor 00:11:38.440 --> 00:11:41.179 command. This actually comes as a tip from an 00:11:41.179 --> 00:11:43.799 internal Anthropic team member. How does the 00:11:43.799 --> 00:11:46.679 doctor command work in practice? You run slash 00:11:46.679 --> 00:11:49.500 doctor to analyze your current workspace. It 00:11:49.500 --> 00:11:52.120 helps you right size your included files. It 00:11:52.120 --> 00:11:54.360 reviews your configurations and helps you clean 00:11:54.360 --> 00:11:56.779 house. Before you start racking up heavy API 00:11:56.779 --> 00:11:59.720 charges. Exactly. And then there is the very 00:11:59.720 --> 00:12:03.679 tricky issue of MCPs. Ah! Model context protocol 00:12:03.679 --> 00:12:06.639 servers, extra tools that let the AI do specific 00:12:06.639 --> 00:12:09.080 tasks. Right. They allow Claude to interact with 00:12:09.080 --> 00:12:11.620 your local environment, databases, or external 00:12:11.620 --> 00:12:14.980 APIs. The guide strongly advises keeping MCPs 00:12:14.980 --> 00:12:17.799 and loaded plugins lean. It cites developers 00:12:17.799 --> 00:12:21.139 Milogy and Nate Hurk. They point out that having 00:12:21.139 --> 00:12:24.139 too many active skills adds massive context overhead. 00:12:24.320 --> 00:12:26.779 It is a huge strain. Here's where it gets really 00:12:26.779 --> 00:12:28.899 interesting. I always assumed unused plugins 00:12:28.899 --> 00:12:31.419 were just dormant code on my hard drive. Are 00:12:31.419 --> 00:12:34.220 extra plugins really that harmful? Oh, absolutely. 00:12:34.700 --> 00:12:36.120 I mean, they are just sitting there. They aren't 00:12:36.120 --> 00:12:38.159 doing anything until I actually call them. That 00:12:38.159 --> 00:12:40.360 is the most common trap developers fall into. 00:12:40.460 --> 00:12:42.139 They aren't just sitting quietly on your hard 00:12:42.139 --> 00:12:45.659 drive. They create constant, heavy context overhead. 00:12:46.139 --> 00:12:49.000 I need to understand that mechanism better. Are 00:12:49.000 --> 00:12:51.539 you saying Claude is actively holding the instruction 00:12:51.539 --> 00:12:53.960 manual for every plugin in its active memory? 00:12:54.379 --> 00:12:56.879 Just in case I ask for it. That is precisely 00:12:56.879 --> 00:12:59.059 what is happening. Even if you aren't actively 00:12:59.059 --> 00:13:02.059 using a tool in your current prompt, its instructions 00:13:02.059 --> 00:13:04.960 are loaded. Its functional definitions and parameters 00:13:04.960 --> 00:13:07.539 are injected right into the context window. It 00:13:07.539 --> 00:13:10.039 takes up highly valuable token space. It's more 00:13:10.039 --> 00:13:12.100 that invisible baggage we talked about earlier. 00:13:12.379 --> 00:13:14.399 Claude has to process those tool definitions 00:13:14.399 --> 00:13:16.759 with every single prompt you send, whether you 00:13:16.759 --> 00:13:19.480 use them or not. Yep. So do tools you aren't 00:13:19.480 --> 00:13:22.440 actively using in a prompt still eat up your 00:13:22.440 --> 00:13:25.200 tokens? Yes, they absolutely do. Loaded skills 00:13:25.200 --> 00:13:28.200 and idle MCP servers constantly occupy space 00:13:28.200 --> 00:13:31.220 in the background context. They slowly and silently 00:13:31.220 --> 00:13:33.679 drain your credits with every enter key press. 00:13:33.919 --> 00:13:36.460 More tools mean less room for your actual project 00:13:36.460 --> 00:13:39.159 code. Less room for code, and a significantly 00:13:39.159 --> 00:13:41.639 higher recurring cost for you. And before we 00:13:41.639 --> 00:13:43.659 wrap up today's deep dive, we'll take a quick 00:13:43.659 --> 00:13:49.970 break. Sponsor. And we're back. So if we synthesize 00:13:49.970 --> 00:13:53.269 all of these tactics, a very clear, golden workflow 00:13:53.269 --> 00:13:55.990 emerges for developers. It really does. It requires 00:13:55.990 --> 00:13:58.850 continuous, intentional management of your workspace. 00:13:59.330 --> 00:14:02.110 Keep the cache warm by maintaining stable prefixes. 00:14:02.590 --> 00:14:05.049 Don't tweak your settings unnecessarily mid -session. 00:14:05.269 --> 00:14:07.809 Prune your context early and often. Overcome 00:14:07.809 --> 00:14:10.529 the fear of deleting history. Use slash compact 00:14:10.529 --> 00:14:13.029 or slash clear before the session gets bloated. 00:14:13.190 --> 00:14:15.960 Trust your actual code base. Root your highly 00:14:15.960 --> 00:14:19.240 complex planning tasks to Opus. Move your simple 00:14:19.240 --> 00:14:21.879 execution and refactoring tasks to Sonnet. And 00:14:21.879 --> 00:14:24.200 make sure to run slash doctor to keep your background 00:14:24.200 --> 00:14:26.779 plugins incredibly lean. So what does this all 00:14:26.779 --> 00:14:29.679 mean? As our personal code bases grow and as 00:14:29.679 --> 00:14:32.139 AI context windows expand infinitely larger, 00:14:32.600 --> 00:14:35.019 things change. The ultimate skill for a software 00:14:35.019 --> 00:14:37.879 developer won't just be writing code, beat. It 00:14:37.879 --> 00:14:40.299 will be mastering the exact precise art of what 00:14:40.299 --> 00:14:42.769 to make the AI forget. If we connect this to 00:14:42.769 --> 00:14:45.169 the bigger picture, that is a deeply powerful 00:14:45.169 --> 00:14:47.970 thought to end on. In an age of endless digital 00:14:47.970 --> 00:14:50.850 memory, intentional forgetting is a crucial feature, 00:14:51.190 --> 00:14:53.549 not a bug. Thank you for joining us on this deep 00:14:53.549 --> 00:14:55.669 dive. We really hope this saves you some serious 00:14:55.669 --> 00:14:58.529 API credits this week. Stay curious and keep 00:14:58.529 --> 00:15:01.289 those context windows ruthlessly clean. O -U 00:15:01.289 --> 00:15:02.250 -T -O music.