Token Usage Experiment: Value, Speed & the Cost of Subagents

AI is fast. That is the easy part to notice. The less obvious part is what each fast answer costs. I have been experimenting with models while working on my Godot project. The goal is not to find the most powerful model at any price. The goal is to get useful work from the money I have available.

That changes the question. I am not asking which model wins a benchmark. I am asking which model lets me keep building tomorrow. A slightly slower answer can be a better answer if it stretches the budget. A faster answer can be expensive if every complex task triggers more context, more retries, or more agents.

This is still an ongoing experiment. Prices change. Models change. My projects change. These conclusions describe my experience so far, rather than a permanent ranking.

What I am measuring

Token usage is not the same thing as useful work. A model can use fewer tokens and still waste my time with a wrong answer. It can use more tokens and save an hour of debugging. The useful measurement sits somewhere in the middle.

I am watching four things:

• Cost — how quickly the balance drops during normal work.
• Speed — how long I wait for a response or tool call.
• Quality — how often the answer is correct and relevant.
• Friction — how much correction, repetition, and context repair I need.

Friction is easy to ignore. It should not be. Five cheap responses that require constant steering can be more expensive than one direct response. The cost is not only in tokens. It is also in attention.

I also try to separate simple tasks from complex ones. A model that is perfect for a short explanation does not automatically make the best project partner. Codebase work brings more context. More context means more tokens. A model's strengths can change once the task gets larger.

DeepSeek: great bang for buck, but slow

DeepSeek made a strong first impression on value. It could produce useful results without burning through the budget quickly. For straightforward questions and focused code, that matters. It made experimentation feel affordable.

The problem was speed. The wait became part of the workflow. A development loop depends on momentum. Ask a question, inspect the result, run the game, report what happened, and continue. Long pauses make that loop feel heavier.

The experience was not bad. It was simply slower than I wanted for interactive work. A low cost is less attractive when every small step takes longer. DeepSeek remains a good option when price is the main constraint and the task is not time-sensitive.

My conclusion was not "cheap is bad." It was more specific:

Value includes the time between a question and a useful next step.

Gemini Flash: excellent until the work got complex

Gemini Flash felt great for a lot of tasks. It was responsive. The answers were useful. It handled the kind of short, direct interaction I wanted from an assistant. For simple work, it was a very good fit.

The cost changed when the tasks became more complex. Longer context, more back-and-forth, and bigger changes added up. The experience stayed good, but the budget moved faster than I expected.

That is an important distinction. A model can be excellent and still not be the model I use by default. If the complex tasks are the tasks I do most often, their cost matters more than the price of a quick test.

Gemini Flash taught me to test models with realistic work. A short prompt is not enough. I need to include the sort of task I will actually repeat. Inspecting a project is different from asking for a one-off code example. Debugging a scene is different from explaining a function.

Luna: the current best balance

Luna is the model I keep coming back to. It is fast. It is useful. It gives me enough quality for the Godot work I am doing. Most importantly, it offers a balance I can live with.

It does not need to be perfect. It needs to be good enough that I can keep the loop moving:

1. Ask about one problem.
2. Get a useful answer.
3. Test it in Godot.
4. Report the actual result.
5. Continue without worrying about every exchange.

Luna has become my go-to because it performs well across that whole loop. It is not only a strong answer in isolation. It is a sustainable default.

That conclusion is personal. Someone else may value maximum reasoning depth, a particular coding style, or a different price structure. My priority is value over maximum capability. I would rather have a reliable model I can use freely than a powerful model I have to ration.

The hidden cost of subagents

The next discovery came from Claude Code. The main model was Luna, but Claude Code subagents could only use a selected group of models. The subagents were not automatically using my preferred model.

That made the spend less obvious. I would start a task with Luna. The main interaction looked reasonable. Then subagents would be called in the background. They were useful, but they worked through models I found expensive for my use case. The money was being spent on delegation before I had decided that delegation was worth it.

Subagents can be a great feature. They divide work. They can explore files, review changes, or handle separate pieces of a larger task. In a business environment, the time saved may be worth more than the additional cost. A team with a deadline may prefer several parallel workers over one careful loop.

That is not my current situation. I am working on a personal project. I am trying to stretch the budget. I am also learning the codebase. The time saved by a subagent is not always a real saving if the result still needs review.

