“Local-first” can mean almost anything in software marketing. In Upfyn it should describe a specific boundary: the desktop application is the main engine for project files, local tools and machine actions.
That boundary remains true whether you are sitting at the computer or reaching it through a paired browser. It also remains true when a cloud model handles a reasoning turn. The important question is not whether the product ever uses a network. The question is which parts run where, and what you have authorized each part to receive.
Files and tools stay anchored to the desktop
When Upfyn reads a project file, edits a document, runs a terminal command or drives an installed browser, that operation belongs to the desktop environment. The project is not automatically copied into a hosted development machine.
Analyst and Developer expose different portions of that environment. Analyst can read the active project and confines its own writes to output. Developer can work across the full project and use terminal, browser, Git and review tools according to the active permissions.
The distinction is useful because local-first is not the same as unrestricted. The machine contains the work, while the mode and tool policy define what the assistant may do with it.
A cloud model still receives context
If you select a cloud model, the model provider must receive the prompt and the context required to answer. That context can include relevant portions of files, tool results or conversation history. Saying “nothing ever leaves the computer” would be false for that route.
Upfyn’s responsibility is to keep file and tool execution local, assemble only the context required for the turn and send it to the provider you selected through the configured path. Provider terms and retention policies still matter.
Bring-your-own-key credentials are stored locally and used with the provider you choose. UpfynAI routes the turn through the gateway and uses the account’s credit balance. Supported CLI subscriptions use their own authenticated route.
A local model changes the reasoning path
With a compatible local model served through Ollama or LM Studio, the model turn can remain on the computer too. This is the path for work that must avoid a cloud inference request or for times when an internet connection is unavailable.
Local does not automatically mean capable enough for every job. Model size, available memory, context limits and tool-use quality affect the result. Choose a local model because its privacy and availability fit the task, then test whether its reasoning is sufficient.
Offline operation also has boundaries. Cloud connectors, account services, updates and remote access still require a network. A local model can reason without the internet; it cannot fetch an inbox from a cloud service while disconnected.
Focused apps follow the same principle
Artifact autosaves documents inside the active project and can use bundled on-device OCR for scanned PDFs. Design keeps its projects with the workspace. AI Studio uses a project-local media library and timeline for imported image, video and audio files.
Share transfers selected files directly between devices on the same local network. That avoids cloud storage, but it does not make an untrusted network safe. Discovery should be enabled deliberately, browse and incoming-file requests should be approved, and the transfer history should remain visible.
Operator creates a remote-assistance session with explicit host and client approval. Screen and input access are grants for that session, not a permanent background authority. AI-authored operator actions require host consent when the optional AI operator is enabled.
The relay is transport, not execution
Remote access needs a way for a browser or phone to find the paired desktop across networks. The relay carries the session between devices. It should not become a hidden worker that stores a second copy of the project or continues local tasks after the desktop disappears.
This architecture has an honest consequence: keep the desktop running, connected and opted into remote access. If the engine is unavailable, the remote window cannot use its local files and tools.
Known devices and sessions should be visible in the account dashboard, where the user can revoke them. Identity is shared across the website, gateway and desktop so access can be managed as one account rather than a collection of unrelated logins.
Scheduling is coordinated, then executed locally
Hosted Temporal schedules make recurring job state durable. When the job needs a local folder, application or browser session, the desktop performs it. Temporal does not turn the task into cloud execution.
This is why the product should say “the schedule is durable” rather than “the automation always runs.” A powered-off or disconnected machine cannot perform local work. The run should expose that condition instead of producing a plausible but incomplete result.
Questions to ask before sensitive work
For any task, identify four paths:
- Where are the source files?
- Which model receives the reasoning context?
- Which local or connected tools will act?
- Where will the result be stored or sent?
Then set the narrowest useful permissions. Use Analyst for read-heavy work with an output boundary. Keep external sends, submissions and destructive actions behind approval. Use a local model when the reasoning context must remain on the machine and its capability is sufficient.
Local-first should make these choices clearer, not hide them behind a green shield icon.
Ask Upfyn
Map the data path for this task. Identify what stays on the desktop, what context the selected model receives, which services require a network, where results are stored, and every action that needs my approval.