Help & safety

Help & safety

Product functionality and AI assistance
AI Shutdown Timer is a rule-based Windows timer that automatically detects supported running AI processes. “AI” (artificial intelligence) in the product name refers to the AI applications being monitored. The app contains no integrated AI model, chatbot or generative AI. It uses predefined algorithms, local measurements and available signals. Local background-load calibration also calculates reference values using fixed rules and does not train an AI model. The app does not call an AI service for this analysis.

Generative AI tools supported the development and design of the software and the creation of its app icon. These tools are not an integrated runtime feature of the app. The provider remains responsible for the supplied software, agreed functionality and statutory obligations.

Test safely
Timer starten.cmd opens the regular app with optional test mode initially checked. Vorschau starten.cmd hard-locks PC actions and uses a separate preview profile. Opening never arms a timer. Test mode logs the trigger/time without a PC action. A real run asks for additional confirmation. Save your work first.

Actions and triggers
Shut down, restart, hibernate, sleep, sign out, lock or display off. Enter a duration in hours/minutes/seconds or select a clock time using Windows or your 12/24-hour override. Schedule supports individual weekdays with up to four times each. Advanced triggers include CPU, network, input idle and process exit. Saved settings do not start themselves.

Choose your timer view
Appearance & startup contains Design, Timer view, Visible content and Startup. Regular timers default to a small strip with no extra resource queries. AI monitoring defaults to a window with CPU/GPU/network readings and charts. Regular/AI runs each have independent strip/window content profiles. Choose action, countdown, state, scheduled time, individual readings, charts, progress and AI trigger time. The window fits the contents. Extra whole-PC sampling occurs every five seconds only for visible regular metrics and stops when minimized. AI views reuse the existing monitor. Display choices never change trigger rules.

Windows and warnings
Drag a free area even with Always on top. Opacity affects this widget's own surface; text remains readable. Choose any screen corner. Minimize keeps the timer in the taskbar; click to restore. Back to app opens the running main view; Back to timer view restores the same strip/window. The widget status button opens the history window; clicking it again closes it. The timer keeps running.
Regular timed runs keep their deadline. Final warning defaults to 10 seconds and allows10–3600. AI confirmation starts a 30-second countdown by default, adjustable in AI detection → Goals and protection. Amber countdown precedes the final red warning. Newly detected AI work revokes clearance. A rendered final warning is required before dispatch.
Ordinary Stop asks to keep running, stop or stop and adjust. The timer continues while you decide. The final emergency Stop acts immediately. +10 minutes/+1 hour accumulate with repeated clicks. The ordinary warning hides five seconds after the last extension, then returns before expiry; Close countdown only hides it. Run now never skips the final safety interval.

AI detection and limits
Automatic selection discovers known running apps; installed does not mean active. Custom executable names are supported. CPU, available GPU/TCP values, supported visible generation buttons and configured local Codex/Claude-Code hooks complement each other. Extra PC/download/program rules are vetoes: every selected condition must pass. Idle is an estimate, not proof of remote completion or correct project files. The network display identifies AI or PC as its source. If AI TCP is unavailable, an available whole-PC rate is labelled PC. The original measurements and trigger rules stay separate. If both values are unavailable, the display shows —; a measured zero remains 0. Availability depends on versions/drivers/rights; TCP does not include UDP/QUIC. No paid AI API or extra AI tokens are needed.

History, privacy and parent mode
History filters individual runs by start date/time and records diagnostics, charts and trigger markers. Fixed age/count/size limits prevent unlimited growth; cleanup happens while running. Regular journals share a 1.5MiB budget. Clear history removes history/diagnostics/charts, not settings or active completion signals. Review exports before sharing. Offline privacy/license notices are under Info & privacy.
Parent mode requires a separate standard child account and an administratively installed independent service. Parents configure a password, one-off playtime, weekly windows and date exceptions. Changes/stop/extensions need elevated Windows parent rights and the parent password. Child warnings have no stop/extension control. Closing the child GUI does not stop the service, and persisted deadlines survive restarts. Administrator, Safe Mode, external boot, firmware/disk access and shared parent credentials are outside protection. No absolute anti-bypass guarantee is made. Installed multi-account/restart acceptance is still required. Enforcement can lose unsaved work and requires parent consent.

