The web console and the online dashboard

ParetoStack has a web page that walks through the same work as the command line: choose a project, analyze it, see the plan and, on your own machine, verify and measure the changes. It comes in two forms, the local console on your machine and the online dashboard that HPC Labs hosts at https://portal.hpc-labs.ai.

	Online dashboard	Local console
Where	portal.hpc-labs.ai, in your browser	`paretostack serve`, then http://127.0.0.1:8190
Who	everyone with a purchase (any version line): sign up with your e-mail, confirm it with the link we send, sign in	anyone with the tool
What it does	analyzes and plans. Your code is analysed and never built or run, so nothing is validated there and there is no optimized code base to download	the whole workflow: it also runs your program on your machine to measure it, builds a changed copy, verifies it against the original and exports a patch
Engine version	one version, shown in the page (you do not choose)	you choose it (V1 to V11)
Your code	stored in your own private account folder until you remove it	stays on your machine

To optimize, verify and export a change, use the command line tool (or the local console) on the machine you are targeting. The dashboard shows the exact commands.

The steps

The page shows your route as numbered steps and what is done in each.

Choose. Pick a project, drop a .zip, a set of files or a folder onto the page, or pick a compute library. Nothing you drop is ever executed.
Analyze. A static analysis of the code: where the time probably goes (hotspots) and the ranked recommendations, each with the level of the change, the expected gain, the risk and the places in the code. If there is nothing to recommend, the page says what was checked and what else can be done (profile the real workload, build and runtime settings, hardware or libraries), instead of an empty list. 2b. Dynamic analysis (local console, optional). Runs the project's own command as it is and measures time, CPU, memory and where the time goes.
AI review (optional). A model reviews the code and the static findings. It is off until you add your own key, and nothing is sent without it.
Implement (local console). The plan lists the optimizations that apply to this code; you tick what you want, the tool backs up your files, builds a changed copy, and verifies it. On the dashboard this step is the read-only Optimization plan.
Result (local console). Input, process before and after, and output, with the measured speed-up and, from V4, the accuracy trade-off.
Deploy (local console). Apply the verified change to your project, or export a patch, after a re-check of the live code.

See what changed, before and after

Nothing in your project changes until you say so, and you can always look at the change first. This is the same for one of the samples and for your own code base.

As a patch. paretostack run PROJECT --yes ends with the change saved as a patch. paretostack apply PROJECT --patch change.patch writes it as a unified diff that any editor or review tool can open; cd PROJECT && git apply change.patch applies it when you are happy with it.
As a whole folder. paretostack apply PROJECT --export DIR copies the refactored tree into a new folder, so you can compare it with your project in any diff tool (diff -ru PROJECT DIR, VS Code, Beyond Compare).
In place. paretostack apply PROJECT --in-place copies the changed files over the project, keeps a backup, and commits nothing.
In the assistant. /patch shows the first lines of the change and writes the patch file.
In the local console. Step 4 offers "Download the patch" and a Compare button that opens the staged copy against the original in a diff tool (Beyond Compare on the machine running the console, or a script for it); "Compare the two selected" shows the difference between two change sets as a diff in the page.
The samples. paretostack examples copy NAME DIR copies a sample into a folder you can run and diff exactly like your own project.
On the online dashboard there is no changed code to look at: it analyses and plans, and shows what would change and where. Use the tool on your own machine to see the code.

Words used

Contract. The rule a changed program's output must meet before its speed-up counts. The default is identical output, byte for byte. Where small differences are expected (rounding, fixed-point arithmetic, an FFT), the contract is a tolerance you declare: a numeric error, PSNR or SSIM for images, or a task metric (from V4, the "Accuracy contract" card). A change that does not meet its contract is rejected, whatever its speed.
Verified. The changed program was run next to the original and its output met the contract; only then is its timing believed.
Speed-up. The original's time divided by the changed program's time, both measured on the same machine, alternating runs.

What the levels mean

