WEBVTT 00:00:00.000 --> 00:00:04.900 91 million tokens saved in one single day. Over 00:00:04.900 --> 00:00:08.519 300 million tokens saved in just a week. And 00:00:08.519 --> 00:00:11.039 it was not achieved by upgrading massive server 00:00:11.039 --> 00:00:13.839 hardware. You achieve this simply by changing 00:00:13.839 --> 00:00:16.539 how an AI remembers. Yeah, that scale of efficiency 00:00:16.539 --> 00:00:19.559 is truly hard to comprehend. It fundamentally 00:00:19.559 --> 00:00:21.760 changes the math for modern software development. 00:00:22.100 --> 00:00:24.850 Welcome to the Deep Dive. We are cracking open 00:00:24.850 --> 00:00:27.890 the mechanics of Cloud Code today. Our core mission 00:00:27.890 --> 00:00:31.230 is mastering prompt caching together. We are 00:00:31.230 --> 00:00:34.009 going to help you achieve massive token efficiency. 00:00:34.369 --> 00:00:36.549 It is a total game changer for active workflows. 00:00:36.869 --> 00:00:39.109 We will cover what caching actually is first. 00:00:39.609 --> 00:00:41.909 Then we will explore the hidden pricing mechanics 00:00:41.909 --> 00:00:43.890 driving this technology. Right, and we will look 00:00:43.890 --> 00:00:45.829 at what secretly shatters your cache. And we 00:00:45.829 --> 00:00:48.869 will build daily habits to keep it intact. Beat. 00:00:49.170 --> 00:00:51.229 Let us begin. Awesome. Let us jump right in. 00:00:51.450 --> 00:00:53.289 We need to establish the baseline problem right 00:00:53.289 --> 00:00:56.729 away. Long AI sessions eat up your tokens incredibly 00:00:56.729 --> 00:00:59.009 fast. They really do. It gets expensive very 00:00:59.009 --> 00:01:01.710 quickly. Tokens are the basic text units in AI 00:01:01.710 --> 00:01:04.450 reads. A single word might be broken into three 00:01:04.450 --> 00:01:08.689 separate tokens. Exactly. So long projects consume 00:01:08.689 --> 00:01:11.909 millions of tokens very rapidly. This becomes 00:01:11.909 --> 00:01:14.530 incredibly expensive over a standard work week. 00:01:14.859 --> 00:01:17.640 Caching solves this massive financial problem 00:01:17.640 --> 00:01:20.200 for active developers. Yeah, because without 00:01:20.200 --> 00:01:23.920 caching, Claude processes everything completely 00:01:23.920 --> 00:01:26.680 from scratch. It happens every single time you 00:01:26.680 --> 00:01:29.560 send a new prompt. Standard AI is like a brilliant 00:01:29.560 --> 00:01:32.060 but amnesic assistant. That is a great way to 00:01:32.060 --> 00:01:33.980 put it. Every time you ask a simple follow -up 00:01:33.980 --> 00:01:36.599 question, they forget. They have to reread the 00:01:36.599 --> 00:01:39.280 entire manual from page one. Right. It essentially 00:01:39.280 --> 00:01:41.459 forgets everything immediately after responding 00:01:41.459 --> 00:01:44.260 to you. That requires massive computational power 00:01:44.260 --> 00:01:47.500 for every single interaction. Exactly. It reads 00:01:47.500 --> 00:01:49.519 the whole context again from the very beginning. 00:01:49.920 --> 00:01:53.560 But prompt caching reuses frequently used context 00:01:53.560 --> 00:01:56.000 instead of rereading it. It is like handing that 00:01:56.000 --> 00:01:58.040 and music assistant a physical bookmark. They 00:01:58.040 --> 00:02:00.239 keep the manual open right on the desk. And when 00:02:00.239 --> 00:02:02.219 you ask the next question, they just keep reading. 00:02:02.280 --> 00:02:04.799 They only read the brand new sentence you handed 00:02:04.799 --> 00:02:07.120 them. That drastically changes how developers 00:02:07.120 --> 00:02:11.009 approach complex coding tasks. Let us use a hypothetical 00:02:11.009 --> 00:02:14.449 developer named Sarah for context. Sarah loads 00:02:14.449 --> 00:02:18.389 50 pages of dense API documentation into Claude. 00:02:18.590 --> 00:02:21.430 Which is easily over 100 ,000 tokens of text. 00:02:21.669 --> 00:02:24.289 Under the old system, Sarah pays for those tokens 00:02:24.289 --> 00:02:27.110 repeatedly. She asks a question about the code 00:02:27.110 --> 00:02:30.810 architecture. The AI reads all 100 ,000 tokens. 00:02:31.069 --> 00:02:33.550 She asks a second question about a specific bug. 00:02:34.229 --> 00:02:37.370 The AI reads all 100 ,000 tokens again. It is 00:02:37.419 --> 00:02:39.740 terribly inefficient when you think deeply about 00:02:39.740 --> 00:02:42.400 it. Normal processing is very wasteful and highly 00:02:42.400 --> 00:02:44.680 repetitive. Yeah, that is exactly how standard 00:02:44.680 --> 00:02:47.699 AI models operate today. Caching is much smarter 00:02:47.699 --> 00:02:50.460 and far more elegant. It is like stacking Lego 00:02:50.460 --> 00:02:52.939 blocks of data seamlessly together. They stay 00:02:52.939 --> 00:02:55.300 perfectly in place for your very next move. Right. 00:02:55.400 --> 00:02:57.199 And we have two incredibly important metrics 00:02:57.199 --> 00:02:59.460 here. First, we have the cash rope metric to 00:02:59.460 --> 00:03:01.840 consider. You write new context into the cash 00:03:01.840 --> 00:03:04.099 at a premium. Second, we have the cash read metric 00:03:04.099 --> 00:03:07.360 to heavily monitor. You reuse that cashed context 00:03:07.360 --> 00:03:09.840 at a massive financial discount. You pay about 00:03:09.840 --> 00:03:12.900 10 % of the normal input cost. Yeah, the payoff 00:03:12.900 --> 00:03:16.240 is absolute huge for daily users. You get drastically 00:03:16.240 --> 00:03:18.620 faster response times across the entire board. 00:03:18.860 --> 00:03:21.400 The time to first token drops significantly during 00:03:21.400 --> 00:03:23.939 your daily workflow. Exactly. You can run much 00:03:23.939 --> 00:03:26.340 longer sessions without experiencing token blow. 00:03:26.460 --> 00:03:31.240 Whoa. Imagine scaling to a billion queries. The 00:03:31.240 --> 00:03:34.039 savings would be absolutely astronomical for 00:03:34.039 --> 00:03:37.039 a modern enterprise. The cost difference fundamentally 00:03:37.039 --> 00:03:40.520 changes how you build complex software. It allows 00:03:40.520 --> 00:03:43.080 developers to build rich, persistent environments. 00:03:43.340 --> 00:03:45.680 How exactly do you know if caching is actually 00:03:45.680 --> 00:03:48.039 active? You simply check the dashboard visual 00:03:48.039 --> 00:03:50.860 indicators during your session. You look closely 00:03:50.860 --> 00:03:53.159 to see the cache read numbers climbing. So the 00:03:53.159 --> 00:03:55.639 dashboard proves it when those read numbers climb. 00:03:55.860 --> 00:03:57.819 That is exactly right. Reading from the cache 00:03:57.819 --> 00:04:01.539 clearly saves you a lot of money. Yeah. How exactly 00:04:01.539 --> 00:04:03.659 does the pricing model make that happen? Well, 00:04:03.659 --> 00:04:06.139 it works best when handling a very large context. 00:04:06.199 --> 00:04:08.020 You provide that massive amount of information 00:04:08.020 --> 00:04:11.039 just one time. Then you reference it repeatedly 00:04:11.039 --> 00:04:13.300 during your ongoing daily work. Yeah, exactly. 00:04:13.560 --> 00:04:16.300 We need to clearly define context here for a 00:04:16.300 --> 00:04:19.220 moment. Context means the background information 00:04:19.220 --> 00:04:23.540 you feed the AI directly. Coding assistants use 00:04:23.540 --> 00:04:25.800 this feature perfectly in their automated workflows. 00:04:26.639 --> 00:04:28.740 Knowledge bases and agent workflows use it incredibly 00:04:28.740 --> 00:04:32.040 well too. Let us look at Sarah and her API documentation 00:04:32.040 --> 00:04:35.660 again. She uploads the entire 50 page document 00:04:35.660 --> 00:04:38.019 just one time. Right. She writes that massive 00:04:38.019 --> 00:04:40.759 document into the cache initially. Let us look 00:04:40.759 --> 00:04:43.480 closely at the actual hard financial numbers. 00:04:43.839 --> 00:04:47.399 For Claude 3 .5 Sonnet, base input tokens cost 00:04:47.399 --> 00:04:51.699 $3. That is $3 per million standard input tokens. 00:04:51.779 --> 00:04:55.839 The cash write cost $3 .75. That is exactly 25 00:04:55.839 --> 00:04:58.300 % higher than the standard base. Yeah, you pay 00:04:58.300 --> 00:05:00.829 a premium to store that data in memory. The cash 00:05:00.829 --> 00:05:03.509 read costs only 30 cents per million tokens. 00:05:03.970 --> 00:05:06.389 That is just 10 % of the normal base costs. This 00:05:06.389 --> 00:05:09.389 can reduce overall costs by up to 90%. I want 00:05:09.389 --> 00:05:11.050 to push back on this pricing model slightly. 00:05:11.370 --> 00:05:14.629 That 25 % higher write cost is an upfront tax. 00:05:14.829 --> 00:05:17.649 Ah, sure. That is fair. Does the math always 00:05:17.649 --> 00:05:20.529 work out favorably for shorter tasks? If Sarah 00:05:20.529 --> 00:05:22.990 only needs a quick snippet, she loses money. 00:05:23.350 --> 00:05:26.019 That is a very valid point to consider. The math 00:05:26.019 --> 00:05:28.600 fails if you only ask one quick question. You 00:05:28.600 --> 00:05:31.100 need a slightly longer conversation to see real 00:05:31.100 --> 00:05:33.360 benefits. Exactly. The cache is designed for 00:05:33.360 --> 00:05:36.230 sustained interactive problem solving. Where 00:05:36.230 --> 00:05:39.250 exactly does the break -even point hit for that 00:05:39.250 --> 00:05:41.910 tax? Usually after you ask your very first or 00:05:41.910 --> 00:05:44.670 second follow -up question, the cheap reads quickly 00:05:44.670 --> 00:05:47.370 overcome that initial higher write cost. It pays 00:05:47.370 --> 00:05:49.269 for itself by the second follow -up question. 00:05:49.430 --> 00:05:51.949 Exactly, yes. If reading cash is so cheap, why 00:05:51.949 --> 00:05:54.149 not cash everything forever? Two -sec silence. 00:05:54.389 --> 00:05:56.290 Because the cash is actually highly fragile. 00:05:56.350 --> 00:05:58.670 It breaks very easily if you are not extremely 00:05:58.670 --> 00:06:00.829 careful. We need to talk about why these companies 00:06:00.829 --> 00:06:04.449 drop it. The cash lives on incredibly expensive 00:06:04.449 --> 00:06:07.339 server graphics cards. Right. It holds the mathematical 00:06:07.339 --> 00:06:10.259 representations of your text in memory. That 00:06:10.259 --> 00:06:12.759 memory is finite and highly contested by other 00:06:12.759 --> 00:06:15.240 users. The server has to clear it to save massive 00:06:15.240 --> 00:06:19.370 compute costs. Exactly. Cache expiration is a 00:06:19.370 --> 00:06:22.290 major problem for most typical users. Cached 00:06:22.290 --> 00:06:25.310 content naturally expires after a period of user 00:06:25.310 --> 00:06:27.329 inactivity. You lose everything you just saved 00:06:27.329 --> 00:06:30.350 by stepping away briefly. Yeah. Switching models 00:06:30.350 --> 00:06:33.069 during a session also resets the board entirely. 00:06:33.810 --> 00:06:36.730 Each AI model uses its own completely separate 00:06:36.730 --> 00:06:40.009 proprietary cache. Changing system level instructions 00:06:40.009 --> 00:06:43.029 forces a total cache rebuild as well. System 00:06:43.029 --> 00:06:45.449 instructions are hidden rules telling AI how 00:06:45.449 --> 00:06:48.050 to act. Here is where it gets incredibly technical 00:06:48.050 --> 00:06:51.889 and fascinating. How does the AI actually read 00:06:51.889 --> 00:06:54.350 the cached memory? It uses something called prefix 00:06:54.350 --> 00:06:56.790 matching to verify the data. Right. It reads 00:06:56.790 --> 00:06:59.310 your document strictly from top to bottom. It 00:06:59.310 --> 00:07:01.649 compares your new prompt against its saved memory 00:07:01.649 --> 00:07:03.870 cache. It looks for an exact match from the very 00:07:03.870 --> 00:07:06.029 beginning. If the first hundred sentences match 00:07:06.029 --> 00:07:08.980 perfectly, it uses cache. But if you change just 00:07:08.980 --> 00:07:11.100 one word at the top, the match breaks immediately 00:07:11.100 --> 00:07:13.220 for the rest of the document. Exactly. The AI 00:07:13.220 --> 00:07:15.540 throws out everything below that tiny text change. 00:07:15.600 --> 00:07:17.459 It has to rebuild the entire memory structure 00:07:17.459 --> 00:07:20.339 completely again. Pasting huge documents into 00:07:20.339 --> 00:07:23.660 a normal chat randomly ruins it. It completely 00:07:23.660 --> 00:07:25.959 breaks that strict top -to -bottom sequential 00:07:25.959 --> 00:07:29.259 matching process. Mixing unrelated tasks in one 00:07:29.259 --> 00:07:31.579 session destroys token efficiency completely. 00:07:32.079 --> 00:07:33.860 Let us look back at Sarah for a quick moment. 00:07:34.259 --> 00:07:37.060 She is coding a complex backend server in her 00:07:37.060 --> 00:07:39.850 chat window. Then she randomly asks the AI for 00:07:39.850 --> 00:07:43.170 a soup recipe. Mixing tasks is very chaotic and 00:07:43.170 --> 00:07:45.790 highly counterproductive overall. The AI gets 00:07:45.790 --> 00:07:48.589 confused by the heavily conflicting user context. 00:07:48.709 --> 00:07:51.050 It is like cooking a gourmet meal on a table. 00:07:51.410 --> 00:07:53.069 But you're also trying to fix a bicycle there. 00:07:53.110 --> 00:07:55.410 Right. At the exact same time. It makes no sense. 00:07:55.470 --> 00:07:57.709 I still wrestle with prompt drift myself, to 00:07:57.709 --> 00:07:59.850 be honest. I slowly change the topic without 00:07:59.850 --> 00:08:01.889 even realizing it happening. We all do it during 00:08:01.889 --> 00:08:04.490 long exploratory chat sessions, naturally. The 00:08:04.490 --> 00:08:06.769 general rule is to keep the session highly focused. 00:08:06.939 --> 00:08:09.079 The core context should really change as little 00:08:09.079 --> 00:08:11.300 as possible. How long does the period of inactivity 00:08:11.300 --> 00:08:14.279 last before expiring? It typically lasts around 00:08:14.279 --> 00:08:16.819 five minutes for these specific models. You only 00:08:16.819 --> 00:08:18.800 get a strict five minutes of inactivity. Yeah, 00:08:18.939 --> 00:08:21.220 the clock ticks fast. We will pause right here 00:08:21.220 --> 00:08:24.060 for a brief sponsor message. Mid -roll sponsor, 00:08:24.220 --> 00:08:26.779 re -drill placeholder. And we are back to our 00:08:26.779 --> 00:08:29.319 deep dive. Let us get back into it. Since the 00:08:29.319 --> 00:08:31.980 cache breaks easily, how do we actively protect 00:08:31.980 --> 00:08:35.909 it? We must adopt very specific user habits every 00:08:35.909 --> 00:08:39.070 single day. Exactly. Habit one is to keep your 00:08:39.070 --> 00:08:42.149 sessions intensely focused. Habit one requires 00:08:42.149 --> 00:08:45.090 serious mental discipline from you. Think of 00:08:45.090 --> 00:08:47.250 your chat window like a dedicated meeting room. 00:08:47.730 --> 00:08:50.490 If you are reviewing API code, stay strictly 00:08:50.490 --> 00:08:53.370 on code. Do not invite completely irrelevant 00:08:53.370 --> 00:08:56.350 topics into that specific room. If Sarah is doing 00:08:56.350 --> 00:08:59.080 an API reliability review, she stays there. She 00:08:59.080 --> 00:09:01.360 actively looks for major bottlenecks and critical 00:09:01.360 --> 00:09:03.919 security flaws. The second she asks for marketing 00:09:03.919 --> 00:09:06.580 copy, she ruins everything. She forces the AI 00:09:06.580 --> 00:09:09.240 to load entirely new mental frameworks. Habit 00:09:09.240 --> 00:09:11.059 two is using the clear command when switching 00:09:11.059 --> 00:09:13.980 tasks. You type forward slash clear into the 00:09:13.980 --> 00:09:16.360 active command prompt window. Say you move from 00:09:16.360 --> 00:09:18.700 backend code to a sauce marketing framework. 00:09:19.179 --> 00:09:21.419 Clearing removes all the irrelevant context immediately 00:09:21.419 --> 00:09:24.080 from the session. I questioned the emotional 00:09:24.080 --> 00:09:26.360 friction of that specific command. Oh really? 00:09:26.509 --> 00:09:29.289 Why is that? You spend hours building up this 00:09:29.289 --> 00:09:32.610 incredibly rich technical context. Deleting it 00:09:32.610 --> 00:09:34.769 feels like throwing away your hard -earned progress. 00:09:34.870 --> 00:09:37.350 Ah, yeah. I see. It feels deeply unnatural to 00:09:37.350 --> 00:09:40.809 wipe the slate totally clean. I completely understand 00:09:40.809 --> 00:09:44.299 that natural hesitation you were feeling. But 00:09:44.299 --> 00:09:46.799 the AI does not think like a human does. It gets 00:09:46.799 --> 00:09:49.600 confused by the old context hanging around uselessly. 00:09:49.860 --> 00:09:52.740 Right. Clearing gives the AI a clean and fresh 00:09:52.740 --> 00:09:55.620 starting point. It stops the old technical context 00:09:55.620 --> 00:09:58.059 from confusing the new task. Habit 3 is using 00:09:58.059 --> 00:10:00.919 session handoffs for much longer projects. For 00:10:00.919 --> 00:10:03.799 projects lasting days, prompt Quad to write a 00:10:03.799 --> 00:10:06.639 summary. Ask it for a handoff document detailing 00:10:06.639 --> 00:10:08.860 all the work. Do this before you clear the active 00:10:08.860 --> 00:10:11.039 session entirely. The summary must include the 00:10:11.039 --> 00:10:13.450 project overview and completed work. It needs 00:10:13.450 --> 00:10:16.129 important files, known open issues, and recommended 00:10:16.129 --> 00:10:18.490 actions. You simply paste this detailed summary 00:10:18.490 --> 00:10:21.190 into your brand new session. It serves as a highly 00:10:21.190 --> 00:10:23.889 compressed memory for the AI. Bonus habits include 00:10:23.889 --> 00:10:26.210 using the project's feature for large documents. 00:10:26.750 --> 00:10:29.350 This dedicated feature manages background context 00:10:29.350 --> 00:10:31.870 much better than chat. Right, and try to stay 00:10:31.870 --> 00:10:34.330 within the cache window time limit. Keep the 00:10:34.330 --> 00:10:36.570 workflow moving smoothly without taking overly 00:10:36.570 --> 00:10:39.710 long breaks. This prevents the server from purging 00:10:39.710 --> 00:10:42.980 your data from memory. Does pasting that handoff 00:10:42.980 --> 00:10:46.039 document trigger a new write charge? Yes, it 00:10:46.039 --> 00:10:47.779 absolutely triggers a brand new write charge 00:10:47.779 --> 00:10:51.059 immediately. But summarizing shrinks the context 00:10:51.059 --> 00:10:54.159 down, making the charge tiny. You pay a tiny 00:10:54.159 --> 00:10:57.120 fee to save a massive one. Exactly. It is highly 00:10:57.120 --> 00:10:59.399 strategic. You can build these great habits easily 00:10:59.399 --> 00:11:01.720 over enough time. But how do you know if they're 00:11:01.720 --> 00:11:04.389 actually working? You have to measure the invisible 00:11:04.389 --> 00:11:06.529 mechanics behind the scenes. Two -sex silence. 00:11:07.269 --> 00:11:09.710 You need to use the forward slash usage command 00:11:09.710 --> 00:11:13.470 very frequently. It reveals several crucial hidden 00:11:13.470 --> 00:11:16.389 metrics for your current active session. It clearly 00:11:16.389 --> 00:11:18.809 shows your total input tokens and output tokens. 00:11:19.179 --> 00:11:21.960 The command also shows cache read, cache write, 00:11:22.100 --> 00:11:24.399 and total usage. There's a vital golden rule 00:11:24.399 --> 00:11:26.940 to remember right here. If cache read continues 00:11:26.940 --> 00:11:29.360 to increase, caching is working perfectly. You 00:11:29.360 --> 00:11:32.559 must be using the exact same context across requests. 00:11:32.960 --> 00:11:35.039 Token dashboards are also incredibly helpful 00:11:35.039 --> 00:11:37.679 for tracking this raw data. You can build your 00:11:37.679 --> 00:11:40.419 own token dashboard over time easily. Yeah, it 00:11:40.419 --> 00:11:42.779 requires pulling data directly from your API 00:11:42.779 --> 00:11:46.159 usage logs. This helps you visualize the completely 00:11:46.159 --> 00:11:48.840 unseen costs of your work. They track your token 00:11:48.840 --> 00:11:51.519 usage across different models over time. They 00:11:51.519 --> 00:11:53.899 help you find your most expensive sessions very 00:11:53.899 --> 00:11:56.240 easily. You start to notice clear usage patterns 00:11:56.240 --> 00:11:59.320 quite quickly. Focus sessions are always highly 00:11:59.320 --> 00:12:01.799 efficient with their token consumption. Large 00:12:01.799 --> 00:12:05.240 context changes create massive usage spikes almost 00:12:05.240 --> 00:12:08.440 instantly. Seeing the actual metrics fundamentally 00:12:08.440 --> 00:12:11.000 changes your daily user behavior. It really does. 00:12:11.039 --> 00:12:13.710 You wake up. You shift from a passive user to 00:12:13.710 --> 00:12:16.830 an active manager. You actively shape the memory 00:12:16.830 --> 00:12:19.590 environment for your AI assistant. You stop wasting 00:12:19.590 --> 00:12:22.250 expensive tokens blindly on poorly structured 00:12:22.250 --> 00:12:25.210 prompts. You learn to format documents to maximize 00:12:25.210 --> 00:12:27.669 that prefix matching mechanism. Which single 00:12:27.669 --> 00:12:30.129 metric is the ultimate red flag for a broken 00:12:30.129 --> 00:12:32.870 cache? A sudden massive spike in the cache write 00:12:32.870 --> 00:12:35.350 metric mid -session. A sudden cache write spike 00:12:35.350 --> 00:12:38.190 means you accidentally rebuilt everything. Exactly. 00:12:38.250 --> 00:12:41.009 You broke the chain. Let us firmly connect this 00:12:41.009 --> 00:12:43.649 back to the much bigger picture. Prompt caching 00:12:43.649 --> 00:12:47.070 turns AI from an amnesiac you constantly reeducate. 00:12:47.529 --> 00:12:50.169 It becomes a highly focused, extremely cost -effective 00:12:50.169 --> 00:12:52.570 collaborator for your projects. But this only 00:12:52.570 --> 00:12:55.309 works if you curate its memory space carefully. 00:12:55.629 --> 00:12:58.710 Right. You must manage its context window with 00:12:58.710 --> 00:13:01.590 very serious intention. Beat. That brings us 00:13:01.590 --> 00:13:04.460 to a lingering thought for today. What happens 00:13:04.460 --> 00:13:07.519 to human creativity when AI memory becomes truly 00:13:07.519 --> 00:13:10.700 infinite? That is a wild concept to think about. 00:13:10.860 --> 00:13:13.139 Imagine when our digital assistants never forget 00:13:13.139 --> 00:13:16.100 a single thought ever. Will we rely entirely 00:13:16.100 --> 00:13:19.220 on them to connect our own ideas? That is a profoundly 00:13:19.220 --> 00:13:22.080 interesting question to deeply consider. It fundamentally 00:13:22.080 --> 00:13:24.240 changes the entire nature of human -computer 00:13:24.240 --> 00:13:26.600 interaction. We highly encourage you to run the 00:13:26.600 --> 00:13:28.659 usage command next time. Do this in your very 00:13:28.659 --> 00:13:31.080 next CLOD session this week. See your own hidden 00:13:31.080 --> 00:13:33.539 token numbers clearly for yourself. Thank you 00:13:33.539 --> 00:13:35.820 for joining us on this deep dive today. Beat. 00:13:36.220 --> 00:13:38.200 See ya. Out to your own music.