DEV Community: Hoa Trinh

I gamed Copilot's billing model and built a plugin to do it properly

Hoa Trinh — Fri, 08 May 2026 16:32:28 +0000

I have been running agentic workflows daily for over a year. Jobs, side projects, experiments. The stack keeps changing. The habits around it slowly solidify.

The part worth paying attention to is the billing math: the Copilot usage table only showed about $10 in orchestrator spend, while the subagents in my pack did much more work off that meter.

I started with GitHub Copilot, used Claude Code for work for more than eight months, and eventually moved to OpenCode. Each switch taught me something. None of them felt final.

The upgrade that made me pay attention

A few weeks ago I upgraded from Copilot Pro to Pro+. Not for any specific reason. I wanted to try the newer models through OpenCode, and Pro+ unlocks more of them.

While I was testing the setup, I noticed something. When a primary agent spawns a subagent, the subagent calls do not count against your Copilot premium request quota. The main orchestrator eats a request. The subagents work for free.

That is a big deal if your workflow is built around delegation.

Right around the same time, Copilot announced the new usage-based billing kicking in June 1, 2026. Premium requests will be billed at $0.04 each once you exceed your monthly included quota. So the loophole I found just became a lot more valuable.

Spec-driven development already solved the hard part

I had been using the Superpowers plugin pack for a while. The core idea is Spec Driven Development: before any code gets written, you brainstorm, write a spec, write a plan, then implement task by task with review at each step. It sounds slow. It is actually faster because you stop mid-implementation a lot less.

The problem was that Superpowers was built for Claude Code. I was on OpenCode.

So I built opencode-superpowers: an agent pack that brings the same SDD workflow to OpenCode, with one key addition. Each agent in the pipeline is assigned a model tuned for its job, and the whole thing is wired to exploit the subagent billing gap.

how the model assignment works

The pack installs six agents. Here is how the copilot profile assigns models:

| Agent | Model | Role | |---|---|---| | superpowers (orchestrator) | GPT-5.4 mini | Brainstorm, delegate, coordinate | | superpowers-spec-writer | GPT-5.5 | Write and self-audit the design spec | | superpowers-plan-writer | Claude Opus 4.7 | Turn spec into executable plan | | superpowers-implementer | Claude Sonnet 4.6 | Execute plan task by task | | superpowers-code-reviewer | GPT-5.4 | Review each task before finalizing |

The orchestrator runs on GPT-5.4 mini. It is cheap, fast, and good enough for routing and coordination. The heavy thinking happens in subagents where the premium request cost does not apply. So you get Opus-quality planning and Sonnet-quality implementation essentially for free under the current billing rules.

What the numbers actually look like

Eight days of real work, May 1 to May 8. Here is the full usage breakdown:

| Model | Included requests | Billed requests | Gross amount | Billed amount | |---|---|---|---|---| | GPT-5.4 mini | 129.69 | 0 | $5.19 | $0.00 | | Claude Sonnet 4.6 | 48 | 0 | $1.92 | $0.00 | | GPT-5.4 | 31 | 0 | $1.24 | $0.00 | | GPT-5.3-Codex | 27 | 0 | $1.08 | $0.00 | | Gemini 3.1 Pro | 13 | 0 | $0.52 | $0.00 | | GPT-5.5 | 7.50 | 0 | $0.30 | $0.00 | | Claude Haiku 4.5 | 2.97 | 0 | $0.12 | $0.00 | | Gemini 2.5 Pro | 1 | 0 | $0.04 | $0.00 | | Grok Code Fast 1 | 0.50 | 0 | $0.02 | $0.00 |

Total gross value in the Copilot usage table: ~$10.43. Billed: $0.00. That table only reflects the metered Copilot requests shown above, not the much larger usage from my agent pack subagents. In total, this consumed 260 premium request equivalents, all inside the included quota. That is the whole trick behind the headline. My 1500 monthly premium requests are at 17% used after 8 days of active shipping.

In those 8 days: a full project release, a batch of bug fixes across two repos, and an MVP for a new macOS app. Not bad.

The part that will not last

Copilot will close this gap eventually. Billing rules change, quotas tighten, subagent calls will probably count at some point.

