If you grew up listening to 90s hip hop, you probably already know where the title came from. “Get the money. Dolla, dolla bill, y’all!” Proud 80s baby here. That aside, here’s what led me to this.
A few days ago, I found out I was going to have to start paying a lot more attention to my AI token usage at work. My first reaction was not some profound engineering insight. It was basically: ugh.
I use GitHub Copilot a lot. Like…a lot a lot. 😅 Over the past year, AI has slowly worked its way into almost every part of how I build: planning something new, debugging, refactoring, exploring an unfamiliar repo, writing tests, or sometimes just asking, “What am I missing here?”
So adding more limits initially just felt like friction. Then I started looking at how I was actually using AI.
And, well…
Maybe I needed the friction.
For a long time, I mostly chose an AI tool based on convenience. If I was already in VS Code, I used Copilot. If I was in ChatGPT, I asked ChatGPT. If I needed to change a bunch of code, I used whichever coding agent I was already talking to.
And if a really capable model was available, why wouldn’t I use it?
That approach works surprisingly well when usage feels unlimited. It gets a lot less sensible once it isn’t. I started noticing all these places where I was basically sending a U-Haul to pick up a sandwich.
| Task | What I was often doing |
|---|---|
| Fix a tiny script | Big model |
| Explain a function | Big model |
| Change two files | Big model |
| Rename something | You guessed it. Not as big model |
I would never architect a production system like that. But somehow with AI, I had normalized it.
I already had most of the pieces
The funny part is that I wasn’t lacking alternatives.
I already run Ollama locally. I’d started using Aider for smaller coding tasks. I was using Codex more heavily on personal projects. ChatGPT was already where I did a lot of thinking, planning, research, and architecture. And Copilot was deeply integrated into my normal development workflow.
I’d even spent time optimizing the commands agents run. RTK, for example, helped me reduce how much noisy terminal output gets dumped back into context.
So this wasn’t really a “find cheaper AI tools” problem. I already had the tools. What I didn’t have was a particularly disciplined way of deciding which one should do what.
And there is a difference. Having six AI tools installed is not an AI strategy. It’s mostly a good way to forget which subscriptions you’re paying for.
So I built a skill to choose for me
I have a repo called ai-config.
It started innocently enough: some Ollama configurations, a few reusable instructions, some things I didn’t want to keep recreating. Then I kept adding more.
Now it has reusable AI skills that work across Codex, Copilot, ChatGPT, and some of the other environments I use. Things like restoring coding context, creating new skills, writing in my voice, previewing Marp presentations, and a bunch of other little pieces of my workflow.
Recently I added one called ai-tool-recommender.
I built it because I got tired of making the same decision over and over: What should I use for this?
At first I thought I would just create a few basic rules.
| Situation | Likely choice |
|---|---|
| Small coding task | Aider |
| Personal multi-repo work | Codex |
| Planning or architecture | ChatGPT |
| Sensitive data | Ollama |
| IDE-centric implementation | Copilot |
Done. ✅
Except once I started building it, I realized the decision was more interesting than that.
Ollama doesn’t have API token costs, but that doesn’t make it free. Running one of my larger local models can eat a ridiculous amount of memory. My poor Mac knows when I’ve decided to be “cost conscious.”
Copilot sits right inside my IDE, which makes it a great choice for a lot of work. But there are situations where another tool can see more of the context I need.
And sometimes I don’t need a coding agent at all. I need to think. That’s usually a different tool.
So the recommender grew actual rules. It looks at things like privacy, repository scope, task type, complexity, cost, context, speed, and even how much local compute I want to burn.
Some things aren’t scored at all. They’re hard stops. Sensitive data, for example, changes which tools are eligible before anything else gets considered.
What started as:
Which AI should I use?
quietly became:
What is the least expensive capable resource for this workload?
And that sounded very familiar.
Oh. This is just engineering again.
We already know how to do this. Nobody looks at a system running in production and says, “CPU is available. MAX IT OUT.” At least I hope not.
We right-size things. We cache. We reduce unnecessary network calls. We think about memory, data boundaries, expensive operations, and which infrastructure actually fits the workload. Somewhere along the way, I had stopped applying those instincts to AI.
The model was just…there. And because it could do the task, I let it.
Token limits made me care about efficiency enough to start architecting around it.
The prompt isn’t the whole bill
One thing I had to get clearer on was what “token usage” actually meant. I used to think mostly about the prompt.
If I typed:
Rename this variable.
that feels like a tiny request. And the request itself is tiny.
But depending on the tool and the session, that request might arrive with conversation history, repository context, tool definitions, retrieved files, terminal output, and everything else I’ve accumulated along the way.
So the mental model I use now is closer to: my request + accumulated context + the model’s response
That explains something I had noticed before I really understood it: a tiny request late in a long coding session can be surprisingly expensive. The words I just typed aren’t necessarily the expensive part. It’s all the luggage they’re traveling with.
Once I understood that, a few of my day-to-day habits started changing too.
| Habit | Why it matters |
|---|---|
| Start fresh when the task is actually new | Yesterday’s debugging session doesn’t need to follow me into unrelated work. |
| Compact long-running conversations | Keep the useful decisions, lose the accumulated noise. |
| Be selective about repo context | “Just in case” still counts as context. |
| Use RTK for terminal-heavy work | Huge command outputs can quietly eat a surprising amount of the context window. |
| Persist decisions in files | Important project knowledge should live somewhere durable, not inside one giant chat. |
None of these are particularly exciting on their own. Together, though, they changed how I work.
I’m spending less time feeding the model information it either doesn’t need or should be able to recover from somewhere more durable.
And I can actually see the difference.
That graph is my recent token usage. It isn’t perfectly flat, and I wouldn’t expect it to be. Some days genuinely need more context or more capable models. What I care about is the shape.
The huge spikes are becoming less frequent. I’m getting more deliberate about when I use expensive context, when I reset, and when a smaller or local workflow is enough. That’s the signal I care about. Not “use as few tokens as possible.”
Use the tokens where they actually matter.
That shift is also why I’ve been moving more of my workflow into reusable skills and configuration. Instead of writing another giant prompt telling an agent how I work, I want that knowledge sitting somewhere durable.
The skill already knows. The repo already knows. The agent instructions already know. Now the conversation can actually be about the work.
I’m still experimenting with this, but I’m becoming much more interested in context engineering than prompt engineering.
A great prompt helps one interaction. A good context system makes the next hundred interactions cheaper and better. That’s a much more interesting problem to me.
I’m not trying to use fewer tokens
This is where I think the conversation can go sideways. The goal isn’t to use the smallest model all the time. That’s just another kind of bad optimization.
Sometimes I absolutely want the biggest, smartest model I can get. Give it the long context. Let it reason. Let it explore. If I’m making a complicated architectural decision or working through something I genuinely don’t understand yet, that’s probably money well spent.
I just don’t need to bring that same energy to:
Rename this variable.
There’s a difference between using fewer tokens and wasting fewer tokens.
I’m after the second one. That distinction matters because cheap can be expensive too.
If a smaller model takes ten times longer, needs three retries, or sends me down the wrong path, I didn’t really save anything. And if I use a giant local model for a tiny task, I may not be paying per token, but I’m still paying in memory, compute, and time.
So the goal isn’t minimal usage. It’s appropriate usage.
The constraint changed the architecture
I still don’t love token limits. Let’s not get carried away here. But I do think they forced a useful change. My AI workflow used to mostly be a collection of tools I liked using. Now I’m starting to think of it more like a system.
Some work stays local. Some goes to Copilot. Some goes to Codex. Some starts in ChatGPT and moves into a coding workflow once I’ve figured out what I’m actually trying to build.
Some gets handled by smaller models because it simply doesn’t deserve anything bigger. And the routing rules themselves are becoming reusable. That’s the part I didn’t expect.
The limitation didn’t just change how much AI I use. It changed how I architect my use of AI.
I suspect we’re going to see a lot more of this as AI becomes normal engineering infrastructure. The interesting question won’t always be:
What’s the best model?
It might be:
What’s the right model for this particular piece of work?
That feels like a much healthier question.
Because apparently Wu-Tang was right about resource management all along. They were just a few decades early on the tokens.
