there are many causes, but it’s a drift in performance

you can drift a tool via the harness in many ways

you can modify the system prompt

you can modify the underlying model powering the harness

you can use different “thinking” levels for different processes in the harness

you can change the entire way a system works via the harness, which could be better or worse, depending on many things

you can introduce anti-anti-slop within the harness to foil attempts from users using patch scripts

you can modify how your tool sends requests to your server depending on many variables

you can handle requests differently, depending on any variable of your choosing, at the server level

you can modify the compute allotment per user depending on many things, from the backend, without telling the user, it’s very easy. you can modify it dynamically depending on your own usage or the user’s cycle. Or their organization’s priority level as a customer. The weekly and daily usage management system is intricate, compute is very finite and must be managed

the user has literally no way to know and you have no legal obligation to tell them, you never made them any legally binding promises

the combination of so many factors that all affect each other means that you can, if you’d want to, create a new clusterfuck of an experience anytime any of these or unknown variables change, it may not even be deliberate, it grows exponentially complex, so you may not even be able to promise a specific standard to your users

drift is not imagined, sure, but admitting to it could expose you to unneeded liability

That's a lot of words without actually defining the term, although idle_zealot's suggestion of "change" seems to make grammatical sense as a replacement here.