But the workflow itself, SDD with a specialized agent per step, stays useful regardless of billing. The cost optimization is a nice bonus for now. The real value is the structure: you stop hacking at code before you understand the problem, and the review gates catch things before they compound.

I am running it hard through May. After that, the Pro+ subscription goes. The agent pack stays.

If you are on OpenCode and want to try it: npx opencode-superpowers. It auto-detects your provider and installs everything.

AI made learning fun again

Hoa Trinh — Fri, 01 May 2026 14:18:31 +0000

For a long time, learning new dev stuff felt like homework.

I could be curious enough to start, but not patient enough to stay. I would open the docs, then ten tabs, then a video, then another thread explaining the same thing in a different tone. Somewhere in that mess, the energy would drop. The thing I wanted to learn was still interesting. The process of learning it was not.

That changed with generative AI.

Not because AI made me brilliant. It did something smaller and more useful: it removed just enough friction that I stopped quitting so early.

The real problem was never information

There is more learning material online than any one person could finish in a lifetime.

So the problem was never access. It was everything around access:

too many tabs
too much context switching
too many small questions I felt silly asking
too much time spent trying to understand the “obvious” part before reaching the useful part

That last one is the killer.

When you are stuck on a tiny thing, the whole learning session starts to feel expensive. Then you stop. Not because the topic is hard, but because the momentum is gone.

AI helped me keep the momentum.

It shortened the shame loop

Before AI, there was always a little embarrassment attached to asking beginner questions.

I knew I was supposed to already understand the thing. So instead of asking, I would try to power through with fragments from memory and half-understood docs. That usually made things worse.

AI made it easier to say:

“Explain this like I know the basics, but not this exact detail.”
“What am I missing here?”
“Show me the simplest version first.”
“Why would someone choose this approach instead of that one?”

That sounds small, but it matters.

The shorter the gap between confusion and clarification, the less likely I am to give up.

It turned passive reading into active learning

I learn better when I am doing something with the information, not just reading it.

AI helps me move from passive to active faster. I can ask it to:

turn docs into a small exercise
quiz me on the idea
compare two approaches
generate a toy example
explain the tradeoff in plain language

That changes the vibe completely.

Learning stops feeling like a lecture and starts feeling like a conversation. More importantly, it feels playable. I can explore, try something, get corrected, and try again.

It taught me to ask better questions

AI is only useful if you learn how to use it well.

If I ask lazy questions, I get lazy answers. If I ask for the first thing that works, I stop learning too early. So the real skill is not “use AI.” It is “steer AI.”

The prompts that help me most are usually like this:

explain it simply first
then show the tradeoffs
then show a real example
then tell me what to build next

That sequence keeps me honest. It prevents me from outsourcing the thinking while still letting me move faster.

It still cannot replace doing the work

This is the part people skip.

AI can help me understand faster, but it cannot make the understanding stick.

I only really learn when I build something, break it, and fix it myself. AI is best when it gets me to that loop sooner. It should reduce the distance between “I have a question” and “I am testing the idea.”

If I use it to avoid doing the work, I get a false sense of progress.

If I use it to get to the work faster, it becomes genuinely useful.

The bigger change is emotional, not technical

The most surprising thing AI did for me was not technical.

It made being a beginner feel less bad.

That matters because a lot of people do not quit learning from lack of ability. They quit because the process makes them feel slow, behind, or stupid. AI does not remove that feeling completely, but it softens it enough to keep going.

And once you keep going, learning gets fun again.

My rule now

I do not use AI to think for me.

I use it to:

remove friction
ask better questions
stay in motion
get to hands-on practice sooner

That is the smarter way to use it.

Not fear. Not hype.

Just a tool that makes learning feel possible again.

The small habits I keep on rails

Hoa Trinh — Mon, 27 Apr 2026 01:46:39 +0000

Willpower is a bad scheduler. If a habit has to be decided every morning, I skip it about a third of the time. If it shows up as a Todoist task at 6:10 with a due time, I do it, because the friction of dismissing the notification is higher than the friction of doing the thing. That is the whole trick. The habits below are not special. The rails around them are.

What I do every day

20 push ups + 20 squats + 15 leg raises + 40 mountain climbers + 30s hollow hold, at 6:10.
Take a multivitamin at 10:00.
Read one post on daily.dev.
30 to 60 minutes of workout / running / cycling.
A monkey-type round.

