Everyone how's it going in this video i'm going to teach

you how to reduce your cloud code token

usage by up to 90

in

four different strategies it's easy and free to do and you

can do it right away and in this video i'm going to show

you step by step and also a quick comparison on like

visually being able to see difference in tokens that you'll

be ending up using now all of these strategies actually do

have some trade-offs and i'll also go over those trade-offs

as well so be sure to stick around through the entire video

so you don't miss out on exactly how to use these things

properly as usual i made some slides so there's some

visual representation of what i'm talking about so let's get

right into the four different strategies now the first

strategy is actually to index the code essentially we're

going to create an index of the code now if you don't

know what indexing is it's essentially like search actually is

a very famous usage of an index. Essentially what Google

does behind the scenes is it creates a map of like

keywords that point to different websites as a very

dumbed down example. So the core idea is that we want

to essentially create a graph map of our code base.

So here's a visual representation. Now on the left side,

it's kind of how clock code already does

the grep and reading and scanning of the code base.

It will go one by one and deep dive into the code base.

If you're asking about some particular, you know,

server implementation or some validations like file or an

auth file, we'll try to go and grep it using regular file grep

and they will go and find it and load those into the

token context. So it ends up spending a lot of time

because sometimes to find the files that it's looking for,

it would have read a lot of things that it doesn't need.

Now, when you index the entire code base into essentially

a curable graph, You can see this representation here.

You essentially use like natural language to try to find the

code base via a search. And then you essentially do this

indexing ahead of time once so that Kako can leverage

this code graph so that it can find a lot of these things

under the hood without having to read all of this other

files just to get to where it needs to go. Now the way to

get this to work is essentially use this repo

called CodeGraph. It's very easy to install. All you need to

do is just copy this

mpx command and then paste it in or just install using the

npm global and then you just init the project here.

So for example, we could do CodeGraph init-i and then it

would initialize it. I already initialized it over here.

And there's a bunch of things that you can do with this.

So for example, you could do CodeGraph status

and they will kind of give you a metadata about

the CodeGraph, like what is in here, what kind of nodes

are there, like import. Is there a component?

You know, the common things that you kind of

would need. And then as an example, we could do

Curie. So let's do CodeGraph Curie LLM, for example.

And then here it found two search results where it says it's

HTML to text and active session.

So essentially just use like semantic natural language to

be able to find the relative code.

Now you wouldn't normally

use like

this manually, but Clock Code essentially learns how to

use this CLI tool under the hood and then it will do all of

these like functions for you. Now, if you look at the docs,

this is the CLI reference right here. It has all of these

commands and then essentially Clock Code will read the

CLI tool,

understand how to use it and leverage the CLI to do

the Curies. So that's the first strategy is essentially to

create a graph.

So that instead

of Clock Code reading files one by one, kind of using grep,

you do some work ahead of time.

And then you index a bunch of things so you could quickly

get to the file that you're looking for more semantically.

Now this is a very common strategy and essentially how

like a lot of search based products work, right?

Or graph recommendations like in Meta. But there are

trade-offs to this strategy. So the number one trade-off

with this

graph strategies, this pre-indexing strategy

is that now there is two source of truth, which is that one,

you have your code base as a source of truth. But now

when Clock Code is looking and researching things,

there is the index that is also the source of truth.

That means that some system, ideally Clock Code,

will have to spend time syncing.

Now this repo actually has a method of syncing, but if you

forget to do it, or it just hasn't been done since some time

period that you've been coding, something could go out

of sync. And then now Clock Code will confidently be

wrong that, hey, this function may not exist, or this file

doesn't exist. Or it does exist, even though it

doesn't exist.

So there's this tax of like having to keep it synced.

The other kind of major trade-off, which is not as big of

a problem, but essentially for compound engineering,

when you're adding context files into big modules,

for example, the way it systematically does code search,

it may miss some of that. It might find the actual file that it

needs to, but it might miss that module's Cloud.md

that it's supposed to load normally. Because the way

normal Cloud.md works

is if you put one in some directory, if the code search

goes into that file and reads that file, it'll actually go up

and read that Cloud.md in that module. But because

you're using a query version,

it may miss it.

So there is this inherent issue. And there's also

probably some

issue with accuracy, especially for

deep dives. And at the end of the day, you still need to

read the accuracy. Actual file once it files where the file is,

right? So it does save a lot of tokens in the retrieval of

the file, but you still will have to spend tokens on reading

the file. But yeah, so those are kind of the

high-level trade-offs. All right, strategy number two is to

compress the outputs.

So what does this mean? And I think this is a really

good example. So if you take a look at this

video animation,

on the left side is essentially an NPM run. And in the

NPM run, anyone who is programmed for a while knows