Startup and support
Startup opens the app on Windows sign-in without arming. It applies immediately and cannot be changed in a locked test launch. Keep a configured portable folder fixed. Windows can restrict startup/foreground requests. Support is contacted only when you send your own message; do not send passwords or chat text. This is a local release candidate, not Store certification.


FAQ: CPU and local calibration

Does every CPU need its own threshold?
No. Measured app activity also depends on app versions, open windows, background jobs and Windows state. A ranking with one setting for the supposedly worst processor would be too coarse. The app detects CPU model and topology for diagnostics; it does not raise a threshold based on them.

How does recommended automatic detection work?
Leave “Account for stable background CPU when detecting idle” enabled. For small stable load near the threshold, the app can learn a background level after at least six samples spanning two minutes, provided visible generation checks are available and report no activity. Learning is capped at 10% of one core and twice the configured CPU allowance. The full configured idle grace then starts again. Clearly low CPU load needs no raised background allowance. New targets or sampling gaps discard the estimate; unavailable UI observations remove the extra allowance. Active generation and configured GPU, network or agent vetoes remain effective.

What is stored and reused?
“AI detection → Measurements and options → This PC and local calibration” shows CPU information and the most recent confirmed idle observation of the monitored apps. cpu-reference.json contains CPU model, logical processor count, processor groups, architecture, Windows version, counter source, and the observation time, app names, CPU value and background/limit at that time. No serial number, device identifier or chat text. The file is limited to 16 KiB and remains local. The observation expires after 30 days or a change in hardware, Windows or measurement context. Every run evaluates afresh; a saved value never shortens idle grace or permits an action. “Delete saved measurement” removes the reference while preserving CPU information and settings; it is disabled during a run. Clear history does not remove this reference.

The timer remains armed. What should I check first?
Open “Status and test history → Current measurement”. The decision and individual requirements identify the veto. First check that only the relevant apps are monitored, that no generation is still visible and that a download, PC or program-exit rule is not waiting. Unavailable UI, GPU or network data is not measured zero. Direct events from supported local agents can help. Without such interfaces the app cannot reliably inspect every remote job.

When does manual adjustment make sense?
Only when repeated controlled tests show that the relevant apps are finished and an overly tight CPU limit is the sole veto. CPU thresholds and local calibration refer to ONE logical core. The visible CPU load is normalized to the whole CPU on a 0–100% scale. For example, with 16 logical processors, 16% of one core corresponds to a 1% whole-CPU display. Do not compare the display and threshold directly. With automatic background enabled, the field is the allowance above freshly learned background; otherwise it is an absolute limit. If necessary, increase it by one percentage point at a time and test both active and finished tasks in test mode after each change. Do not raise a threshold to override known activity. Independent guards and idle grace remain. The processor model alone is no reason to adjust a setting.

Does this guarantee completion of every cloud job?
No. Local calibration improves the idle heuristic but does not replace a direct completion event. Check your apps in test mode before permitting real PC actions. Opening the normal app or saving settings never arms a timer by itself.


Behavior
Appearance & startup → Behavior: remember last start values, start in the system tray, remember the main window position and use a steady warning. Timer position memory is configured under Timer view beside the screen-corner selection. Clock format applies throughout the app. Apply saves these settings together; Close discards the draft. Only startup changes apply immediately. The tray icon restores hidden timers; final warnings still appear in the background. “Hide only” does not stop a run. Test mode still starts checked.


Run report
History opens the report with the outcome, start times, original rules, decision evidence, whole retained timeline and a few evidence-based adjustment hints. Individual events, diagnostics and charts provide detail. The time filter affects only those detail views. Choose the selected run or all retained runs at the bottom; Export report saves local printable HTML or optional support JSON. Current settings never replace missing historical data. Missing ending events establish neither success nor an active timer. A recurring schedule remains active after one occurrence while its explicitly started session is running. After clearing, an active run records new observations with the original rules and an explicit gap notice.