Choose the smallest reversible action first

There are three different jobs that are easy to confuse: seeing what QuotaWake knows, pausing automatic sends, and removing the background service. They are deliberately separate. A pause lets you preserve configuration and logs while preventing automatic readiness. Stopping the service ends background scheduling. Uninstalling the service removes its registration.

That sequence is useful when you are troubleshooting, taking a break, changing providers, or simply deciding whether the tool fits your workflow. It also avoids treating local automation as a black box.

1. Inspect before you change anything

Use the status command to see the current provider and quota-window state in a human-readable form. Use the JSON variant when a script or another local tool needs stable values.

quotawake status
quotawake status --json

If you want observation without sending a prompt, use the provider-specific observe command. This is the right first check when the question is “what local signal is visible?” rather than “should a readiness prompt run?”

quotawake observe claude
quotawake observe codex

2. Review the local record

QuotaWake records local activity so a decision can be inspected after the fact. Review recent entries before changing a setting, especially if you are investigating an unexpected run or an unknown state.

quotawake logs --limit 20
quotawake logs --limit 20 --json

Look for the provider, time, exit result, duration, decision source, and confidence. A log can explain what the local process did; it should not be treated as a promise about a provider-side account state.

3. Pause automatic readiness

Pausing is the preferred reversible control. It keeps your local configuration available while instructing QuotaWake not to perform automatic readiness sends.

quotawake config set readiness.paused true

Check the result with quotawake status or quotawake config get --json. When you deliberately want to resume later, change the same setting back through the configuration command after reviewing your provider selection and active-only policy.

4. Stop or remove the background service

Use the service controls when you want to change the lifecycle of the background daemon itself. Stopping is appropriate for a temporary halt. Uninstalling is appropriate when you no longer want the per-user service registered.

quotawake service status
quotawake service stop
quotawake service uninstall

These commands address the service registration, not every local file automatically. QuotaWake’s documented state roots contain settings, logs, quota-window data, and runtime files. Review anything you want to retain before manually removing local application data.

5. Know the local data location

On macOS, the documented default is ~/Library/Application Support/QuotaWake/. Linux and Windows use their platform-appropriate local state roots. The project also supports an explicit QUOTAWAKE_HOME location. This is useful when you need to inspect or back up local state rather than delete it blindly.

For a full command reference, consult quotawake --help or the project README. The exact lifecycle behavior may evolve as platform support moves beyond its developer-preview stage.

What this guide does not do

It does not ask you to remove files, change provider account settings, or infer a provider reset. It explains the local controls QuotaWake owns. If a command produces a result you do not understand, keep the automation paused and review the local logs before resuming it.

Evidence & source material

Commands and state locations in this guide are taken from the published project documentation. Check the source before acting on a newer release.