AI governance gets weird when it turns into a yes/no committee. The better question is usually not "should we allow AI?" It is: - what problem is this rollout actually solving - who owns the risk when the workflow changes - what evidence proves the control is working - where does the risk register live once everyone starts moving fast That last bit matters. AI adoption does not fail because someone forgot to write a policy. It fails because ownership, evidence, exceptions, and follow-through end up scattered across docs, tickets, chats, vendor portals, and somebody's memory. Then the committee becomes the brake because nobody can see the operating picture. Governance should be the thing that lets good teams move faster. Clear risk appetite. Visible owners. Evidence tied to the control. A risk register people can actually use while the rollout is still moving. That is the difference between "we have an AI policy" and "we can prove this AI rollout is being managed deliberately."

Summary: Whenever you feel your credits per prompt are increasing start a new/fresh session! --- Maybe it's a no-brainer; perhaps I never thought about it, because when building my fluXTimer app, I was thinking to be normal, that with the increasing amount of code, it must have been some kind of "logical" that prompts are becoming more expensive when the code base is expanding: from initially 50-100 credits to 1000-1500 credits on average for new features added. Finally, I was forced by Perplexity (which was not able for days to start its internal sandbox again and/or resolve its technical problems - which is a topic on its own about the worst support I have ever got) to start fresh with a new session (and luckily I had all my already generated code on GitHub - so resuming work on this was a breeze). And - taraa - I have found, that the new sessions did not only "fix" Perplexity's internal problem (and they did not compensate for this), but adding a new feature was again around 100 credits rather than 1000-1500 in the old "job". So, just starting a new session saves me 90% and increases the credits I would have spent when continuing in the same session any longer. Conclusion: At least for Perplexity, the credits are measured dominantly by session length and not the amount of code lines of your app! Maybe for you this is basic. However, I was never aware, and most probably it has been something I have overlooked - because so simple. Summary: Whenever you feel your credits per prompt are increasing, start a new/fresh session!! And here is what perplexity says about this: Long-running sessions accumulate context — every prior message, tool call, and tool output (like the full npm run build logs, file contents, and git diffs from earlier in our fluXTimer work) stays part of the conversation history. Each new response has to reprocess all of that accumulated context, so token usage — and therefore cost — grows with session length. A fresh session starts with none of that baggage. Rebuilding the project there only needs the context relevant to that specific request (clone, build, fix, push), so it uses far fewer tokens for the same outcome.