ParetoStackpareto-stackdocshpc-labs

What changed from one version to the next

Newest first. Each entry lists what was added, changed and fixed, and what was measured. Each version's own documentation is under its number.

ParetoStack 0.4.5 (2026-10-29)

  • Update notice (ported from the 0.5 line, 217c497): paretostack update and /update in the assistant say whether a newer version of the SAME product line exists (0.4.x is never pointed at 0.5, 0.3.x never at 0.4), from the public https://hpc-labs.ai/releases.json read at most once a day with a 2 s timeout, cached under ~/.cache/paretostack/, silent on any failure; nothing about you, your machine or your code is sent (a plain GET). After an interactive command the notice goes to stderr; the assistant shows it under its banner when interactive. Off with PARETOSTACK_NO_UPDATE_CHECK=1 or PARETOSTACK_OFFLINE=1. paretostack/updates.py, tests/test_updates.py.

ParetoStack 0.4.4 (2026-10-28)

  • Database access, the first rule of the cloud product's database work (docs/DB_ACCESS.md): py:db_batch (L3, on by default, bit-exact). A loop that runs cur.execute("SELECT ... FROM t WHERE col = ?", (key,)) + fetchone() once per item (the N+1 pattern) runs ONE WHERE col IN (...) query per table before the loop, in chunks of 500 keys, and hands each item its row exactly as fetchone would; the per-item statements stay in the code as the fallback (a key the batch did not see, a key with several rows, rows that are not tuples, a driver that refuses the batch). Loops that write are never rewritten; several read pairs in one loop each get their own batch. DB-API 2.0 cursors (sqlite3, psycopg, mysql; ? and %s placeholders). Keys may be the loop variable or a subscript / attribute chain on it (o["customer_id"], o.customer.id). The rule is in the search, in paretostack optimize and in the cloud zip optimizers (cloud lambda-optimize --zip, cloud gcf-optimize --zip): on the sample's recorded events the Lambda package verifies identical and 2.66x on this machine.
  • Database access, second rule: py:db_aggregate (L3, on by default, bit-exact). cur.execute("SELECT col FROM t WHERE ...") + fetchall() followed by sum(r[0] for r in rows), max(...), min(...) or len(rows) (also total += ..., return max(...), max(...) if rows else 0; the rows read nowhere else) becomes one SELECT SUM(col), COUNT(*), COUNT(col) statement; its value is used only when the column had no NULL (Python would have raised), the result is an integer (a float column's SUM is not the sequential Python sum) and the set is not empty for max / min; the fetch stays as the fallback. Same drivers and places as db_batch.
  • Two text rules, bit-exact, on by default, in the search, optimize and the cloud zip optimizers (also in 0.3.12; docs/TEXT_RULES.md): py:str_build (L1): a string grown piece by piece in a loop through a reference CPython cannot update in place (self.out += line, d["k"] += s, a global or nonlocal) is quadratic, every += copying the whole string; the pieces are collected and joined once after the loop, in a finally so an exception leaves the partial string as before. The string is not read and its holder is not called in the loop (other fields of the holder are fine); at run time anything that is not a str flushes the pieces and runs the original += at the same statement; a plain local is left alone (CPython grows it in place, measured as fast as a join). Several statements growing the same string share one list. py:re_hoist (L1): re.match(PATTERN, s) and search, fullmatch, sub, subn, findall, finditer, split, compile with a constant pattern and flags, inside a function, use a pattern compiled once at module level (the module-level functions look the pattern up in re's cache on every call, which costs as much as a short match); the compile is wrapped so an invalid pattern still raises at the original call. The text rules run before the attribute-binding rules and every reported line is the customer's own (a line map across the passes).
  • Sample log_report (in the wheel; tour step 20): an access-log report parsed with re.match / re.sub in a loop and grown on an attribute: 6.7 s -> 0.23 s on the GB10 (29x), report and summary byte for byte identical.
  • Sample lambda_db_orders (software and cloud products, in the wheel): a Lambda order-enrichment handler with a customer and a product query per order and a customer report added up in Python, on a SQLite fixture built by its harness (orders.db); on the GB10 in fast mode (a loaded machine): db_aggregate 1.94x, db_batch 1.83x, both 1.87x, responses identical; the harness alone measures 2.0x for both. The tours run it as step 19.

ParetoStack 0.4.3 (2026-10-27)

  • Offline mode for the assistant: /offline on (and paretostack models offline on|off|status, kept in the per-user config) checks the local runtime and model, looks for a newer model or runtime when the network is reachable, offers the (re)download (asks, skippable), then turns the cloud backends off for the session; /offline off restores. paretostack/offline.py; the fake-Ollama tests in tests/test_offline_mode.py.
  • The assistant (pareto) looks and reads like Claude Code: a welcome box in the brand colours (logo, product line, version, machine, project, model, tips), a coloured prompt, Tab completion of the slash commands and sample names, /help grouped by product. New commands: /pick (the sample picker), /cloud (check, probe, the offline package optimizers, the tuning plans; anything that creates copies asks first), /hw and /pcb (when the build has the chip line), /doctor, /models, /keys, /cost, /status, /version. The catalogue and colours are in paretostack/branding.py.
  • Fix: an install or an update no longer replaces a sample file the customer already has under ~/ParetoStack/sample (an edited sample survived only the Windows .exe installer): new samples and new files are added, edited files are kept and listed (copy_samples in lib-ensure.sh; the Windows share installer does the same).
  • Wider proof rules for the C/C++ loop pass (OpenMP, pipelining, unrolling): loop variables declared before the loop (the rewritten forms leave the original's final value), an empty init, literal / scalar / constant strides, <= bounds, bounds with member chains and casts, comma declarator lists, arrays indexed by the loop variable plus an invariant base (2-D nests by row), if / else bodies of the same statement forms, reads of another array at an offset (guarded), and sequential reductions into INTEGER scalars (unrolled and pipelined forms only). A floating-point reduction is refused: measured on the GB10, GCC fuses s += a * b into an FMA in the original loop and not in the unrolled copies, one ulp apart. On OpenCV core + imgproc and CPython's Objects (3 793 loops) the pass now rewrites 87 loops unrolled / 38 pipelined / 74 parallel, from 25 / 17 / 25.
  • Three more tricks, all bit-exact: source-level loop unrolling by 4 (cpp:unroll, L1) and software pipelining (cpp:swp, L2: the reads of element i+1 before the store of element i, behind the parallel loop's runtime alias guard) for the proven element-wise C/C++ loops (one transform per loop: OpenMP, then pipelining, then unrolling); inlining, unrolling + peeling and modulo-scheduling axes in the L0 flag tuner (inline, unroll-peel, swp) and as GCC candidates of the build search (unroll, inline, swp).
  • Three samples from the CPython exploration: py_workloads (the study's 13 pure-Python kernels as one program), lambda_py_workloads and gcf_py_workloads (the same kernels as a CPU-bound Lambda / Cloud Function worker: the samples for the cloud presets — package offline, C port, tuning plan, sandbox). In the packages and the tours (example.sh workloads).
  • paretostack examples pick [NAME PRESET] [--product software|cloud|chip]: a menu to choose a sample (the list is long) and a preset with a spread of settings (quick = fast mode bit-exact, bit-exact full measurement, accuracy contract, autonomous search, local AI review, cloud AI review; build search for a codebase sample), then the exact command is shown and run. example.sh / example.cmd with no argument open it on a terminal (all is still the tour); the chat has /examples pick. Product-aware (docs/SAMPLE_PICKER.md): the cloud product adds the cloud presets (deployment package offline, with a C port, tuning plan, sandbox tuning, cloud check) on the function samples; the chip product has its own samples (hw_, pcb_) and presets (analyze, quick / full / rewrites / proven / strength synthesis search, PCB analyze / route); the console's gallery shows every preset's command.
  • AI usage ledger: every AI call ParetoStack makes (analysis, chat, models/keys tests) appends one line of COUNTS to ~/.cache/paretostack/ai_ledger.jsonl (model, purpose, project, input / output / cache tokens, dollars when reported or estimated from a configured price and then flagged, seconds, success; never the prompt, the answer or code). paretostack ai-usage [--project P] [--days N] [--json] prints the totals by model and purpose and the tokens per VERIFIED win (wins from the Strategy Memory; none means none). Tokens of an external agent driving the command line are not in it. docs/AI_USAGE.md; tests/test_ai_ledger.py (6).
  • Audit: the 0.3.7 suite ran with no AI model in the loop (by construction: paretostack run reaches a model only with --ai, default none); tests/test_ai_isolation.py (3) keeps it true; a run-time tripwire on the word_filter example saw no model access and no ledger entry. docs/AI_USAGE.md.
  • packaging/token_ab.py: the A/B harness for the token-saving claim (the same agent with and without paretostack, every result judged by the sample's verify recipe, capped spending, plan without --go); tests/test_token_ab.py (5).
  • Recipes can define build candidates: builds: {stock, baseline, variants: [{key, title, configure, flags, lto, pgo, network, contract}], only} composed on the generator's baseline (buildgen.recipe_builds); a contract: true candidate is left out of a bit-exact search.
  • search --builds-only: the build candidates without the source scan (a C / C++ codebase's Python files are not transform candidates).
  • Verifier: the Mann-Whitney p uses the exact distribution for small samples (up to 10 per side, no ties). The normal approximation floored at p = 0.012 for 5 against 5 non-overlapping passes (exact: 0.008), so a recipe with 5 repeats could never pass the p < 0.01 gate; the OpenCV 5 study found it.
  • Tests: the build-generator test accepts the explicit -march the generator derives on Arm cores the compiler does not know.
  • Fast mode: a noisy machine gets at most 2 extra pairs (extra_pairs) before the conservative estimate decides; the full mode keeps 8.
  • Doctor and Java on macOS (found in the macOS trial, docs/MACOS_TRIAL.md): paretostack doctor lists macOS as experimental instead of MISSING and shows arm64 for Apple silicon; the JDK check runs javac -version and java -version (macOS ships stubs that exist but fail), and says why; a Java project or examples run java_box_sums without a working JDK now stops with "Java is not usable on this machine: ... install a JDK" instead of ending in "too few successful runs". tests/test_doctor_mac_java.py (4).

ParetoStack 0.4.2 (2026-10-27)

  • Fast mode (--fast on search and run, fast: in the recipe, "fast" in the console's search request): sequential early stopping after 3 pairs for candidates that cannot reach the gain gate (or whose output already differs), optional screening passes (PARETOSTACK_SCREEN=1 for a shorter workload), the original's passes pooled across the candidates of a search with a fresh drift-check pair, PARETOSTACK_PASS / PARETOSTACK_SIDE in every pass so a recipe can run its correctness part once per side, ccache launchers on the V8 build lines, and the next build overlapped with a remote (--machine) measurement. The verdict's meaning is unchanged. docs/FAST_MODE.md; tests/test_fast_mode.py (11).
  • Build candidates, OpenCV on x86-64: the native-CPU variants (native, native-lto, pgo) use OpenCV's CPU_BASELINE=DETECT instead of -march=native, which does not build OpenCV 5 on an AVX-512 CPU (SSE3-baseline universal intrinsics mis-select the 512-bit vector types; seen on a Ryzen 9 7950X, GCC 13).
  • Build candidates on Arm Linux: when -mcpu=native adds no feature over a plain compile (GCC 13 on the GB10's CPU part 0xd87 falls back to generic armv8-a: no dot-product, FP16, BF16 or SVE code), the native flags are built from /proc/cpuinfo's feature list (-march=armv8.2-a+dotprod+fp16+bf16+i8mm+sve+sve2 on the GB10). The native variants of the OpenCV 5 study had compiled exactly the baseline's code.
  • The source fingerprint (baseline-build cache key, remote copies) skips the project's own .paretostack/ folder: a project whose searches had built a few candidates grew past the 2 GB remote-copy limit through the tool's own installs and the next search stopped at the baseline build.

Changelog

What changed in each ParetoStack release, newest first. Written by hand from the git history (git log v0.2.0..v0.3.0, ...) and from the measured results kept in TASKS.md and docs/; the RELEASE-NOTES.txt in each dist/<version>/ folder is the raw commit list of that release. Dates are the commit dates (UTC). Numbers marked measured come from a verified run on the DGX Spark (GB10, 20 cores); the comparison of the examples across versions is in docs/BENCHMARKS_BY_VERSION.md (each version ran its own examples on the same machine; one run each, so read it as an indication).

Two numbers are easy to mix up: the package version (0.1.0, 0.2.0, 0.3.x: what you install) and the engine version (V1 to V10: which optimizers and features a project may use; the "Use optimizers up to" setting). A package version contains every engine version up to the one it names below.

ParetoStack 0.4.1 (2026-10-25)

Fixes, a clearer start for new users and an AWS Lambda and a Google Cloud Functions example to try the cloud commands on. The engine is the same as 0.4.0.

Added

  • A Google Cloud Functions example, gcf_log_digest (paretostack examples gcf_log_digest, the console's project list, example.sh gcf / example.cmd gcf, step 17 of the tour): an HTTP Cloud Function (main.digest_http) that reports on web access-log lines, with a local harness (harness.py) that times and verifies it offline, byte for byte, through a stand-in for the web request object, and writes recorded requests for the cloud commands. docs/GCF_EXAMPLE.md.
  • paretostack cloud gcf-optimize --zip PACKAGE --events FILE --entry-point NAME: the Google twin of lambda-optimize --zip: the exact optimizers on the function's own Python files, verified offline on the recorded requests on this machine (identical status and body; the timing is indicative); original.zip, optimized.zip, changes.diff, report.json in --out. A licensed command. Not built yet: --port for Cloud Functions and the live verification on deployed copies.
  • An AWS Lambda example, lambda_log_digest (paretostack examples lambda_log_digest, the console's project list, example.sh lambda / example.cmd lambda, step 16 of the tour): a handler (lambda_function.handler) that digests SQS batches of log lines, with a local harness (main.py) that times and verifies it offline, byte for byte, and writes recorded events for the cloud commands. docs/LAMBDA_EXAMPLE.md: offline as a project, offline as a deployment package, live on a sandbox copy. Before this the 0.4.x cloud commands shipped without anything to try them on.
  • paretostack cloud lambda-optimize --zip PACKAGE --events FILE [--handler module.function]: the same optimization as on a deployed function, on a local deployment package, offline: the optimized code is verified against the original on the recorded events on this machine (identical answers; the timing is indicative), nothing is sent anywhere; original.zip, optimized.zip, changes.diff, report.json in --out. The tour's step 16b runs it on the example.
  • The assistant is documented: a new "Assistant (pareto)" page in the documentation (how to start it, that it needs no AI model and no API key, the models and keys, exactly what a cloud model is sent, every command).
  • The Windows installer's Getting started file has a section on pareto (no AI model and no API key needed; a local model, Claude or OpenAI only if you pick one, and then only a short summary, never your code).

Fixed (from the 0.3.10 DGX package installed from hpc-labs.ai as a customer would, and the full example tour, 2026-10-25)

  • update.sh (Linux, DGX) also refreshes what install.sh put under ~/ParetoStack: the example script and the profile are replaced by the package's, sample projects the install lacks are added (existing ones are never overwritten). Before, a customer who updated kept the old tour script and never saw the new steps (16 Lambda, 17 Google Cloud Functions) or the new samples unless they ran example.sh from the package folder. Windows keeps its samples in the package folder, so update.cmd needs nothing.
  • The EC2 probe suggests the current Graviton generations (c8g, m8g or m9g, r8g; t4g for burstable) instead of the 7g families. m9g is Graviton5 (generally available June 2026, some regions only).
  • Windows install.ps1 picks the Python a compiled package needs. With several Pythons installed it took the newest (for example 3.14) and failed with "not a supported wheel"; it now looks for the version in the wheel's name (3.12 for cp312) first, says so clearly if that Python is missing, and starts an earlier environment on another Python again. When only python was found (no py launcher) it crashed on $py[0] (the first letter of the word). Found by running the 0.4.1 zip on a Windows 11 PC with Python 3.11 to 3.14.
  • The license refusal now also names the whitelisted download (curl -fsSL https://hpc-labs.ai/api/license -o license.json), not only the account page.
  • example.sh labels its log after the package's PROFILE file (example-dgx-*.log), which install.sh now copies next to the installed script; before, the label came from the folder name, which is dgx only inside dist/, so a customer's DGX log said linux.
  • install.sh keeps a paretostack-console.service it did not write (ExecStart not the private environment: a source checkout, another python) and says so; --console-overwrite replaces it. update.sh says whether systemctl --user restart paretostack-console will pick the update up or that a hand-written unit is not affected.
  • update.sh found no wheel in a DGX package folder (paretostack-dgx-*, the pattern was paretostack-linux-*) and, with pipefail, ended silently with status 2 when a pattern matched nothing.
  • paretostack doctor has a JDK (javac, java) row (the Java front-end and the java_box_sums example, which the example scripts skipped without a word about where a JDK comes from; the scripts now point to doctor) and a zig (ziglang) row (cloud lambda-optimize --port). Both optional, each with the install command for the system's package manager; --everything still does not pull a JDK onto every machine.
  • The DGX install adds CuPy to the private environment (the wheel of the CUDA toolkit found: cupy-cuda12x / cupy-cuda13x; --no-gpu skips it), so the GPU offload optimizers and the doctor row work out of the box; doctor's hint names the matching wheel instead of always cupy-cuda13x.

ParetoStack 0.4.0 (2026-10-25)

The first release of the 0.4.x line: everything in 0.3.x plus cloud optimization (engine version V11). 0.4.x is a separate version line from 0.3.x.

Added

  • V11, a real engine version (settings 1 to 11, the default is now V11, the console picker and roadmap card, the chat assistant): a project that holds an AWS Lambda function gets two plan items, right-sizing and code optimization, with the exact commands; they are advice (nothing runs in the console) and need V11.
  • paretostack cloud (the commands that create resources or change code are licensed; check and probe are free):
  • check [aws|azure|gcp]: is the cloud command line tool installed and logged in, as whom (read-only).
  • probe: reads a host (this machine, --ssh, an EC2 --instance through AWS Systems Manager, an Azure VM --azure-vm through Run Command, a Compute Engine --gcp-instance through gcloud compute ssh, optionally --iap): processor, instance type from the cloud's metadata service, how Python, NumPy, OpenCV and the JVM were built, and what is likely slow or costly (for example an x86 type with an Arm equivalent). Every finding is labelled likely, not measured, with the measurement that would confirm it.
  • lambda-tune: the cheapest memory size and processor architecture of an existing AWS Lambda function that gives identical answers, measured in throwaway copies on your recorded events.
  • lambda-optimize [--port]: optimizes the function's own Python code (dependencies are left alone) and verifies it against the original in throwaway copies; --port translates pure-numeric functions to C, built for the function's architecture.
  • gcf-tune: the same idea for Google Cloud (2nd generation, HTTP, Python) functions: memory and CPU, with server-side latency from Cloud Logging, against the current setting.
  • Safety: plans by default; running needs --sandbox (your own test account or project) and stays under a cost ceiling; every copy is deleted afterwards; the live function is never changed. Run live on AWS Lambda, EC2 over SSM and Google Cloud (Compute Engine, Cloud Functions); the Azure VM probe has only run against a test double.

Changed

  • The default engine version is V11 (it was V10).

Not yet

  • Azure Functions, a Google Cloud code optimizer and C port, event-triggered and 1st-generation functions, and the 0.4.x purchase on the website.

ParetoStack 0.3.13 (2026-10-29)

  • Update notice (ported from the 0.5 line, 217c497): paretostack update and /update in the assistant say whether a newer version of the SAME product line exists (0.3.x is never pointed at 0.4), from the public https://hpc-labs.ai/releases.json read at most once a day with a 2 s timeout, cached under ~/.cache/paretostack/, silent on any failure; nothing about you, your machine or your code is sent (a plain GET). After an interactive command the notice goes to stderr; the assistant shows it under its banner when interactive. Off with PARETOSTACK_NO_UPDATE_CHECK=1 or PARETOSTACK_OFFLINE=1. paretostack/updates.py, tests/test_updates.py.

ParetoStack 0.3.12 (2026-10-28)

  • Two text rules, bit-exact, on by default, in the search and optimize (docs/TEXT_RULES.md): py:str_build (L1): a string grown piece by piece in a loop through a reference CPython cannot update in place (self.out += line, d["k"] += s, a global or nonlocal) is quadratic, every += copying the whole string; the pieces are collected and joined once after the loop, in a finally so an exception leaves the partial string as before. The string is not read and its holder is not called in the loop (other fields of the holder are fine); at run time anything that is not a str flushes the pieces and runs the original += at the same statement; a plain local is left alone (CPython grows it in place, measured as fast as a join). py:re_hoist (L1): re.match(PATTERN, s) and search, fullmatch, sub, subn, findall, finditer, split, compile with a constant pattern and flags, inside a function, use a pattern compiled once at module level (the module-level functions look the pattern up in re's cache on every call, which costs as much as a short match); the compile is wrapped so an invalid pattern still raises at the original call. The text rules run before the attribute-binding rules and every reported line is the customer's own.
  • Sample log_report (in the wheel; tour step 16): an access-log report parsed with re.match / re.sub in a loop and grown on an attribute: 6.7 s -> 0.23 s on the GB10 (29x), report and summary byte for byte identical.

ParetoStack 0.3.11 (2026-10-27)

  • Offline mode for the assistant: /offline on (and paretostack models offline on|off|status, kept in the per-user config) checks the local runtime and model, looks for a newer model or runtime when the network is reachable, offers the (re)download (asks, skippable), then turns the cloud backends off for the session; /offline off restores.
  • The assistant (pareto) looks and reads like Claude Code: a welcome box in the brand colours (logo, product line, version, machine, project, model, tips), a coloured prompt, Tab completion of the slash commands and sample names, /help grouped by product. New commands: /cloud, /hw, /pcb (each says so when its product line is not in this build), /doctor, /models, /keys, /status, /version; /pick and /cost say so too on the 0.3 line (the sample picker and the AI usage ledger are 0.4.3 features). The catalogue and colours are in paretostack/branding.py.
  • Fix: an install no longer replaces a sample file the customer already has under ~/ParetoStack/sample (an edited sample survived only the Windows .exe installer): new samples and new files are added, edited files are kept and listed (copy_samples in lib-ensure.sh; the Windows share installer does the same).

ParetoStack 0.3.10 (2026-10-24)

Fixes the Windows installer. The engine is the same as 0.3.9.

Fixed

  • Windows installer: a program that imports a module sitting next to it (import helper beside main.py) failed under the Python the installer brings, because its path file switches off the "folder of the script first" import path. The installer now puts that behaviour back (the isolation from other Pythons on the PC stays). Found by running the installer on a real Windows 11 PC, where a full paretostack run of a sample also passed (verified, identical output, 21.78x faster).

ParetoStack 0.3.9 (2026-10-24)

The Windows installer, and the console explaining itself. The engine is the same as 0.3.8.

Added

  • Windows installer: paretostack-setup-0.3.9-amd64.exe and -arm64.exe (one per processor). Double-click it: it installs for the current user (no administrator rights, no internet) with its own Python 3.12, puts the paretostack and pareto commands on the PATH, adds a Start-menu console, copies the sample projects and registers an uninstaller that keeps your license file. The zip packages stay available.
  • Console: a legend explaining the optimization levels (L0, L1, LIB, L2, L3, L4) and a hover text on every level badge; the samples chart names each sample's language and says what each speed-up is measured against (the C++ samples are compiled with g++ -O2 on both sides); a recorded run of the two C++ samples against g++ -O3 -march=native.

Changed

  • The Windows README names the per-processor zips and the installer.

ParetoStack 0.3.8 (2026-10-23)

The first protected release: the optimizer core ships compiled, not as readable Python. Behaviour is the same as 0.3.7.

Changed

  • Protected packages: the optimizer, verifier and search modules (68, listed in packaging/protected_modules.txt) are compiled with Cython per platform; the Linux, DGX and Windows packages carry no readable source for them: Linux and DGX for aarch64 and x86_64, Windows for x64 (amd64) and ARM64. The command line, the sample projects, the console plumbing, doctor and keys stay readable. See docs/PROTECTED_BUILDS.md.
  • Windows packages: paretostack-windows-0.3.8-amd64.zip and -arm64.zip (Python 3.12). Built from Linux with zig against the Windows Python headers; every compiled module was checked as a valid Windows DLL. The installers pick the package for the PC's processor.
  • License check cannot be switched off by editing a file: a release build compiles the "license required" flag into the protected license.py, and a missing key file now means "no license is valid" rather than "none needed".
  • Fixed: the library catalog (catalog.yaml) was missing from the 0.3.7 wheel.

ParetoStack 0.3.7 (2026-10-23)

The first release you buy: signed packages, a license file, optional AI keys, and the analysis-only console for the hosted portal.

Added

  • AI keys, optional: paretostack keys (status, setup, set PROVIDER, remove PROVIDER, test [PROVIDER]) keeps an Anthropic or OpenAI key in a private per-user file (or reads ANTHROPIC_API_KEY / OPENAI_API_KEY); a key is never printed back (only its last four characters) and keys test only lists the provider's models (no prompt, no project data). The installers (install.cmd / install.ps1, install.sh) offer the step once, interactively, skipped by -NoKeys / --no-keys and never in a -Yes / --yes or non-interactive install; each package also carries provision-keys.cmd / provision-keys.sh to add a key later.
  • Signed releases: make_dist.sh --release signs the release's SHA256SUMS with an AWS KMS key (ECDSA P-256, alias/paretostack-release-signing; the private key cannot leave KMS) and writes SHA256SUMS.sig, the public key and its fingerprint beside the packages (--no-sign skips it; packaging/sign_release.py creates the key, signs and verifies). paretostack check-download PACKAGE checks a download with the key that ships inside the package, using a dependency-free ECDSA verifier, and customers without the CLI can use plain openssl or the verify-download.sh / .ps1 scripts published on the website. The publisher refuses a release whose signature is not valid for the trusted key. 0.3.6 was signed after it was built (the signature files were added beside the immutable release); packages built from now on carry release_key.pem.
  • License file: a release package asks for a license before the commands that change code (optimize, run, search, tune, scout, apply, dynamic, reverify, ci, chat, serve without --analysis-only). The license is a license.json issued on the buyer's account page at hpc-labs.ai, signed with a dedicated KMS key (separate from the release-signing key), naming the buyer's license id and the version line they bought (a purchase covers every 0.3.x release; a later line is a separate purchase). paretostack license shows the status and paretostack license install FILE checks it offline and keeps it. Analysis, the examples, doctor, keys and check-download need no license, and a source checkout is never gated.
  • anthropic backend: Claude through the Anthropic API with that key, with no Claude Code needed (--ai anthropic, /model anthropic); --ai all asks Claude once (the Claude Code CLI when installed, else the API key) plus OpenAI and the local model.
  • serve --analysis-only: the console can be started so that nobody can run code or write to a project, even a trusted private-network peer; uploads are only analysed. It is what the hosted portal at hpc-labs.ai runs (loopback is never privileged).
  • Without any AI (no key, no local model, no Claude Code) only the AI-assisted features are limited: AI review of the optimizations, the AI-suggested search order, and free-form requests and /explain in pareto. Each says so and how to add a key; every deterministic optimizer, the verifier, the search and the report work the same. paretostack doctor, paretostack keys and the pareto banner show the state.

ParetoStack 0.3.6 (2026-10-23)

Added

  • gpu_dot (V10, LIB level, opt-in like gpu_matmul, accuracy contract): existing a @ b, np.dot(a, b) and np.matmul(a, b) call sites run on the GPU through CuPy (shared-GPU lock) when both operands are 2-D float32 / float64 arrays of one dtype and the product is big enough to pay for the copies; every other case, and any machine without CuPy, a GPU or the lock, calls the original function unchanged. Offered only where an NVIDIA GPU exists. Verified with a fake CuPy (unit tests) and on the real GPU (see Measured).

ParetoStack 0.3.5 (2026-10-22)

No change to the engine, the examples or the console: this release is about knowing what changed.

Added

  • CHANGELOG.md (this file) ships in every release folder, with a table of the examples release by release; a release now refuses to build without a ## <version> entry here.
  • BENCHMARKS.md in every release folder: each example of that version run on the build machine, one at a time, with its verdict and speed-up (about 30 minutes; make_dist.sh --release --no-bench skips it). The raw results are kept in docs/benchmarks/<version>.json and docs/BENCHMARKS_BY_VERSION.md compares all versions (0.1.0 to 0.3.5).
  • packaging/release_bench.py (run for one version, compare across versions).

ParetoStack 0.3.4 (2026-10-22)

Added

  • Console step 4-C offers the recipe suggested for the project as a box at the top ("Recipe to select for this project") with Use and save this recipe (one click; saving is the approval and the text says what it allows), Reload this suggested recipe (replaces the saved one) and Only fill the form.
  • The "Say how to run the code first" dialog offers Use and save the suggested recipe instead of only pointing at 4-C.

Changed

  • The recipe API returns the suggestion even when a recipe is already saved.
  • The stale "tick the approval box" wording is gone (that box was removed earlier; pressing Save is the approval).

Fixed

  • The CI gate test no longer fails when a 50 ms program looks 5 % slower on a busy machine (its "ok" step allows 300 %; the regression step still uses a 12x slowdown).

ParetoStack 0.3.3 (2026-10-22)

Changed

  • V10 is the default engine version (was V7). A setting saved for a project still wins; V7 stays selectable. CLI help, paretostack init, the chat assistant and the console label follow.

Added

  • Example s3_ocr_rescan: a made-up cloud-style job (a fake S3 bucket on disk behind boto3-style calls, a textbook OCR; no network, no credentials, no customer data); 20 examples now. docs/S3_OCR_EXAMPLE.md lists the step 4-C fields and what to change for a real S3 job (never a production bucket).

ParetoStack 0.3.2 (2026-10-22)

Changed

  • The console lists V8 and V10 as implemented (V1-V10).
  • The speed-up plot in the example scripts names the machine it was measured on (CPU model, architecture, cores).

ParetoStack 0.3.1 (2026-10-22)

Added

  • Safe parallelism: the plan scan and the staging of the refactored copy use a worker pool (PARETOSTACK_JOBS, paretostack config --set jobs=N); the result does not depend on the number of workers, and a pool that cannot start falls back to one process. Timing runs and the search stay sequential.
  • CPU lanes: --cpus LIST / PARETOSTACK_CPUS pin a run and its children to cores (Linux and Windows); example.sh --parallel N and example.cmd all --parallel N run the single-core examples N at a time, one core each, labelled [in a lane].
  • Examples cpp_matmul, cpp_loops (C++) and java_box_sums (Java), with a compiled group in the example scripts.

Changed

  • C / C++ / Java sites count as hot when the profiled Python wrapper only waits for the compiled program it starts (they were dropped as "not hot" and the run was blocked).
  • The installers no longer print pip's "new release of pip" notice.

Fixed

  • example.sh rejected contracts, vector, parallel, assert, fixed, fft and box (shipped in 0.3.0; the Windows script was fine).

ParetoStack 0.3.0 (2026-10-22)

Added

  • V10: GPU offload (gpu_matmul): a matrix-multiply loop nest becomes a CuPy product when it is big enough, under the shared-GPU lock, with a CPU (BLAS) fallback.
  • V10: OpenCV rules: cv_hoist (36 factory functions built once), cv_cse (repeated pure calls done once: 70 functions), cv_loops (27 functions: hand-written pixel loops become cv2 calls, bit-exact) and cv_approx (grey conversion, blending; accuracy contract). paretostack opencv-rules lists the 109-function catalog; docs/OPENCV_RULES.md.
  • Examples: a core set of 10 that need only Python and NumPy (6 byte-identical, 4 judged by an accuracy contract), plus OpenCV 5 and C-port examples (opencv_pixels, opencv_cse, opencv_metrics, opencv_color, image_fixed_point, fft_convolution, box_sums).
  • Example scripts show the exact paretostack command of every step, print a summary that tags each example bit-exact or contract, and print a summary when interrupted with Ctrl+C.
  • The Windows installer offers a portable C compiler (llvm-mingw, pinned and checksummed; -NoCompiler to decline).
  • Releases live in dist/<version>/ (immutable, tagged, with checksums and release notes); development builds go to <version>-dev.

Changed

  • The profile keeps hot callers, so cv_hoist is selected by default; the FFT rewrite falls back to NumPy when SciPy is missing; the image contract reads .npy.

ParetoStack 0.2.0 (2026-10-21)

Added

  • Windows support end to end: installer (install.cmd, -Everything / -WithModels for the prerequisites), update.cmd, example scripts, a ready-to-run sample project; confirmed on a real Windows machine. A text shim runs python.exe -m paretostack (no unsigned launcher program, to avoid antivirus prompts); UTF-8 end to end.
  • Distribution per system (dist/windows, dist/linux, dist/dgx, dist/macos placeholder) with example scripts that write one log and a findings summary, a CLI spinner with an ETA, a per-user config file with a default target.
  • paretostack arch and --target: processor detection and named targets (x86_64-v3, aarch64, ...); a target this machine cannot run is refused.
  • pareto, a chat-style interface with slash commands, text plots, settings advice, plain requests ("optimize word_filter") that become steps after one confirmation, and /explain.
  • Search pause / resume (and the console servers as systemd user units that pause running searches when stopped); "Run all versions" resumes after a reload or reboot.
  • V9: accuracy budget (--min-accuracy) and Amdahl-bounded search (a candidate that cannot gain 2 % is skipped, the biggest best case first); L4 port of pure-numeric Python functions to C (guarded, bit-identical when it applies; loops, helper calls, list building); set_member (list membership to a frozenset, exact); paretostack ci, a performance gate with a committed baseline, a report and a GitHub workflow.
  • V8: build search for recipes that run the library's own tests (OpenCV's test suite); lib_matmul library swap.

Changed

  • The search tries an L2 layout transform before the L1 loop work in the same function; the version plot shows the per-version ceiling from the measured profile (the uncalibrated static estimate had 0 of 14 past results inside its range).
  • --no-build-sandbox / --build-network for big library builds.

Fixed

  • Windows: ingest path check, disk check, timing without wait4, WMI hang in the platform module, a stale install that was never updated (wheel lookup in ensure-current.ps1), quote stripping in PowerShell 5.1.

ParetoStack 0.1.0 (2026-10-20)

Added

  • The first packaged release: the local command line tool (Linux x86_64 and aarch64): pipeline, doctor, init, dynamic, plan, run, run-all-versions, report, apply, models; pyproject.toml and install.sh; three test projects that need no computer-vision library. Nothing leaves the machine unless a model is turned on.