Todoist handles the scheduling. Recurring tasks for the habit stack; one-off tasks for anything that is not on rails yet.

What I would cut first

Ranked by return on the minute it costs me. If the week got crowded and I had to start pulling things out, this is the order.

Keep. The 30 to 60 minute workout block. Biggest mood and energy lift of the day, and the only one that pays back into everything else.
Keep. The 6:10 bodyweight stack. Tiny time cost, primes the day, and the streak matters more than the volume.
Keep. Multivitamin. Cheap, zero friction, no reason to touch it.
First to cut. daily.dev. It is the most passive item on the list, and the easiest to rationalise as "input" when I am really just scrolling.
Second to cut. monkey-type. Fun, but if my keyboard speed were the bottleneck in my life I would already know.

When the rails break

Travel, illness, late nights, a deadline that eats the evening. The stack dies and pretending it did not makes it worse. The minimum viable version I fall back to:

One walk, any length.
Multivitamin.
Skip everything else without negotiating with myself about it.

The goal on a bad day is not to run the program. It is to not break the identity. One tiny thing keeps the "I do this" label intact. Zero things starts a story about quitting.

The commitment

One new habit, starting with this post: one post per week, on Fridays. This blog is day one. The rules are the same as the rest of the stack. Todoist handles the scheduling. If I miss a Friday, the cadence header on /blog will tell on me. That is the point.

What success looks like

Three months from now, late July, the honest metric is not whether I hit every day. It is two things. Is the Friday post still going up. Is the workout block still showing a streak longer than two weeks. If both are true, the rails are working. If one breaks, the rails are wrong for the season, not the habits.

I kept abandoning side projects, so I built a tool to fix the real problem

Hoa Trinh — Sat, 28 Feb 2026 15:12:02 +0000

I have a graveyard of side projects. Not dramatic failures, just apps that quietly stopped.

A habit tracker I was genuinely excited about. A recipe manager I used every day for two weeks. A CLI tool that was 80% done. All of them died the same way: I stepped away for a few days, came back, stared at the code, and thought, "I'll pick this up tomorrow." Tomorrow never came.

For a long time, I assumed this was a motivation problem. I tried fresh starts, cleaner task lists, and better scoping. None of it stuck.

Then one evening, I opened a project I hadn't touched in ten days. I spent the first twenty minutes just reading my own code, trying to reconstruct what I'd been doing. By the time I pieced it together, I didn't have the energy to actually build anything. I closed the editor and watched YouTube instead.

That's when it clicked: the problem wasn't motivation. It was context.

The 15-minute problem

Here's what actually happens when I try to resume a side project after a break:

I sit down with ~45 minutes. Good energy, ready to build. I open the project. I scan recent commits. I check the current branch. I re-read the code I was writing, trying to remember what I was thinking. I open the issue tracker to see if I left myself notes.

Twenty minutes later, I finally have enough context to start. But half my session is gone, and I spent it on archaeology instead of building.

That friction compounds. Eventually, the cost of resuming becomes just high enough that you choose something else instead. Not consciously. You just… don't open the project.

It's not motivation. It's context loss.

I started calling this context debt: the mental state that evaporates when you step away from a project.

Git tells you what changed, but not why you were changing it.
Your task list tells you what's left to do, but not where you were in the middle of doing it.

The cost of resuming after a break is what actually kills most of my side projects. Not the building, the coming back.

Once I saw it that way, the problem statement became pretty clear:

How do I make it almost effortless to pick up where I left off?

So I built a small tool

I ended up building a VS Code extension called KeepGoing. It's basically a thin context layer for your projects.

The idea is simple: capture lightweight "what was I doing?" context while you work, and hand it back when you return, without asking you to maintain docs for your future self.

This isn't meant to be a full-on productivity system. It's closer to a memory prosthetic.

Here's how it works in practice.

1. You code normally

No setup ritual, no new workflow. You open your project and code like you usually do. KeepGoing runs in the background.

I didn't want something that turned into its own todo app or forced me to remember another step before closing my laptop. If it required discipline, I knew I wouldn't use it.

2. Context gets captured automatically

KeepGoing watches for natural breakpoints and saves small "checkpoints":

