Why loqy starts local and how cloud can complement it

A finance director is preparing a note for the executive committee. Two internal forecasts disagree. She wants to compare their assumptions, research public signals that might challenge them, and deliver a recommendation whose conclusions can be checked.

The work combines three needs. The files are confidential. The research requires the internet. Some steps may need a model more capable than one that fits on her Mac. Should everything stay local, should everything move to the cloud, or should the problem be divided more carefully?

loqy's answer is a rule: local is the complete starting point, cloud is an explicit complement, and the user chooses according to their needs.

Work begins under the user's authority. When a step needs an external capability, loqy identifies the model or service involved and the data it needs. Local sets the starting point, and the user decides when an external capability is worth the data exchange it requires.

In brief

A complete local foundation with explicit cloud capabilities

The term local-first comes from a wider approach to software that prioritises user-owned data, offline operation, and the longevity of work. Ink & Switch set out its principles for software that can collaborate without making a central server the implicit owner of the data.

An AI agent does more than open a document. It assembles context, asks a model, calls tools, creates files, and may propose an action in the outside world. Its authority depends on all of these paths.

Four questions describe that authority:

1. where the reference work is kept;
2. where the agent engine runs;
3. where the model generates its response;
4. which data and permissions cross each boundary.

In loqy V1, the agent engine is local. The Core, the application's control core, retains authority over work state, permissions, tools, and effects. The model can be local or hosted. These are separate choices: changing the model does not move the agent engine. The V1 execution map follows that separation component by component.

A complete application therefore does not require an account or remote infrastructure. External resources remain available when they add useful capacity and the user accepts the boundary.

Local-first provides an autonomous starting point. Isolation and protection come from concrete controls, while external capabilities remain visible.

What local changes in practice

For the finance director, starting locally has immediate effects.

Documents remain close to their source. She can open the forecasts, compare them, and prepare a first structure without transmitting them to a model provider. The work remains available offline until it needs an external resource.

Repeated operations do not create a per-token bill. Once the Mac and model are available, reading a table again, rewriting a paragraph, or extracting another series of figures consumes energy and machine time, but it does not trigger usage pricing for every generation.

Latency does not depend on a network round trip. For short extraction, classification, or structured transformation, a suitable local model can respond immediately. The benefit depends on hardware, model, and task.

A remote outage does not remove the working foundation. The local engine, history, and offline tools do not disappear when an API is unavailable. Web research or a hosted model may become temporarily unreachable, but the conversation and work already produced remain on the Mac.

That control has limits. Unified memory restricts the models that can run. A novel analysis or very long context may benefit from a more capable hosted model. Sustained generation can use the GPU, reduce battery life, and slow other applications. The real cost of local and hosted inference therefore depends on the work, hardware, and success rate.

Choose the model while the application stays local

Engine and model have different responsibilities.

The local engine organises execution. It maintains the thread of work, prepares context, checks permissions, assigns tools, and records results. It decides whether a model proposal matches a capability that was actually granted.

The model produces a response from the context it receives. It can run on the Mac or at a hosted provider. The Core treats that response as a proposal. A request such as “send this email” still crosses the exact capability that authorises the send.

The finance director can therefore use a local model to extract assumptions from two files, then select a hosted model to challenge several scenarios. The conversation, sources, rules, and deliverable do not change owner between those generations.

The model assigned to a run does not change midway. If it fails, loqy does not silently redirect context to another provider. The user can still know who received what.

“Cloud” covers three boundaries

The word cloud covers three distinct operations, each with different data and authority.

1. Asking a hosted model

The engine remains local. loqy sends the selected provider the request and context required for a generation, then receives the model response. Credentials, file access, and authority over tools stay behind Core capabilities.

The first boundary concerns inference: where does the model compute its response?

2. Calling an external service

Web search, a connector, or an API receives a request for its specific function. Search may receive a set of queries. A connector may receive one operation and its parameters. The result returns in a form loqy expects.

The second boundary concerns a tool. The Core builds a research query from the useful terms, while the financial workbook remains in local work.

3. Running work remotely

A remote engine would move execution state, tools, and some authority to cloud infrastructure. That is a different architecture, useful for remote access or processing independent of the Mac. The V1 path runs the engine and its authority on the Mac; a hosted model moves only generation.

The path of a mixed request

Return to the finance note and follow it step by step.

1. Local opening. The finance director opens both forecasts. loqy keeps the conversation and working references on the Mac.
2. First local analysis. A local model extracts assumptions, finds disagreements, and prepares questions that need evidence.
3. Explicit research. The user authorises research into a small set of public signals. The service receives the queries it needs, not the full internal documents.
4. Model choice. If scenario analysis needs more capacity, the user selects a hosted model. The Core assembles the generation context and sends it to the chosen provider.
5. Effect control. The model may propose a revision or action. The Core checks permissions and requires the corresponding decision before a consequential effect.
6. Local delivery. The note, sources, tool results, and decisions remain attached to the work for review.

Research and hosted inference receive the data required for their role. Each crossing has an identifiable recipient and scope, making the privacy boundary precise.

Layered controls around the device

A local machine can be compromised, lost, poorly backed up, or rarely patched. A process with excessive permissions can read data it should not see. A document or web page can carry hostile instructions designed to redirect an agent. A downloaded model can differ from the expected artefact.

Local-first primarily optimises for control and minimised trust. It needs concrete security mechanisms around it.

In loqy V1:

• the local Core is the sole authority over business state, permissions, and effects;
• managed models and engines have expected identities and artefacts;
• provider credentials stay in macOS Keychain and are not given to the model;
• available tools form a closed set scoped to the run;
• code, scripts, and other untrusted processing run in an isolated environment;
• an external or destructive action crosses a typed, visible permission;
• the model and provider choice stays fixed for the run, with no silent fallback.

Together, these controls reduce ambient authority and make boundaries testable. Model location becomes one layer in a broader security design.

Informed choice at the right level

Control remains useful when it concerns a decision people can understand. loqy groups routine operations into narrow capabilities and reserves approval for the effects that require it.

loqy therefore puts decisions at the right level: model choice, tool permission, resource access, and approval of a consequential effect. The product knows which data a conversation and its tools need. It does not ask the user to reconstruct every technical envelope by hand.

The interface keeps movement between local and remote services smooth and identifies the boundary when it matters.

Start local so the choice remains yours

The finance director can ultimately stay entirely local. She can also authorise a bounded search and select a hosted model for part of the analysis. In both cases, the local engine retains the organisation of work, rules, tools, and evidence.

loqy therefore starts local to preserve that choice. The internet and hosted models remain available as capabilities selected by the user while work keeps its local anchor.

Sources and method

• Ink & Switch, Local-first software
• loqy, product vision and scope
• loqy, architecture overview
• loqy, local inference architecture
• loqy, Core-relayed hosted inference providers
• loqy, threat model

This article describes the loqy V1 product and architecture contract. Later cloud architectures are documented separately.