Using tokens economically for hobby projects
My economical AI workflow routes planning and implementation across two subscriptions, keeps project context small, and puts human verification between tickets.
Contents
For a long time, I did not think much about token costs. I had a pile of AWS credits, and Bedrock gave me access to Claude Opus 4.6. It worked well. The credits made that level of usage feel almost unlimited.
Then the credits expired.
Paying API prices for large models is hard to justify for hobby projects. A long session, a few subagents, or an unproductive direction can turn experimentation into real money quickly.
Subscriptions changed the calculation
I started looking for a flat-price replacement. ChatGPT Plus turned out to be a good fit. I could use Codex and Pi Agent without running out of the provided window during my hobby projects.
That costs $20 per month and includes the ChatGPT mobile and desktop apps. I do not know whether this is profitable for OpenAI or how long the limits will stay this generous, but the value is good today.
I have now added Claude Pro as well. Two subscriptions give me access to two complementary frontier models without paying the API price for every experiment.
The split matters more than choosing one winner. GPT-5.6 Sol with medium reasoning has been enough for almost anything technical when the workflow is right. Opus gives me a different model for planning and design.
The setup changed while I was writing this
This is a good example of how quickly the economics move. My first draft said I would probably return to Claude Pro and invoke Claude Code through Pi. A few days later, my primary harness had changed to T3 Code.
T3 Code lets me give each subscription a specific job. I use Claude Opus 5 through Claude Pro for planning, then switch to GPT-5.6 Sol through ChatGPT Plus for implementation.
| Work | Model | Access | Role |
|---|---|---|---|
| Planning and design | Claude Opus 5 | Claude Pro through T3 Code | Grilling, architecture, specifications, ADRs |
| Implementation | GPT-5.6 Sol, medium reasoning | ChatGPT Plus through T3 Code | Ticket-by-ticket coding and verification |
| Alternative harness | Pi Agent | pi-claude-bridge where appropriate | Provider flexibility and subagents |
| Research | Tavily and Context7 | Minimal enabled tooling | Current web information and technical documentation |
This is not a model ranking. It is the division of work that currently fits how I think. Opus plans. Sol implements. Pi remains available when I want a different harness or a focused subagent.
Spend context as carefully as tokens
Economical usage is not only about the price of generated tokens. Every skill, MCP server, instruction file, and stale conversation included in the context consumes attention.
I try to load the minimum needed for the task:
AGENTS.mdholds project instructions.CONTEXT.mdrecords shared language.- Local specifications, tickets, and ADRs carry decisions between sessions.
- Skills and MCPs stay disabled until the task needs them.
- Tavily and Context7 provide current external knowledge when local context is not enough.
The shared language surprised me. I never expected vocabulary to become an engineering concern, but human and agent conversations improve when project terms have exact meanings.
What is a “secret administrator” in this project? What are “access control tags”? Once CONTEXT.md answers those questions, future sessions do not have to rediscover the definitions.
The same applies to ADRs. A decision without its reasoning gets reopened. A short record of the trade-off keeps the next agent from spending tokens debating a question that was already settled.
The workflow I use now
The harness and models may change, but the artifacts between stages stay stable.
Here is the sequence I run:
- Run
/grill-with-docsuntil the design and vocabulary are aligned. Even a small change can produce 50–60 questions. It takes time and energy, but unresolved assumptions cost more later. - Run
/to-specto compress the conversation into a high-level design or PRD. - Run
/to-ticketsto create small stories that can be implemented and verified independently. - Run
/implementon one ticket at a time, usually through a focused subagent with fresh context. - Verify the happy path yourself before starting the next ticket.
The first three stages are not specific to development. I use the same alignment, specification, and ticket flow for architecture and design work. Only the implementation artifact changes.
Human verification is the gate
AFK ticket loops are tempting, but I do not let several unverified tickets run ahead. If the first one is wrong, every later ticket inherits the wrong context and makes the correction more expensive.
Current frontier models are good at trying to solve a ticket on their own. I rarely need /goals for this workflow. Autonomy inside one well-scoped ticket is useful.
I still verify at least the happy path before moving on. Tests can pass while the interaction is wrong. Human judgment catches that early, while the change is still small enough to unwind.
Keep the workflow replaceable
Kimi K3 adds another relatively cheap option, and a Kimi subscription may become useful for flat-price usage. OpenRouter remains the escape hatch when I need a specific API model.
I still have Google credits, so Gemini can use those. The exact mix will keep changing as models, prices, and subscription limits move.
For hobby projects and small startups, I think the practical approach is to use subscription capacity first, pay API rates selectively, and keep the artifacts independent of the provider.
The deeper workflow behind grilling, shared language, specifications, vertical slices, and fresh-context implementation.
The model is replaceable. The workflow should be too.