These two approaches produce the same outcome for sleep and completely different outcomes for everything else.
A power request is a declaration. The application creates a request object carrying a reason string, then sets the flags it needs — system-required to prevent sleep, display-required to keep the panel powered. Windows honours it for as long as it is held and stops the moment it is cleared. It is inspectable: the operating system can list which applications are currently holding requests and why, so the behaviour is auditable rather than mysterious. StayGreen sets a reason string stating plainly that it is keeping the PC awake at the user's request.
One implementation detail explains a real reliability difference. There is an older API for this that sets an execution-state flag, and it is thread-affine — the flag belongs to the thread that set it. StayGreen sets and clears its awake state from several places: the command thread handling your clicks, the task that expires a timed session, and the worker receiving Windows power and lid events. With a thread-affine flag that produces inconsistent behaviour, which is documented in the source as the reason the newer request API was chosen instead. So if you have used keep-awake utilities that sometimes did not release properly, that class of bug is what this avoids.
Synthetic input is a lie, and Windows knows. Injected input is flagged as such at the OS level, and any monitoring tool can read that flag. It is not stealthy. It also has real side effects: the pointer moves, keystrokes land somewhere, and anything watching input for its own purposes sees traffic that did not come from a person.
Where they genuinely differ. A power request does not generate input events, so it does not reset the system idle timer. Anything that infers presence from that timer — collaboration status indicators, most obviously — is unaffected by it. A jiggler does reset it, which is precisely why people reach for one. If your actual goal is a green status icon rather than a machine that stays on, these are different problems and a keep-awake tool is not a solution to the first.
On that, StayGreen is not entirely without an answer, and it is careful about it. There is an optional presence mode that sends a single innocuous key signal on a slow interval. It is off by default and cannot be enabled without an explicit consent step; the setting is re-validated whenever configuration is loaded or written, so it cannot be switched on by editing a file. It only emits while a power request is genuinely held, never while the session is locked, and only inside optional active hours. The interface states outright that this is detectable, because injected input carries that OS-level flag and pretending otherwise would be dishonest. If your environment has a policy about this, that policy applies — and the feature is built so that using it is a deliberate decision rather than a default you did not notice.
