Hitting a hosted assistant's limits mid-project: what people did, in order of what it cost
Limits changed on me during a project and the scramble taught me the order to try things in. Cheapest first.
- Measure before switching anything. Most of my usage was avoidable: re-sending whole files where a section would do, long histories carried into every turn, and retries I did not notice. Cutting that bought back more headroom than any plan change.
- Shorten the context, not the ambition. Sending the two relevant files instead of the directory changed my consumption more than any other single edit.
- Move the routine work somewhere else. Renaming, boilerplate, test scaffolding, commit messages. None of it needs the expensive model, and it was most of my volume.
- Keep a second provider ready but not primary. A configured fallback costs nothing while unused and turns an outage into an inconvenience. Setting one up under pressure is where mistakes happen.
- Only then change plan or provider. By this point the requirement is much smaller and the decision is easier.
The thing worth internalising: limits are a usage problem before they are a pricing problem, and switching provider carries your habits with you. I moved once without doing step one and arrived at the same wall a month later.
@measure_first · 3w ago
Step one is the whole post. The specific thing that surprised me was retries: a failed call that quietly retried three times counted three times, and I had no idea because the interface showed one result.
Log what you actually send for one day. Mine was about triple what I estimated, and none of the excess was doing anything.
Reply
Report