Every recommendation carries a level badge. Hover over it, or open "What do L0, L1, LIB, L2, L3 and L4 mean?" above the recommendations.

Level	Meaning
L0	Build and runtime settings: compiler flags, link-time and profile-guided optimization, interpreter or JVM settings. Your source does not change.
L1	Changes inside a function: bound lookups, inlining tiny functions, a set instead of a list for membership tests, simple vectorization. The output stays identical (checked).
LIB	A hand-written routine replaced by a tuned library call (BLAS, OpenCV, FFT). Usually the same result; floating-point sums may be added in a different order.
L2	Data layout and memory: loop interchange and tiling for the cache, array-of-structs to struct-of-arrays. Same results when the order of arithmetic is kept.
L3	A different algorithm for the same job (FFT convolution, separable filters, integral images, fixed-point arithmetic). The numbers can change slightly, so it needs an accuracy contract you accept.
L4	A pure-numeric function rewritten in C behind a guard; the Python function stays as the fallback.

The cards

Machine capabilities. On the local console, your machine: processor, instruction sets, compilers, libraries. On the dashboard it names the cloud service that runs the analysis (for example a managed container with its vCPU and memory), never a private machine.
Test samples. Twenty small programs with a known answer. Open any of them as your own project (it is copied into your list and analysed) and see a bar chart of the measured speed-up of every sample for any recorded run: a release, the machine it ran on, and the engine version. Each bar says whether the sample is Python, C++, Java or a Python program with a C port; a footnote says what the speed-up is measured against (for the C++ samples, the same compiler flags on both sides, so the gain comes from the source change). One run each: an indication, not a measurement with error bars.
AI review (optional): add your own key. On the dashboard you can add, test and remove your own Anthropic or OpenAI key. It is stored in your account folder, shown only as its last four characters, used only when you run an AI review, and deleted when you remove it. Without a key, the AI options are not shown at all.
Accuracy contract (from V4). The tolerance a changed program's output must stay within: byte for byte, a numeric tolerance, PSNR or SSIM, or a task metric.
Targets and porting (local console, from V7). Where else the code could run, and what a static scan says would stop it from building or running there.

The online dashboard in detail

Sign up and sign in. Anyone can create an account with an e-mail address and a password; the e-mail is confirmed with a link first. Only an account with a purchase gets in; a refunded purchase closes the door on the next request. Five wrong passwords lock the address for 15 minutes. "Forgot password" sends a one-time link.
Your folder. What you upload, or a sample you open, is kept in your own private account folder (encrypted storage, backed up, not visible to any other account) until you remove it with "Reset project" or ask us to delete it. Each account has a storage limit (2 GB). We do not look at it.
Fair use. A small number of consoles run at once. When all are busy you get "busy, try again in a minute"; a console that nobody has used for about 15 minutes is stopped (your files stay) and starts again on your next visit.
What it never does. It does not build, run, install or deploy anything, and it has no compiler or model of its own. The page says so at the top.
To optimize for a given target, on the machine you are targeting:

paretostack license install license.json            # once, from your account page
paretostack run PROJECT --target native             # this machine (Linux, DGX, Windows)
paretostack run PROJECT --target x86_64-v3          # Intel / AMD with AVX2
paretostack run PROJECT --target aarch64            # Arm
paretostack arch --list                             # every target name
paretostack apply PROJECT --export optimized        # the verified code, in a new folder

A target the machine cannot execute is refused: run the tool on that hardware.

The local console

paretostack serve                         # http://127.0.0.1:8190, only this machine
paretostack serve --port 8200             # another port
paretostack serve --analysis-only         # nobody can run code or write to a project (what the dashboard uses)

By default it listens only on this machine. To use it from another computer on your network, give it --host, add --allow-host NAME for a DNS name, and protect it with an access code first: paretostack set-code, then paretostack serve --require-login. In a release package serve is a licensed command like run; serve --analysis-only needs no license.