Running Python work without freezing your PC: the PyRe guide

By J.E. Herizon LLC · Published September 27, 2026

For anyone running serious Python on Windows — data pipelines, quant backtests, llama.cpp-class local models — the failures that hurt are usually not in your code. They are the four-hour ETL that freezes the desktop, the overnight run whose terminal history vanished, and the “GPU-accelerated” tool that reports a speedup for work that never touched the device. PyRe is a local-first Windows workbench that plans, queues, runs, and records your Python work, with guardrails that keep the PC usable and honest, measured control over GPU acceleration.

Key takeaway: PyRe is the control layer around your scripts and your local AI stack. It does not rewrite your scripts, it does not pretend to schedule them, and it refuses to claim a speedup it cannot demonstrate. Every feature below is a build-verified claim you can test yourself in the free download.

One workbench for scripts, runs, and status

PyRe replaces the “which of my five terminals ran that?” problem with a single native Windows desktop workbench (PySide6/Qt6, shipped as an MSIX package). Add scripts by drag-and-drop, organize selected runs in one place, and keep status and results close at hand. Run one script with F5, or submit the whole selected queue in order with Ctrl+F5; every submission carries an immutable source identity, so a run that started at night is traceable to the exact file that launched it.

The live run queue shows each run’s state as requested → selected/running → verified, with durable IDs across paginated snapshots — and stale or disconnected states are labeled honestly instead of guessed at. Output lands in a bounded log tail, so you read your own stdout and stderr without hunting through files. When something runs away, one-click force cancellation tears down the OS job-object tree in under 150 ms, and cancel, pause, and resume intents all settle into durable state — no growing collections of zombie python.exe processes.

Real-time meters in the GUI track RAM, VRAM, committed memory, and GPU temperature; a native Windows tray monitor surfaces VRAM, compute utilization, and thermal metrics while you stay in other applications. And the GUI is not the run’s life support: close the window and running jobs keep going, reopen and status re-syncs, and pending requests were durably persisted before IPC and replayed. Unattended work survives a closed window, a reboot, or a crash without losing the record.

Allocation & planning: review the plan before you press run

PyRe’s core promise is “review an allocation plan before a run and leave capacity for Windows and the other apps you have open” — and it is delivered as a pre-run review, not a wish. Before anything executes, you see the resource plan a job will consume, so a four-hour ETL does not evict your IDE, browser, and market feeds mid-afternoon.

The default allocation targets roughly 70% of measured free RAM — not 70% of the manufacturer’s sticker capacity — so the OS and your open apps keep breathing without tuning. --workers N --reserve-threads M sizes CPU parallelism while explicitly reserving threads for Windows itself. The device-budget grammar handles VRAM as percentages or absolute sizes, per device: --device 0,1 --vram 0:8G,1:6G, with host-RAM budgets and B/K/M/G/T sizes including KiB/MiB variants.

An admission governor refuses to start a run it cannot satisfy — when host load, RAM, commit, or disk is over threshold (host-load refusal at roughly 85% CPU), you get exit code 75 instead of an out-of-memory crash. For Torch and CuPy workloads, allocator ceilings are applied before the framework is even imported, and a backend_limits.receipt.json records them — the mechanism that stops an AI model from grabbing every GB of VRAM the moment it loads, which is how Windows desktops actually freeze.

Run records & receipts: did yesterday’s 2 AM run finish?

“See what started, what finished, and what needs attention. Keep a run record to check afterward” — that is the page promise, and the machinery behind it is a persistent ledger of every run with its outcome. The 2 AM question is answered in seconds from durable records, not from a dead terminal’s scrollback.

Each run carries one of a stable set of exit codes (0 / 64 / 74 / 75 / 130) and validated output paths, so success, bad arguments, parity failure, admission refusal, and interrupt are distinguishable deterministically. Completion and admission events are published as cryptographic, atomically-written run receipts, identity-bound and documented — the trust layer for unattended work. Resource snapshots carry observation timestamps and stale readings are flagged, so telemetry can never be mistaken for live state after a collection failure. The ledger and receipts persist across GUI closes, service restarts, and attach/detach cycles. And attribution is honest by design: GPU utilization is labeled device-wide and never falsely credited to your process — no fabricated “this run used X% of the GPU” numbers to build reports on.