So I turned subagents off.

Why I prefer one model for now

Turning off subagents felt slightly backwards at first. More agents sounds like more speed. But the main model was already fast. I did not need several parallel answers for every small task.

A single model gives me a simpler cost story. I know which model is working. I can see the conversation. I can follow the decisions. I can decide when a task is big enough to justify another layer.

There is also a learning benefit. When one model handles the investigation, I see more of the reasoning and the project structure. I have fewer invisible steps to reconstruct later. That is useful while the game is still small and unfamiliar.

The trade-off is straightforward:

Subagents on:
  More parallel work
  Potentially faster completion
  Less direct visibility
  More model and token spend

Subagents off:
  One clear working loop
  Lower and simpler cost
  More time spent waiting or guiding
  More direct understanding of the project

For me, the second list wins at the moment. I would prefer to stretch the money out rather than save time I do not urgently need to save.

Speed is not always the bottleneck

This is the part I keep returning to. AI is already blazingly fast at most things. Why do I need multiple agents for every request?

Sometimes I do need parallel work. A large codebase review can benefit from separate investigations. A business team may have several people waiting on the result. Deadlines change the calculation. The value of time depends on what that time is worth.

My situation has a different bottleneck. I need to make decisions. I need to test the game. I need to understand the changes. The fastest possible answer does not remove those steps.

If an agent saves me ten minutes but costs more than I want to spend, it is not a saving. It is a trade. That trade can be correct. It should just be intentional.

A more deliberate token workflow

I am changing the way I prompt as well. Better prompts do not only improve answers. They reduce repeated context and correction.

My current rules are simple:

• Give one task at a time. Small scope reduces wandering.
• Ask for inspection first. Guessing creates expensive corrections.
• Name the constraints. Say what must not change.
• Ask for a plan before a large edit. A short plan is cheaper than undoing a large one.
• Include the actual error. Do not make the model debug my summary of the error.
• Stop when the task is done. Extra refinement can cost more than it adds.
• Keep reusable project context nearby. A concise project note is better than repeatedly explaining the same structure.

The last rule is especially useful with Godot. The project has a small set of conventions: scene names, folder locations, input actions, and movement rules. Keeping those decisions clear reduces the number of times the model has to rediscover them.

This connects directly to the Godot MCP workflow. MCP gives the model project-aware tools. Good prompting decides how often those tools are used and how much work happens after each result.

Cost versus time

I do not think there is one correct balance. There is only the balance that matches the work.

For a business project, a faster result can easily be worth more than the model cost. If several developers are blocked, subagents may be the right choice. If a deadline is close, parallel investigation can be sensible. The budget is not the only resource.

For a personal project, the calculation can be different. I would rather have more sessions over more days. I would rather understand the code than receive a large invisible patch. I would rather wait a little than run out of budget while I am still learning.

That is why my current preference is not anti-subagent. It is pro-balance. Use the expensive acceleration when acceleration matters. Do not pay for it by default just because it exists.

My current setup

This is where I have landed for now:

Default model: Luna
Model gateway: OpenRouter
Project: Godot game prototype
MCP: enabled for project-aware work
Claude Code subagents: disabled
Priority: value, then speed, then extra automation

That setup is not final. The project will get bigger. My needs may change. A larger milestone may justify parallel work. A new model may change the comparison. I will test again rather than treating today's result as a rule forever.

For now, one fast model is enough. Luna keeps the work moving. Turning off subagents keeps the cost predictable. The saved money gives me more room to experiment.

What I have learned

The biggest lesson is that token usage is a workflow problem. It is not only a model problem. The model matters, but so do prompt size, task scope, retries, delegation, and how often I ask for work I do not need.

DeepSeek showed me that low cost can come with a speed trade-off. Gemini Flash showed me that a great experience can become expensive at scale. Luna showed me what a sustainable middle ground feels like. Claude Code subagents showed me how quickly delegation can change the cost of a session.

My current rule is simple:

Spend money to remove a real bottleneck, not to make an already-fast process look more advanced.

That rule may change when the project changes. For now, I am keeping the model count low, the tasks focused, and the subagents off.

The game still needs building. I would rather spend the budget on more building than on more activity around the building.