Most AI apps you use today are thin clients to someone else's cloud. You type a prompt, it goes to their servers; your files get uploaded so the model can read them; your conversation history lives in their database; and the API key — if there even is one — is theirs, billed back to you with a margin. That arrangement is convenient, and for a lot of uses it's fine. But it quietly makes one assumption: that your data, your work, and your credentials are theirs to hold.
Local-first AI flips that default. This article explains what "local-first" actually means, what changes when you apply it to AI specifically, and how to tell whether a tool that claims to be local-first really is. Orkas is built this way, so we'll use it as the concrete example — but the ideas apply to any tool in this category.
Scope note. The direct-key sections below describe Orkas's bring-your-own-provider path. Orkas also offers optional managed official models; those requests use Orkas's managed model service. Local-first describes workspace defaults and control, not a requirement that every model request bypass Orkas.
Quick answers
What is local-first AI?
Local-first describes where workspace data and the control plane live by default: on your device. It does not require every model call to bypass the app vendor. Orkas offers optional managed official models and also a direct bring-your-own-provider path.
Is local-first AI the same as running a local LLM?
No. Local-first describes where your data, keys, and control plane live — on your machine. The model itself can still be a cloud API such as OpenAI or Anthropic. Running a fully local model (for example with Ollama) is one option within a local-first design, not the definition of it.
What does bring-your-own-key (BYO-key) mean?
Bring-your-own-key means you connect a provider using your own API key or OAuth account. With this path, the key stays on your device and model calls go directly to that provider. It is an alternative to Orkas's optional managed official models.
What "local-first" actually means
The term comes from software design generally, not from AI. Stripped down, a local-first app holds to three properties:
- Your data lives on your device by default. Documents, history, settings — the source of truth is a file on your own disk, not a row in a remote database.
- The app works from your machine. The core features run locally; they don't require a round-trip to a server to function.
- The network is opt-in, not the foundation. Sync, sharing, and collaboration are features you can turn on — not the thing the app is fundamentally made of. Turn them off and the app still works.
Contrast that with the cloud-first SaaS default, where the server is the source of truth and your device is just a window onto it. Close the laptop lid on a cloud-first app and your data was never really yours to begin with; it was always sitting on their infrastructure, governed by their terms, visible to their staff and subpoenas. Local-first inverts the burden of proof: the data is yours unless you explicitly decide to send a copy somewhere.
What changes when the app is an AI agent
For a bring-your-own-provider path, those properties create two additional privacy benefits.
Bring your own key (BYO-key). You supply a provider credential — an API key or OAuth sign-in — and control that provider's models, limits, and bill. In Orkas this is an alternative to optional managed official models.
BYO model calls go direct. When an agent uses your own provider, the request goes straight from your machine to that provider and does not pass through Orkas. Managed official models use Orkas's managed model service instead.
It's worth being precise here, because "the AI runs locally" is a common misreading. Local-first does not mean the model itself runs on your laptop (though it can — more on that below). The model can still be a giant cloud API. What's local is everything around the model: your data, your keys, your agent configuration, and the control plane that decides what to send and when. Local-first is about who holds your stuff, not about where the GPU is.
Where your stuff actually lives
Concretely, in a local-first agent like Orkas, here's the split between what stays put and what can move.
By default, on your own machine:
- Your API keys and OAuth tokens — encrypted at rest and excluded from any sync.
- Your chat history, plans, and generated files.
- Your agent configurations, skills, and knowledge bases.
- Your personal memory — the preferences and facts the agent has learned about you.
The credential handling deserves a closer look, because keys are the most sensitive thing an AI tool touches. The lifecycle of a key in a well-built local-first app is short and contained:
1. You add it → paste an API key (or sign in with OAuth), on-device
2. Encrypted at rest → sealed with authenticated AES-256-GCM before it touches disk
3. Stored locally → written to a machine-private config file, excluded from sync
4. Used directly → decrypted in memory only to call your provider, straight from your machine
The key never crosses the wire to the app vendor — not at rest, not in transit, not in telemetry. (Authenticated encryption like AES-256-GCM also makes tampering detectable; it guards against casual disclosure — a stray log, a backup that runs OCR, another app reading the folder — which is the realistic threat for an on-disk secret.)
What still leaves — and only on your command
"Local-first" does not mean "nothing ever leaves your machine." Orkas documents each network path: provider and connector calls you initiate, managed features you select, optional sync, and limited product analytics.
- The model call to your own provider. Your prompts and the replies travel directly between your computer and the provider you picked. They leave your machine — but they go to your provider, not to Orkas.
- Connector calls you explicitly authorize. When you connect GitHub, Notion, Google, and so on, those calls go from your machine to that service. The OAuth tokens are stored on your device; for a few providers that rotate their tokens on every refresh, the refresh step is coordinated through Orkas so your devices don't race each other — a deliberately narrow exception, documented in the open.
- Cloud sync, if you turn it on. Multi-device sync is opt-in. Enable it and the data you choose to sync is stored on Orkas servers so it's available across your devices. Leave it off and nothing syncs.
- Limited, privacy-respecting analytics. Aggregate usage events (which features get used) — never your prompts, file contents, message text, or credentials.
For the BYO path, your provider key stays local and its model traffic does not touch Orkas servers. Managed official models, sync, connectors, and other selected cloud features use Orkas services as described on the Security page.
Why local-first matters
This isn't privacy theater. The default of "your stuff stays yours" buys several concrete things.
Data sovereignty. Your conversations, the files an agent reads and writes, the knowledge base you built — they sit on your disk, under your control. You can back them up, inspect them, or delete them, without asking anyone. There's no vendor database holding the canonical copy.
Auditability. With your own provider, you can read the open-source client, watch the network, and confirm the direct prompt path. Managed features have a different documented path through Orkas services.
Model choice. Choose optional managed official models or connect your own provider and switch its models when needed.
Cost transparency. Managed capabilities consume Orkas credits; usage through your own key is billed directly by that provider.
Resilience. Because the core runs on your machine and your data is local, the tool isn't one outage or one discontinued-product email away from taking your work with it.
Local-first vs. a fully local model — a clarification
One distinction trips people up often enough to be worth its own section. "Local-first AI," "on-device AI," and "running a local LLM" are related but not the same.
- Running a local LLM (with something like Ollama) means the model weights run on your hardware. Nothing — prompt or reply — leaves your machine at all. It's maximally private, but bounded by your hardware, so the models are smaller than the frontier cloud ones.
- Local-first AI is about where your workspace data, keys, and control plane live by default. Model traffic follows the path you choose: Orkas-managed official models use Orkas services, while own-provider calls go directly to that provider.
So they compose rather than compete: a local-first tool that also supports a local model gives you the strongest privacy posture available, while the same tool pointed at a cloud API gives you frontier capability with your data still under your control. Local-first is the architecture; a local model is one of the engines you can drop into it.
How to tell if an AI tool is really local-first
The label gets used loosely, so here's a short checklist you can apply to any tool that claims it. Ask:
- Where does workspace data live by default? Local-first means the device is the default source of truth.
- Which network paths exist? A trustworthy product distinguishes direct BYO calls from managed-model, sync, connector, and analytics traffic.
- Is sync opt-in? Local-first data remains local until you deliberately enable synchronization.
- Can I verify the claims? Open-source clients let you inspect code and network behavior.
- Which model path do I want? BYO gives direct provider billing and traffic; managed models trade that path for convenience and Orkas credits.
Wrapping up
Local-first is a stance about defaults: workspace data and control begin on your machine, while each optional network feature has a disclosed path. In Orkas, managed official models use Orkas services and your own-provider calls go directly to that provider.
If you want to see exactly how this is implemented — the key lifecycle, the encryption, the precise list of what stays and what leaves — read the Security & Trust page; because the client is open source, none of it has to be taken on faith. And if you want the engineering underneath the agent itself, see how a single agent is built to run reliably on your machine and how a lead agent coordinates a team of sub-agents.
A maioria dos aplicativos de IA que você usa hoje são thin clients para a nuvem de outra pessoa. Você digita um prompt, ele vai para seus servidores; seus arquivos são carregados para que a modelo possa lê-los; seu histórico de conversas fica no banco de dados deles; e a chave da API – se houver uma – é deles, cobrada de você com uma margem. Esse arranjo é conveniente e, para muitos usos, é adequado. Mas silenciosamente faz uma suposição: que seus dados, seu trabalho e suas credenciais são de propriedade deles.
IA local-first inverte esse padrão. Este artigo explica o que realmente significa "local-first", o que muda quando você o aplica especificamente à IA e como saber se uma ferramenta que afirma ser local-first realmente o é. O Orkas foi construído desta forma, então vamos usá-lo como exemplo concreto, mas as ideias se aplicam a qualquer ferramenta desta categoria.
Nota de escopo. As seções de chave própria descrevem o caminho BYO do Orkas. Modelos oficiais gerenciados usam o serviço gerenciado do Orkas. Local-first descreve os padrões do workspace e o controle, não exige que toda chamada ignore o Orkas.
O que "local primeiro" realmente significa
O termo vem do design de software em geral, não da IA. Simplificado, um aplicativo local primeiro contém três propriedades:
- Seus dados ficam no seu dispositivo por padrão. Documentos, histórico, configurações — a fonte da verdade é um arquivo em seu próprio disco, não uma linha em um banco de dados remoto.
- O aplicativo funciona na sua máquina. Os principais recursos são executados localmente; eles não exigem uma viagem de ida e volta até um servidor para funcionar.
- A rede é opcional, não a base. Sincronização, compartilhamento e colaboração são recursos que você pode ativar, e não aquilo de que o aplicativo é fundamentalmente feito. Desligue-os e o aplicativo continuará funcionando.
Compare isso com o padrão SaaS que prioriza a nuvem, onde o servidor é a fonte da verdade e seu dispositivo é apenas uma janela para ele. Feche a tampa do laptop em um aplicativo que prioriza a nuvem e, para começar, seus dados nunca serão realmente seus; estava sempre instalado em sua infraestrutura, regido por seus termos, visível para seus funcionários e intimações. Local-first inverte o ônus da prova: os dados são seus, a menos que você decida explicitamente enviar uma cópia para algum lugar.
O que muda quando o aplicativo é um agente de IA
Quando essas propriedades são aplicadas a uma ferramenta de IA, a escolha do caminho do modelo se torna parte importante da privacidade e do controle.
Traga sua própria chave (BYO-key). No caminho BYO, você fornece uma chave de API ou login OAuth de um provedor como OpenAI, Anthropic ou Google. A chave fica no seu dispositivo, e você controla provedor, modelo, limites e faturamento. Como alternativa, o Orkas também oferece modelos oficiais gerenciados.
Chamadas BYO vão direto ao provedor. Quando o agente usa seu próprio provedor, a solicitação vai diretamente da sua máquina para esse provedor e não passa pelo Orkas. Os modelos oficiais gerenciados usam o serviço de modelos gerenciado pelo Orkas.
Vale a pena ser preciso aqui, porque “a IA é executada localmente” é um erro de leitura comum. Local-first não significa que o modelo em si roda em seu laptop (embora possa – mais sobre isso abaixo). O modelo ainda pode ser uma API de nuvem gigante. O que é local é tudo em torno do modelo: seus dados, suas chaves, a configuração do seu agente e o plano de controle que decide o que enviar e quando. Local-first é uma questão de quem guarda suas coisas, não de onde está a GPU.
Onde suas coisas realmente ficam
Concretamente, em um agente local como Orkas, aqui está a divisão entre o que permanece onde está e o que pode ser movido.
Por padrão, em sua própria máquina:
- Suas chaves de API e tokens OAuth — criptografados em repouso e excluídos de qualquer sincronização.
- Seu histórico de bate-papo, planos e arquivos gerados.
- Suas configurações, habilidades e bases de conhecimento do agente.
- Sua memória pessoal: as preferências e fatos que o agente aprendeu sobre você.
O manuseio de credenciais merece uma análise mais detalhada, porque as chaves são a coisa mais sensível que uma ferramenta de IA toca. O ciclo de vida de uma chave em um aplicativo local bem desenvolvido é curto e contido:
1. Você adiciona → cola uma chave de API (ou faz login com OAuth), no dispositivo
2. Criptografado em repouso → selado com AES-256-GCM autenticado antes de tocar no disco
3. Armazenado localmente → gravado em um arquivo de configuração privado da máquina, excluído da sincronização
4. Usado diretamente → descriptografado na memória apenas para ligar para seu provedor, direto da sua máquina
No caminho BYO, a chave não é enviada ao Orkas, nem em repouso, nem em trânsito, nem em telemetria. (A criptografia autenticada como AES-256-GCM também torna a adulteração detectável; ela protege contra divulgação casual – um registro perdido, um backup que executa OCR, outro aplicativo lendo a pasta – que é a ameaça realista para um segredo no disco.)
O que ainda sai — e somente sob seu comando
"Local primeiro" não significa "nada sai da sua máquina". Isso seria um aplicativo inútil – e uma afirmação desonesta. O enquadramento honesto é: as coisas só saem quando você pede e para os destinos que você escolheu. Uma ferramenta local confiável é explícita sobre exatamente o que são. Para Orcas:
- O modelo chama seu próprio provedor. Seus prompts e respostas viajam diretamente entre seu computador e o provedor que você escolheu. Eles saem da sua máquina, mas vão para o seu provedor, não para o Orkas.
- Chamadas do conector que você autoriza explicitamente. Quando você conecta o GitHub, o Notion, o Google e assim por diante, essas chamadas vão da sua máquina para esse serviço. Os tokens OAuth são armazenados no seu dispositivo; para alguns provedores que alternam seus tokens a cada atualização, a etapa de atualização é coordenada por meio do Orkas para que seus dispositivos não compitam entre si — uma exceção deliberadamente restrita, documentada abertamente.
- Sincronização na nuvem, se você a ativar. A sincronização de vários dispositivos é opcional. Habilite-o e os dados que você escolher sincronizar serão armazenados nos servidores Orkas para que fiquem disponíveis em seus dispositivos. Deixe-o desativado e nada será sincronizado.
- Análises limitadas e que respeitam a privacidade. Agregue eventos de uso (quais recursos são usados) — nunca seus prompts, conteúdo de arquivo, texto de mensagem ou credenciais.
No caminho BYO, sua chave fica local e o tráfego vai direto ao provedor. Modelos oficiais gerenciados e outros recursos de nuvem selecionados usam serviços do Orkas.
Por que priorizar o local é importante
Isto não é um teatro de privacidade. O padrão de “suas coisas permanecem suas” compra várias coisas concretas.
Soberania de dados. Suas conversas, os arquivos que um agente lê e grava, a base de conhecimento que você construiu — eles ficam em seu disco, sob seu controle. Você pode fazer backup deles, inspecioná-los ou excluí-los sem perguntar a ninguém. Não há banco de dados de fornecedores que contenha a cópia canônica.
Auditabilidade. Com seu próprio provedor, você pode ler o cliente open source, observar a rede e confirmar o caminho direto do prompt. Recursos gerenciados têm um caminho diferente e documentado pelos serviços do Orkas.
Escolha de modelo. Você pode usar modelos oficiais gerenciados ou conectar seu próprio provedor e trocar seus modelos quando necessário.
Transparência de custos. Recursos gerenciados consomem créditos Orkas; o uso da sua própria chave é cobrado diretamente pelo provedor.
Resiliência. Como o núcleo é executado em sua máquina e seus dados são locais, a ferramenta não está a uma interrupção ou a um e-mail de produto descontinuado de levar seu trabalho consigo.
Local primeiro versus um modelo totalmente local — um esclarecimento
Uma distinção confunde as pessoas com frequência suficiente para valer sua própria seção. "IA local primeiro", "IA no dispositivo" e "executar um LLM local" estão relacionados, mas não são a mesma coisa.
- Executar um LLM local (com algo como Ollama) significa que os pesos do modelo são executados em seu hardware. Nada – prompt ou resposta – sai da sua máquina. É maximamente privado, mas limitado pelo seu hardware, portanto os modelos são menores do que os modelos de nuvem de fronteira.
- IA local-first trata de onde os dados do workspace, as chaves e o plano de controle residem por padrão. O tráfego do modelo segue o caminho escolhido: modelos oficiais gerenciados usam serviços do Orkas, enquanto chamadas do seu próprio provedor vão direto a ele.
Portanto, eles compõem em vez de competir: uma ferramenta local que também oferece suporte a um modelo local oferece a postura de privacidade mais forte disponível, enquanto a mesma ferramenta apontada para uma API de nuvem oferece capacidade de fronteira com seus dados ainda sob seu controle. O local em primeiro lugar é a arquitetura; um modelo local é um dos motores que você pode usar nele.
Como saber se uma ferramenta de IA realmente prioriza o local
O rótulo é usado de maneira imprecisa, então aqui está uma pequena lista de verificação que você pode aplicar a qualquer ferramenta que o indique. Pergunte:
- Onde os dados do workspace ficam por padrão? Local-first significa que o dispositivo é a fonte de verdade padrão.
- Quais caminhos de rede existem? Uma ferramenta confiável distingue chamadas BYO diretas de modelos gerenciados, sync, conectores e analytics.
- A sincronização é opt-in? Os dados permanecem locais até você habilitar a sincronização deliberadamente.
- Posso verificar as afirmações? Clientes open source permitem inspecionar código e comportamento de rede.
- Qual caminho de modelo eu quero? BYO oferece tráfego e cobrança diretos pelo provedor; modelos gerenciados trocam esse caminho por conveniência e créditos Orkas.
Concluindo
IA local-first é uma postura sobre padrões: dados do workspace e controle começam na sua máquina, enquanto cada recurso opcional de rede tem um caminho declarado. No Orkas, modelos oficiais gerenciados usam serviços do Orkas e chamadas do seu próprio provedor vão direto a ele.
Se você quiser ver exatamente como isso é implementado — o ciclo de vida da chave, a criptografia, a lista precisa do que permanece e do que sai — leia a página Segurança e Confiança; como o cliente é de código aberto, nada disso precisa ser considerado confiável. E se você quiser a engenharia por trás do próprio agente, veja como um único agente é criado para funcionar de maneira confiável em sua máquina e como um agente líder coordena uma equipe de subagentes.
你今天用的大多数 AI 应用，本质上都是别人云端的一个瘦客户端。你敲一句提示词，它发去他们的服务器；你的文件被上传，好让模型能读；你的对话历史存在他们的数据库里；而那把 API key——如果有的话——是他们的，加了利润再算到你头上。这种安排很方便，对很多用途也确实够用。但它悄悄预设了一件事：你的数据、你的工作、你的凭证，归他们保管。
本地优先 AI（local-first AI）把这个默认反了过来。这篇文章讲清楚「本地优先」到底是什么意思，把它套到 AI 上之后有哪些变化，以及怎么判断一个号称本地优先的工具是不是真的。Orkas 就是这么做的，所以我们拿它当具体例子——但这些观念适用于这一类里的任何工具。
范围说明。下文的自带 Key 部分描述 Orkas 的 BYO 路径。托管官方模型使用 Orkas 托管模型服务。本地优先描述工作区默认值和控制面，并不要求所有模型调用都绕过 Orkas。
「本地优先」到底是什么意思
这个词来自软件设计本身，不是 AI 圈造的。剥到最核心，一个本地优先的应用守着三条性质：
- 你的数据默认存在你的设备上。 文档、历史、设置——真相的源头是你自己磁盘上的一个文件，而不是远端数据库里的一行记录。
- 应用从你的机器上运行。 核心功能在本地跑，不需要往服务器跑一个来回才能用。
- 联网是可选项，不是地基。 同步、分享、协作是你可以开启的功能——而不是这个应用赖以存在的根本。把它们关掉，应用照样能用。
对比一下云优先（cloud-first）的 SaaS 默认：服务器才是真相之源，你的设备只是一扇朝它开的窗。在一个云优先应用上合上笔记本盖子，你的数据从一开始就不真正属于你；它一直待在他们的基础设施上，受他们的条款管辖，对他们的员工和传票可见。本地优先把举证责任反了过来：数据是你的，除非你明确决定把一份副本发到某个地方。
当这个应用是个 AI agent 时，会变什么
把那三条性质套到 AI 工具上，会额外推出两条 AI 特有的承诺——而这两条恰恰是对隐私最要紧的。
自带密钥（BYO-key, Bring Your Own Key）。 在 BYO 路径中，你提供自己的 API key 或供应商 OAuth 登录，并掌控供应商、模型、限额和账单；Orkas 也提供可选的托管官方模型。
BYO 模型调用直连。 当 agent 使用你自己的供应商时，请求会从你的机器直接发往该供应商，不经过 Orkas。托管官方模型则使用 Orkas 托管模型服务。
这里值得说精确点，因为「AI 在本地跑」是一个很常见的误读。本地优先并不意味着模型本身跑在你的笔记本上（虽然它可以——下面会讲）。模型仍然可以是一个庞大的云端 API。本地的是模型周围的一切：你的数据、你的密钥、你的 agent 配置，以及决定「发什么、何时发」的控制面。本地优先讲的是谁保管你的东西，而不是 GPU 在哪。
你的东西到底存在哪
具体到 Orkas 这样一个本地优先的 agent，下面是「留在原地的」和「可以走的」之间的划分。
默认存在你自己的机器上：
- 你的 API 密钥和 OAuth token——加密落盘，且被排除在任何同步之外。
- 你的 对话历史、计划、生成的文件。
- 你的 agent 配置、技能、知识库。
- 你的 个人记忆——agent 学到的关于你的偏好和事实。
凭证的处理值得细看，因为 key 是一个 AI 工具会碰到的最敏感的东西。在一个做得好的本地优先应用里，一把 key 的生命周期很短、很受控：
1. 你添加它 → 在本机粘贴一把 API key（或用 OAuth 登录）
2. 加密落盘 → 在碰到磁盘之前，用带认证的 AES-256-GCM 封好
3. 本地存储 → 写进一个机器私有的配置文件，排除在同步之外
4. 直接使用 → 仅在内存里解密，用来从你的机器直接调用你的供应商
在 BYO 路径中，这把 key 不会跨网络传到 Orkas——落盘时不会，传输时不会，遥测里也不会。（像 AES-256-GCM 这样的认证加密还能让篡改可被发现；它防的是随手泄露——一条乱入的日志、一个会跑 OCR 的备份、另一个应用读了这个文件夹——这才是一个落盘密钥现实中要面对的威胁。）
什么仍然会离开——而且只在你下令时
「本地优先」不等于「什么都永远不离开你的机器」。那会是个没用的应用——也是个不诚实的说法。诚实的表述是：东西只在你要求时才离开，而且去往你选定的目的地。一个值得信任的本地优先工具，会把这些到底是什么讲得明明白白。对 Orkas 来说：
- 发往你自己供应商的模型调用。 你的提示词和回复，在你的电脑和你挑的那家供应商之间直接往来。它们离开了你的机器——但去的是你的供应商，不是 Orkas。
- 你明确授权的连接器调用。 当你连上 GitHub、Notion、Google 等等，这些调用从你的机器发往那个服务。OAuth token 存在你的设备上；对少数会在每次刷新时轮换 token 的供应商，刷新这一步会经由 Orkas 协调，免得你的多台设备互相抢——一个刻意收得很窄、且公开记录在案的例外。
- 云同步，如果你开启的话。 多设备同步是可选项。开了它，你选择同步的那部分数据会存到 Orkas 服务器上，好让它在你的多台设备间可用。不开，就什么都不同步。
- 有限的、尊重隐私的分析数据。 聚合的使用事件（哪些功能被用了）——绝不包含你的提示词、文件内容、消息文本或凭证。
在 BYO 路径中，供应商 Key 留在本机，模型流量直连该供应商。托管官方模型及其他由你选择的云端功能会使用 Orkas 服务。
为什么本地优先重要
这不是隐私表演。「你的东西仍归你」这个默认，换来几样实打实的东西。
数据主权。 你的对话、agent 读写的文件、你搭起来的知识库——它们躺在你的磁盘上，归你控制。你可以备份、检查、删除，不用问任何人。没有哪个厂商的数据库握着那份「正本」。
可审计。 使用自有供应商时，你可以读开源客户端、观察网络流量并确认提示词的直连路径；托管功能则有一条经 Orkas 服务的、明确记录的路径。
模型可选。 你可以选择托管官方模型，也可以连接自己的供应商并按需切换模型。
成本透明。 托管能力消耗 Orkas credits；自有密钥的用量由对应供应商直接计费。
韧性。 因为核心在你机器上跑、数据又在本地，这个工具不会因为一次宕机、或一封「产品下线」的邮件，就把你的工作一起带走。
本地优先 vs. 纯本地模型——一个澄清
有一个区分常把人绊住，值得单开一节。「本地优先 AI」「端侧 AI」和「跑一个本地 LLM」相关，但不是一回事。
- 跑一个本地 LLM（用 Ollama 之类）指的是模型权重在你的硬件上运行。任何东西——提示词或回复——根本不离开你的机器。它隐私最大化，但受限于你的硬件，所以模型比前沿的云端模型小。
- 本地优先 AI 讲的是工作区数据、密钥和控制面默认在哪。模型流量取决于你选的路径：托管官方模型使用 Orkas 服务，自有供应商调用则直接发往该供应商。
所以两者是叠加而不是竞争：一个同时支持本地模型的本地优先工具，给你的是能拿到的最强隐私姿态；而同一个工具指向云端 API 时，给你的是前沿能力、且数据仍在你掌控之下。本地优先是架构；本地模型是你可以塞进去的引擎之一。
怎么判断一个 AI 工具是不是真本地优先
这个标签被用得很松，所以这里给一份简短清单，可以套到任何号称本地优先的工具上。问：
- 工作区数据默认存在哪？ 本地优先意味着设备是默认的真相来源。
- 有哪些网络路径？ 值得信任的产品会区分 BYO 直连、托管模型、同步、连接器和分析数据。
- 同步是可选的吗？ 在你主动开启同步前，本地优先数据应留在本机。
- 这些主张能核实吗？ 开源客户端让你检查代码和网络行为。
- 该选哪条模型路径？ BYO 提供供应商直连与直接计费；托管模型用便利性和 Orkas credits 换取不同的服务路径。
小结
本地优先 AI 是一种关于默认值的立场：工作区数据与控制从你的机器开始，每项可选网络功能都有明确路径。在 Orkas 中，托管官方模型使用 Orkas 服务，自有供应商调用则直连该供应商。
想看这具体是怎么实现的——密钥的生命周期、加密、以及「什么留下、什么离开」的精确清单——去读安全与信任页；因为客户端开源，这些都不必凭信仰接受。想看 agent 本身底下的工程，去看一个 agent 是怎么被造得能在你机器上可靠运行的，以及一个主 agent 是怎么协调一支子 agent 团队的。
いま使われている多くの AI アプリは、実質的には誰かのクラウドへつながる薄いクライアントです。プロンプトは相手のサーバーへ送られ、ファイルもモデルに読ませるためアップロードされ、会話履歴は相手のデータベースに残ります。API キーがあるとしても、それはたいていアプリ側の鍵で、利用料に上乗せされて請求されます。この形は便利ですが、ひとつの前提を静かに置いています。あなたのデータ、仕事、認証情報を相手が預かるという前提です。
ローカルファースト AI は、この初期値を反転させます。この記事では、ローカルファーストとは何か、それを AI agent に適用すると何が変わるのか、そして本当にローカルファーストなツールかどうかをどう見分けるのかを整理します。Orkas はこの考え方で作られているので、具体例として Orkas を使います。
範囲の注記。以下の自分の鍵に関する説明は Orkas の BYO 経路です。公式マネージドモデルは Orkas のマネージドモデルサービスを利用します。ローカルファーストはワークスペースの既定と制御を表し、すべてのモデル呼び出しが Orkas を迂回するという意味ではありません。
ローカルファーストとは何か
この言葉は AI 固有ではなく、ソフトウェア設計から来ています。要点を絞ると、ローカルファーストなアプリには三つの性質があります。
- データは既定で自分のデバイスにある。 文書、履歴、設定の正本は、リモート DB の行ではなく自分のディスク上のファイルです。
- アプリは自分のマシンから動く。 中核機能はローカルで動き、毎回サーバー往復しないと成立する構造ではありません。
- ネットワークは選択肢であって土台ではない。 同期、共有、共同編集は有効化できる機能であり、オフにしてもアプリは使えます。
クラウドファーストな SaaS では、サーバーが真実の源で、手元の端末はそこを見る窓にすぎません。ローカルファーストは証明責任を逆にします。データはあなたのものです。どこかへコピーを送ると明示的に決めるまでは、あなたの手元にあります。
AI agent になると何が変わるか
この考え方を AI ツールに持ち込むと、プライバシー上とても重要な二つの約束が生まれます。
Bring your own key（BYO-key）。 BYO 経路では、OpenAI、Anthropic、Google などの自分の API キーや OAuth 認証を使い、プロバイダー、モデル、制限、請求を自分で管理します。Orkas には公式マネージドモデルという別の選択肢もあります。
BYO のモデル呼び出しは直通です。 agent が自分のプロバイダーを使うとき、リクエストはあなたのマシンからそのプロバイダーへ直接送られ、Orkas を通りません。公式マネージドモデルは Orkas のマネージドモデルサービスを利用します。
ここは正確に言う必要があります。ローカルファーストは「巨大モデルそのものが必ず手元で動く」という意味ではありません。モデルはクラウド API でもかまいません。ローカルなのは、モデルの周囲にあるものです。データ、鍵、agent 設定、何をいつ送るかを決める制御面。それが誰の手元にあるか、という話です。
何がどこに残るのか
Orkas のようなローカルファースト agent では、既定で次のものが自分のマシンにあります。
- API キーと OAuth トークン。保存時に暗号化され、同期対象から外されます。
- チャット履歴、計画、生成されたファイル。
- agent 設定、skills、ナレッジベース。
- 個人メモリ。agent が学んだあなたの好みや事実です。
特に鍵の扱いは重要です。よく作られたローカルファーストアプリでは、鍵のライフサイクルは短く閉じています。
1. 追加する → API キーを貼る、または OAuth でログインする
2. 暗号化して保存 → ディスクに触れる前に AES-256-GCM で封じる
3. ローカルに保存 → マシン専用の設定ファイルへ書き、同期から外す
4. 直接使う → メモリ上で復号し、あなたのマシンからプロバイダーへ直通する
BYO 経路では、鍵は Orkas のサーバーへ渡りません。保存時にも、通信時にも、テレメトリにも載りません。
それでも外へ出るもの
ローカルファーストは「何も外へ出ない」という意味ではありません。それでは役に立つ AI ツールになりません。正しい説明は、外へ出るのはあなたが指示したものだけで、行き先もあなたが選ぶ、ということです。
- 自分のプロバイダーへのモデル呼び出し。 プロンプトと応答は、あなたのコンピューターとあなたが選んだプロバイダーの間を直接行き来します。Orkas には行きません。
- 明示的に許可したコネクター呼び出し。 GitHub、Notion、Google などへ接続した場合、その通信はあなたのマシンから相手サービスへ向かいます。
- オンにした場合のクラウド同期。 複数デバイス同期は任意です。オンにしたデータだけが Orkas サーバーへ保存されます。
- 限定的な利用状況分析。 どの機能が使われたかという集計イベントだけで、プロンプト、ファイル本文、メッセージ、認証情報は含みません。
BYO 経路では、鍵はローカルに残り、モデル通信は選んだプロバイダーへ直通します。公式マネージドモデルと、選択したその他のクラウド機能は Orkas のサービスを利用します。
なぜ重要なのか
データ主権。 会話、agent が読んだり書いたりするファイル、構築したナレッジベースは、あなたのディスク上にあります。バックアップ、確認、削除を誰かに頼む必要はありません。
監査可能性。 自分のプロバイダーを使う場合は、オープンソースのクライアントとネットワークを見て直通経路を確認できます。マネージド機能には Orkas サービスを使う別の公開経路があります。
モデルの選択。 公式マネージドモデルか、自分で接続するプロバイダーとそのモデルを必要に応じて選べます。
コストの透明性。 マネージド機能は Orkas credits を消費し、自分の鍵による利用はそのプロバイダーから直接請求されます。
耐障害性。 中核が手元で動き、データも手元にあるため、外部サービスの障害や終了告知で仕事そのものが失われる構造になりにくいのです。
ローカルファーストとローカル LLM の違い
ローカルファースト AI、オンデバイス AI、ローカル LLM は近い言葉ですが同じではありません。
- ローカル LLM は、Ollama などでモデル重み自体を自分のハードウェア上で動かすことです。プロンプトも応答も外へ出ませんが、利用できるモデルは手元の性能に左右されます。
- ローカルファースト AI は、ワークスペースデータ、鍵、制御面が既定でどこにあるかを指します。モデル通信は選択した経路に従い、公式マネージドモデルは Orkas サービスを、自分のプロバイダーは直通経路を使います。
両者は競合ではなく組み合わせられます。ローカルモデルを選べるローカルファーストツールなら最も強いプライバシー姿勢を取れますし、クラウド API を使っても、データと鍵は自分の管理下に残ります。
本当にローカルファーストかを見分ける
- ワークスペースデータは既定でどこにあるか。 ローカルファーストではデバイスが既定の正本です。
- どのネットワーク経路があるか。 信頼できる製品は BYO 直通、マネージドモデル、同期、コネクター、分析を区別します。
- 同期は任意か。 有効化するまでデータはローカルに残ります。
- 検証できるか。 オープンソースのクライアントならコードと通信を確認できます。
- どのモデル経路を選ぶか。 BYO はプロバイダー直通と直接請求、マネージドモデルは利便性と Orkas credits という別の経路です。
まとめ
ローカルファースト AI は初期値に対する立場です。ワークスペースデータと制御は手元から始まり、任意のネットワーク機能には明示された経路があります。Orkas では、公式マネージドモデルは Orkas サービスを、自分のプロバイダーは直通経路を使います。
鍵のライフサイクル、暗号化、何が残り何が外へ出るのかを詳しく知りたい場合は、Security & Trust ページを読んでください。agent の実行基盤については、単体 agent をどう信頼できる実行環境にしているか、そして主 agent がサブ agent チームをどう調整するかも参考になります。