that server logs or just CLI logs or just logs in general is

very noisy. And oftentimes it's information that

ClockCode doesn't actually need. So there's this open

source library called RTK that actually takes a lot of these

noisy logs and then compresses them. So on the right

side is something like, oh, 43 test paths, rather than listing

out all the 43 tests. And then like, it'll also like bundle all

the warnings if it's suppressed them, for example.

So there could be huge savings here. And before that,

all of the tokens get read back by ClockCode, it just like

shrinks all of it. So you can imagine how much savings it

would have, especially

if your workflow is heavy in logs or CLI usage, or like a

bunch of like noisy things that ClockCode doesn't actually

need to know. This open source library will save a ton

of tokens. So as you can see, this is the open source

library right here. And it's very easy to install as well. I just

use homebrew and then you could just have it installed

into like a specific directory or globally. And again,

there's a bunch of ways you can like manually just trigger it

using the CLI commands. And this is pretty

common pattern. A lot of people have been realizing that

CLIs are just kind of a better form factor than MCPs.

And if they can help it, they would build a CLI over like an

MCP because ClockCode is very good at juggling CLIs.

Okay, so we'll do like a very simple example of doing like a

Git log, for

example. Git log.

And you can see like, if you actually do Git log,

there's so much, you know,

information about the Git log, it's just it goes on for

a while.

So let's use RTK now.

And then you can see that all of these things

were compressed, and it shows how many lines it

was omitted. And it just saves a ton of tokens. And again,

like CodeGraph, it's ClockCode will leverage this

tooling for you on your behalf. So you will get a ton

of savings. But

there is definitely a trade off here. And it's pretty obvious.

And essentially, the trade off is accuracy, because the

compression is lossy. By doing this method, you definitely

have a chance of like dropping a very important

log or some message that you are hoping for. And the

system tries its best to, you know, compress

and just remove things that it doesn't need.

But if you're trying to debug bunch of server logs, it might

be worth to turn this off when you're doing that

specific work. So like, you should really know when to turn

it on and when to turn it off. And at what point do you

need the extra logs for the improved like self healing,

for example, if you want to self correct, you may want to

read the system logs to make sure that everything is

happening step by step in the way that you want it. But in

most of the time, you don't actually need all of the logs.

So this is a really good strategy to compress a lot of the

output before it comes to you. All right, strategy number

three is,

in fact, my favorite strategy.

And honestly, I think they misnamed this, but essentially is

to use caveman, which is another open source library.

Now at a high level,

it's to get cloud code to talk

less.

So in this diagram, you can see on the left side, there's a

bunch of like long outputs on the right side is a very like

aggressive caveman example.

And

it will just compress everything. And I want to show this

video because I think it's the most accurate assessment

to what this is doing.

I waste time say lot word when few word do track.

That's probably one of my favorite clips from the office.

The office was ahead of its times, honestly.

And you know, Kevin was ahead of this time, and definitely

a clock code Maxer. But yeah, caveman, like I said,

probably should have been named Kevin, in my opinion,

but at a high level, it's really that it's just to shorten the

amount of words that clock code says to basically say the

same thing. It's very easy to install cave man, you can just

do NPM install here, just copy this command and paste it

into your bash command. There's many different ways.

And essentially, it's a skill that sets

your clock code session into a specific mode. So there's

like light full ultra, and then when

essentially it's per session, so you could remove it at any

time or like at it. So it really depends. So let's give it a shot

real quick. Tell me about this project. Alright, so on the left

is without caveman. That's the caveman Ultra. And then

here is came in and saw and it's ready for the next project.

Tell me about this project. Alright, so as you can see

right here, it's about like half of the output. And I would

say you still get about like the same quality.

It's pretty accurate. So that's caveman. I use it quite a bit.

I keep it on ultra

until I like need to get away from a specific trade off.

And we're gonna go into the trade off now. So the obvious

trade off here is that yes, you save tokens, but the

correctness is at risk here. Because essentially, clock code

really needs to leverage this like feedback loop of

messages in and out to get as much context that it needs

to answer things questions better. But when you

essentially shrink the outputs dramatically,

those messages get resent back to clock code, right?

The way the context window works is the context that you

have essentially clock code leverages it in this

agentic loop. And that's how it knows what you've been

working on. So your context history that session if the

quality is bad, then the output may lead to like

bad answers. Essentially, I'm working on a video right now

on system design for a clock code. If you're interested in

that subscribe,

I think it's very important to understand like

system design, system design is probably the most

important thing in this new world of AI. So I'm doing a

whole series

on system design for like agentic tools agentic,

like building chat GPT, building clock code, building like a

rack system, like all of that kind of stuff. So if

