Running Your Agent on Your Own Machine Instead of the Cloud
How local mode connects the Piskes desktop app to an engine running on your own hardware, and what actually changes when you flip that switch.
Most "AI agent" products only offer one place for the model to run: somewhere in their cloud, on hardware you'll never see. Piskes's desktop app offers a second option — an engine that runs on your own machine, with a plain toggle in Settings that switches your chat between the two.
What local mode actually is
Inside the Piskes desktop app, under Settings, there's a "Local mode" section. It only appears there — a browser tab pointed at agents.piskes.com has no engine to connect to, and rather than show a connect form that can't work, that section simply says so. The desktop shell is a prerequisite, not a formality: local mode needs a process running on your machine that a browser tab cannot start on its own.
Getting set up has two separate steps, and they're kept separate on purpose. First, you download the engine itself — a roughly 5GB package, checksum-verified before it's treated as installed, kept apart from the main Piskes installer so that installer stays small for everyone who doesn't want local mode at all. Second, once the engine is on disk, you connect it: you mint a pgw_ gateway API key yourself, by hand, from gateway-portal's self-serve page, and paste it into the Connect screen. That key is what lets your local engine talk to the rest of the platform under your own identity, the same way a cloud request would.
Minting the key by hand, rather than having the app do it automatically for you, is a deliberate current limitation, not an oversight — the platform's existing self-serve mint endpoint doesn't accept the kind of token the desktop app's own sign-in flow produces, so automatic minting is a separate piece of work for later. Today, it's one manual step.
Why this matters more than it might sound like
The 2026 conversation around local versus cloud AI agents tends to circle three things: data never leaving the machine it started on, marginal cost that approaches zero once the engine is downloaded, and a hybrid pattern where a cloud model handles planning while local execution handles anything sensitive. Piskes's local mode is a real, working instance of that pattern rather than a roadmap slide.
Data locality. When your chat is on the local engine, the model running your conversation is executing on your own hardware. That's a meaningfully different trust boundary than any cloud-hosted model, and it's the reason this feature exists at all — for work where you'd rather not send content to a hosted endpoint, even one you otherwise trust.
Cost. Once the engine is downloaded, running it costs whatever your own electricity and hardware wear cost — not a per-token bill. For heavy, repetitive local work, that's a real difference over time, though it comes with the obvious tradeoff that your machine's compute is now doing the work a data center used to do.
A toggle, not a fork. The important design decision here is that local mode isn't a separate app or a separate agent — it's a backend switch on the same chat interface you already use. You flip between "local engine" and "cloud" in the same settings panel, and the rest of the ai-agent experience — tools, memory, scheduling — sits on top of whichever backend is active.
What to actually expect
Setting expectations correctly matters more than enthusiasm here. Local mode is gated behind the desktop app specifically, so if you're working from a browser, it isn't available to you — that's not a bug to report, it's the architecture. The 5GB download is real disk space and real bandwidth, and it happens once, not per session. And the API key step means local mode isn't zero-configuration — you're deliberately in the loop for the one step that establishes your engine's identity to the rest of the platform, rather than that identity being minted silently on your behalf.
None of that is a complaint about the feature. It's the shape of a product that chose to be honest about what's automatic and what isn't, rather than papering over a step that currently has a real technical constraint behind it (that mismatched token format between the desktop sign-in flow and the mint endpoint). If and when that gets resolved, minting will likely get folded into the Connect flow itself. Until then, the manual key is the cost of running your agent somewhere the cloud doesn't reach.
Who this is actually for
If your work never touches anything you'd hesitate to send to a hosted model, cloud mode is simpler and you probably shouldn't bother. Local mode earns its setup cost for people who are already running Piskes on the desktop app, who have a machine capable of running a real model locally, and who have at least one recurring category of work — client-sensitive drafts, internal documents, anything under an NDA — where "the data never left my machine" is worth the one-time download and the one manual key.