Two hundred-something tables, old schema to new. Field names, types, foreign keys — all had to be checked. I estimated two days.
It took four. About one of those was spent waiting on my usage limit to reset.
What I did wrong at the start
I dumped the entire schema in one go and asked for a migration plan table by table. First twenty went fine. Somewhere past fifty it started making mistakes — confusing two similar tables, re-processing ones it had already handled.
At the time I assumed the model was just not good enough. It wasn't. The context was full. Fifty tables' worth of content was sitting in there, and it had to locate the current one inside all of that noise.
This is the part I wish I'd understood earlier: usage is metered on context, not on the number of questions. Every request carries the full conversation history. A one-line question in an eight-hour session can cost more than ten times the same question in a fresh one.
What actually worked
I switched to batches of ten. After each batch:
- Write progress to a file (what's done, decisions made, gotchas found)
- Clear the context
- Before the next batch, read the progress file back
Error rate dropped. So did consumption — each batch now carried ten tables plus a short summary, not an accumulating two hundred.
That "write progress → clear → re-read" loop became my default for any batch job. It's not clever, it just works.
A few other habits from the same project
- Ask for a runnable check, not a description. "Migrate this table and run the schema diff" beats "migrate this table." When there's a check it can execute, it iterates on its own instead of stopping at "looks done."
- Delegate exploration to a subagent. When I needed to understand how the old schema was actually used across the codebase, I had a subagent read the files and report back a summary. Its context absorbed the noise, mine stayed clean.
- Don't keep a session open all day. I used to. The cost curve at hour eight is brutal.
The part nobody warns you about
Doing this properly costs more, not less. Runnable verification means extra iterations. Subagents mean extra context windows. A separate reviewer pass means another agent entirely.
So halfway through the month you end up in a bad spot: limit is close, and the thing you're tempted to cut is the verification step. Which is exactly the wrong thing to cut.
What actually solved this for me was decoupling "how much capacity I need this week" from "which tier I pay for every month." A migration like this is a three-day spike — the rest of the month I'm nowhere near my ceiling. Upgrading a tier for three days is a bad trade, and waiting out a reset in the middle of a batch job means re-establishing context afterwards, which costs again.
I've been using Asale for the spikes. The mechanic is simple: people whose subscription capacity is going unused list it, people who need it draw from it. What made it practical for a job like this rather than just cheap:
- You can see what you're paying before you commit — it's priced per million input/output tokens with the percentage of list price shown next to each model, so it lines up with how you already think about API cost
- It's not tied to one vendor, so when I wanted to sanity-check a tricky migration against a second model I could do it without holding two subscriptions
- Top up, finish the batch, stop. No monthly commitment left behind to forget about
The tradeoff you should know before trying it: requests are relayed through another user's client, so the payload is visible at that hop — no end-to-end encryption. They state this on their own homepage, along with a note that sharing subscription capacity may conflict with upstream terms. That defines the boundary cleanly enough: personal projects and open source, yes. Company code, no.
Client's on GitHub if you search asale. Source is public, which is the part I cared about given a request passes through someone else's machine.
Curious whether anyone has a better pattern for batch work than the progress-file loop. Mine feels crude but I haven't found something better.
Top comments (0)