you're interested, don't forget to subscribe

to this channel and my newsletter. Alright, the final

strategy is kind of boring, but it's good old just managing

the clock code session properly using like compact,

changing the models, the docs have pretty good

recommendations on managing it. Here is kind of the

main ways to main built in ways to save your

tokens. Alright, so obviously, there is

such context, right here. And this kind of shows you

what's in the current context. And I look at this every now

and then to make sure that my

usage just makes sense. You know, sometimes if you have

like a really large cloud.md, you won't realize it until you

look at it. And every time you turn on the quad code,

it's using like 40k tokens, and you're like, what is going on?

How is it that every time. I just opened my session is

using 4%? Well, it could just be that you have a 50k

token cloud.md.

It's like a pretty small cloud.md that like just is already

indexed and like points to different

things. So this is a really good way to kind of audit what's

using the most tokens. And sometimes you'll find that like

MCPs end up using a lot in this case, it's not there's a

bunch of things that's loaded, it's ready to go. And these

are my MCPs that I have. But essentially, this is a way to

debug the current context. There's also slash clear,

which clears

the context. And.

I will say that if you're working on like new tasks, let's say

you have a you just finished a task and you want to do

another new task, then it's good to clear the task if you

need a previous context or not. There's also slash model

to switch the models. And some people ask me if like

haiku or sauna is ever worth using. And my answer is

100% Yes, I think one of the best use cases of haiku is

actually using it in slash Chrome, or just navigating like

Chrome haiku does a really good job. And it's actually

better in most use cases, because it's faster to navigate

because the model itself is fast. For sauna, I actually

leverage sauna for a lot of like my scheduling jobs. If I have

like a slash schedule, I will try to see if that schedule job

that I want to run every like day or whatever, let's say I,

I have one that like just cleans up my desktop, like it's just

like looks at my desktop and moves everything into

folders that I could probably just use sauna or haiku.

Because I know that that specific thing can be done

with sauna. If I know that that task

is repeatedly successful, we're using sauna or haiku,

I'll always end up using that. So don't forget, try switching

the models. And you don't have to be on the million

4.7 context. Now, pro tip here is that if you're doing any

significant programming tasks,

I do recommend just being on

the the most, like reliable, especially for planning and

doing deep dives. The quality self, in my opinion, is a token

savings versus like trying to save money with sauna and

getting a bad quality result. And the last few things is I

would recommend using plan

mode first to plan out an execution rather than just

like having

clock code and go do just a bunch of things. And then for

programming in general, I would say use like

pencil or Figma

to design something, run off designs,

rather than just like coding something right.

So yeah, so those are kind of the high level tips, I would

say that I have for just managing your

session. Now, a lot of what I said actually is in this stock,

I'll link this below. But you know, clock code also has like

advanced strategies. Most of this is already like kind of

covered in my talk, not the repos, they won't cover the

open source projects, but more about like the

strategies that. I just mentioned about managing

your session. So feel free to take a look at that.

For example,

they said agent teams cost a lot,

which makes sense. So should you use all of these things?

And in my opinion, I think the answer is yes.

But again, there's trade offs.

And in my opinion,

the most the largest trade off here is really costs

versus

quality. And also just like the

quality and and and also the complexity, there's a

complexity aspect, right? There's

the code graph, it can get stale.

The RTX proxy is lossy for sure. So you're straight up just

missing messages. And sometimes you'll miss a log or

something that you need. And caveman may be over

trimming things so that

the message history is not great. But

it all of these things dramatically save the tokens.

So really, it's you understanding the how to use these

tools and essentially being like, oh, okay, in this

particular application, I may not need all of the logs. So I

could just have RTX be on. And then oh, in this case,

caveman is great, because I don't really need it right now.

I don't need this. I'm not doing like a crazy plan mode

right now or something like that.

So yeah, but all of these things add complexities,

add multiple layers, multiple things for you to juggle

multiple failure points, essentially for clock code, right?

So yeah, you got your own risk,

but I guarantee you, you will save

tokens

using these strategies. So yeah, I hope you enjoy

this video. I make a ton of videos on clock code and AI

coding agent decoding. So feel free to check them

out here.

And don't forget to subscribe to my newsletter, I

have a bunch of content there that I don't really post here,

I actually also just launched a new course with bye bye go.

And I'll be teaching you over there. So if you're interested,

it is a paid live course. It's a two day thing, you could build

a bunch of portfolio projects.

And I teach you basically everything I know about clock

code. So if you're interested, sign up to a bye bye goes

newsletter or look at this website, the course may or may

not have already happened. So if you missed it, you might

have to join the next course. But yeah, I hope you guys

enjoyed this video. And until I see you guys on the

next one.