On every git commit, it captures what you were working on
On branch switches, it snapshots context before you shift focus
After inactivity (75 minutes by default), it saves where you left off
You can also hit Cmd+Shift+K anytime to save a quick checkpoint manually

Each checkpoint records things like:

A short summary of what you were doing
The next step you had in mind
Any blockers
Which files you touched
Which branch you were on

All of this is stored as readable JSON in a .keepgoing/ folder in your project root. No external service, no account, nothing fancy.

3. You come back and actually know where you were

When you reopen a project after a break, KeepGoing shows a small sidebar briefing:

What you were doing last time
What you planned to do next
Which files matter for that work

If you've been away for 24+ hours, it proactively shows a "cold start" summary so you don't have to go hunting for it.

The experience I was aiming for is:

Open project → read a 2–3 line snapshot → jump straight into the right files.

No commit archaeology. No "wait, what was this branch for again?" Just enough context to unpause.

The "why" problem

After using this for a while, I ran into another gap.

Checkpoints are great for short-term intent and next steps. But some changes are more long-lived: CI configs, OAuth setups, database migrations, deploy scripts, etc. Those are the ones where, three weeks later, you look at your own code and think, why on earth did I do it this way?

So I added a feature I call Decision Detection.

It does two things:

Identifies "high-signal" commits: infra, auth, migrations, deploy scripts, that sort of thing.
Prompts you to jot a quick rationale, just a few sentences on why you made that call.

If you ignore the prompt, it still saves the decision as a draft so you can fill in the details later. The goal isn't perfect documentation; it's just capturing the important "why" before it evaporates.

The core checkpoint system is free; Decision Detection is a one-time paid add-on. I'm mentioning it for completeness, not trying to pitch it.

Plays nicely with AI agents

Agentic coding tools can already scan your repo and infer what's going on. But even with decent AI helpers, I kept finding the missing piece wasn't more code suggestions, it was remembering what I cared about last time I touched the project. AI can summarize files; it can't remember what future-me would have considered "done" for a feature.

Good, human-authored context makes AI agents better too. So I built an MCP server that exposes your checkpoints and decisions to compatible tools. When you start a new session, the assistant can see:

What you were working on last
What you planned to do next
What architectural decisions you've already made

No huge prompt paste, no "let me read through your recent commits for you." It just starts from where you left off.

Setup is literally one command:

claude mcp add keepgoing -- npx -y @keepgoingdev/mcp-server

There's also a CLI if you live in the terminal. You can add a shell hook so that whenever you cd into a project, it echoes your last checkpoint. That's been surprisingly helpful for me.

Design constraints I cared about

When I was building this, I had a few non-negotiables:

Local-first. All data lives in .keepgoing/ in your project. No cloud, no accounts, no syncing.
No gamification. No streaks, no guilt, no "you haven't coded in 3 days" notifications. This isn't meant to judge you. It's just context.
No subscriptions. The basics should be free. If there's a paid part, it should be a one-time thing.
Privacy by default. .keepgoing/ gets auto-added to your .gitignore so you don't accidentally commit your workflow notes.

Basically, I wanted something I'd actually be comfortable running on all my personal projects.

You don't need more hours. You need less friction.

Most side projects don't fail loudly. They just… stop getting opened.

In my case, it wasn't a lack of ideas or a lack of skill. It was the invisible tax of context switching, having to rebuild my mental state every time I came back after a break.

Using KeepGoing on my own stuff for the last few months has made a noticeable difference. Coming back after a week off used to feel like starting over. Now it feels more like unpausing a game.

I open the project, the sidebar pops up, and I see something like:

"Was refactoring the auth flow; next step is updating the callback handler and testing with provider X."

…and I'm usually writing code again within a couple of minutes.

That's really all I wanted out of this: make the resumption tax as close to zero as I can, without turning my side projects into process-heavy work.

If this resonates

If you've also got a side project graveyard, or you've felt that weird resistance to reopening an old repo, you're exactly who I had in mind when I built this.

You can check it out here if you're curious:

But mainly, I'd love to hear how you deal with this yourself:

Do you leave notes to future-you somewhere?
Do you rely on commit messages?
Do you just accept the 20-minute "what was I doing?" cost?

I'm still actively iterating on this, so any stories, ideas, or "here's how I've hacked around this" comments are very welcome.