GPU for local AI — the honesty is the feature

This is where PyRe deliberately refuses magic, and the refusal is the pitch. The landing-page FAQ states the position verbatim: “GPU execution is optional… PyRe does not turn ordinary CPU code into GPU code.” PyRe coordinates your selected runs; your script must specify how it uses a device. What PyRe adds is a chain of checks that make acceleration verifiable:

• Explicit device and backend selection. Choose CPU, NVIDIA CUDA, AMD ROCm, or Intel XPU lanes (cpu / cuda / rocm / xpu) with torch, cupy, or numba backends and explicit device IDs. You decide which hardware a run uses; the workbench does not silently guess with your hours.
• GPU discovery and hard isolation. PyRe probes for discrete NVIDIA GPUs via nvidia-smi and enforces CUDA_VISIBLE_DEVICES=-1 on CPU runs, so a CPU run cannot accidentally touch the GPU and vice versa.
• Capability checks before you commit. An accelerated run requires a fresh, compatible interpreter/device capability record, and the check is public in the published example script (/pyre/how-to.py). You learn before the two-hour run whether your machine, driver, and stack can actually do the job.
• Parity-verified acceleration. The published example runs the same computation on CPU and device and requires exact or tolerance-bounded parity (assert_close), with timing that includes the transfer. “Faster on GPU” is only claimed when the result matches.
• Measured crossover routing. An adaptive router routes per batch to CPU or accelerator using a measured, transfer-inclusive crossover; small batches stay on CPU and only parity-proven large batches go to the accelerator. The unit of progress is completed work per second, not a vanity GPU percentage.
• VRAM reservation and OOM protection. PyRe reserves hardware to eliminate multi-process VRAM thrashing and CUDA out-of-memory aborts, and refuses admission rather than freezing the OS.

GPU runtimes are staged as version-pinned, distinct artifacts (copy → verify → atomic activate), so CPU and CUDA environments never collide — no PATH conflicts, no “CUDA 12 on a CUDA 11 wheel” breakage. For models, an optional warm-state service keeps SHA-bound TorchScript models and a Torch accelerator context hot over an authenticated local socket (typed-array RPC, no pickle): you pay the model-loading cost once, then call inference hot, strictly local. And automatic routing is conservative by default: the auto mode inspects Python source without executing it and stays on CPU when the evidence is ambiguous, so a missing torch install cannot silently kill a run.

The source docs put the philosophy in one line worth framing prominently: imports are evidence of intent, not proof of a speedup. For developers burned by tools that lie about acceleration, that line is a buying trigger — and it is a compliance asset, because every ad can quote the homepage FAQ verbatim.

Environments: version-pinned, per-device, no dependency hell

PyRe does not pretend to be a click-to-create virtual-environment manager, and it does not edit your arbitrary project venvs. What it actually ships is the version-pinned, per-device environment machinery: the installer creates an isolated per-user environment without administrator access, and CPU and accelerator environments are separate, pinned artifacts — the Store’s “zero PATH conflicts or dependency hell” promise.

Preconfigured presets via pyre --env — nvidia-cuda, amd-rocm, intel-oneapi, apple-mps, cpu — detect the system tools (nvidia-smi, rocm-smi, rocminfo, xpu-smi, sycl-ls, clinfo) and ship ready-to-use activation scripts; you choose among environments, and PyRe resolves the interpreter, tools, and visibility from the machine. Per-backend interpreter routing keeps incompatible frameworks apart — a torch-cu121 environment and a pandas ETL environment do not fight over one interpreter — and validation errors surface under explicit names such as PYTORCH_NOT_INSTALLED_IN_SELECTED_INTERPRETER instead of failing somewhere in the middle of a run.

