I'm on similar plan through work ( Teams max ), and I've only ever reached the limits by backgrounding large exploratory feasibility studies while also getting on with actual work.
From what I can tell however, true "vibe coding" gets a lot more expensive very quickly.
If you're actually just agentic engineering, then after a couple of mis-fires you'll stop, re-analyze what it is doing, what you asked for, and consider different approaches.
With pure "vibe coding", you'll keep asking it to meet your requirements as it twists and turns in the background to try to fit.
A more concrete example from a personal "game" I'm developing as a hobby:
Fable got itself in knots trying to render some fairly basic blocks on top of a wall. It understood the problem, it consistently rendered as "fins" under screenshot, and thrashed away for a good while trying to produce better looking blocks to no avail.
Eventually it stopped, and lied that it was happy with how the walls now rendered.
It took me 30 seconds in-game to realise that it was only rendering backfaces, once clued into that, the machine was able to trivially fix it without using much tokens.
But then another similar issue popped up later, hedges exhibited the same behaviour.
It would have been easy to accept the solution to render the hedges in the other order too, but I demanded a better explanation, and it turns out that it had fairly early on defined a DrawBox() method that was backward to Unity's expectations, and pushing further, it emerged this all started when I asked it to transfer what it had learned from a webGL prototype to unity.
It took things a little too literally, which is also how I ended up with an Eastward sunset at first. When I asked it to fix that, I hadn't realised that it's solution was to essentially reverse coordinates and world understanding.
Now, this stemmed from a lack of understanding or review of the 3D code, it's a vibey hobby that I'm using to learn what really goes into rendering a scene.
Had I been a professional, I would have absolutely caught that error ( and many others ).
So being professional would have helped reduce token expenditure massively, firstly by slowing down what could be done to leave time for review, but secondly and perhaps more importantly, by avoiding it getting into a state where it thrashed away for an hour trying to solve an impossible puzzle because the base assumptions were wrong.