The distribution itself is sealed and offline: an AES-256-encrypted package (.pyrepack) with ABI wheels for CPython 3.10–3.13 and zero runtime downloads. The whole product — including its Python runtimes — ships inside the Store package and runs offline.

Unattended and durable runs

PyRe has no built-in scheduler, and it will not pretend otherwise. What exists instead is the assembly kit for unattended operation, and you put the pieces together yourself:

• --headless detaches a run after startup and follows it through durable state, producing the same records a GUI run produces, with stable JSON output.
• Every detached run gets a separately detached supervisor guard with PID-identity checks and heartbeat freshness monitoring; if the runner dies silently at 3 AM, you get a supervision.alert.json file, not a mystery.
• Running jobs are owned by a durable, zero-telemetry controller service — closing the GUI workbench or rebooting does not kill them.
• --resume verifies the recorded source bytes and arguments before reusing a launch plan, and task checkpoints resume from an immutable expected-task matrix using exact set subtraction instead of trusting exit codes — a 50,000-shard pipeline that died at shard 40,000 resumes from what actually completed.
• Journals are append-only JSONL with explicit loss and replay boundaries and configurable fsync policies (per_row, batched, interval) — you pick how much durability you pay for.
• --command python -m pkg … supervises arbitrary launch commands under the same guardrails and records.

Because headless detach, resume, and receipts exist, you can drive PyRe from your own external automation — Windows Task Scheduler being the obvious example — and every run it launches is still governed and recorded. That wiring is your assembly, not a built-in cron; PyRe simply turns unattended work into an evidence trail.

Local-first, zero telemetry, and scriptable

PyRe runs 100% offline: no cloud token meters, no model or prompt upload, no external leaks. Telemetry is zero — privacy is structural, not a settings toggle you are asked to trust. All IPC is localhost-only and token-authenticated with constant-time comparison, fixed 256 KiB frames, and bounded peers and commands — a local execution controller the network cannot poke. Distribution is a verified MSIX through the Microsoft Store: per-user install, no administrator rights, no sketchy installers, and installation on up to ten Windows devices per Microsoft account.

The CLI is the automation surface with stable contracts: pyre-gpu <script> with --dry-run (prints a plan without executing — built for CI), --json with the stable pyre_cli/v1 object, --quiet, --profile <n> (py-spy attach without double-running), --state-dir, --backend, and the same stable exit codes the ledger records.

Pricing: free, then a $3.99/month choice

The landing page deliberately quotes no paid price — its line is “Free download for Windows. See current pricing and requirements in the Store on the Microsoft Store,” and the download answer is “the Microsoft Store button on this page. The listing is free to open, the free trial is there, and the requirements are there too.” The Store’s only exposed number is the in-app subscription line, stated verbatim: “In-app subscription via Stripe ($3.99/month) delivers offline Ed25519-signed licenses.”

• Free. The Store listing itself is free (price $0.00, sign-in optional).
• Trial. An automatic 30-day free trial is included on initial download, with zero setup hurdles and no credit card.
• Subscription. $3.99/month, in-app via Stripe, delivering offline Ed25519-signed licenses.

Requirements from the Store listing: minimum — Windows 10 version 17763.0 or higher, x64, DirectX 11, 4 GB RAM, 2 GB video memory; a dedicated GPU is not required and CPU fallback is supported. Recommended — 16 GB RAM, 6 GB VRAM, a 4-core x64 CPU with AVX2, and an NVIDIA CUDA, AMD ROCm, or Intel Arc-compatible GPU with 8 GB+ VRAM for accelerated workloads. The package is roughly 6.9 GB (up to about 15.6 GB with device runtimes installed).

If you are deciding between renting cloud GPU hours and using the hardware you already own, the demo path is deliberately short: install the free download, run the published example at /pyre/how-to.py, watch it print your device check, compare a CPU and a device result with parity verification, and decide with your own evidence in hand.

← All articles