MemexMemex/Blog
← Back

Your Journal Is Local. Where Do AI Requests Go?

By Clifford · Product research

Written by the Memex team. Memex client source and Ollama documentation checked on October 19, 2026. This is a source-based explanation, not a packet capture, server audit or verification of a particular store release.

Suppose you save a note after dinner and attach a photo of the receipt. Memex keeps its journal records in a local workspace. When an enabled workflow asks a model to organize the evening, the app also submits a request to the configured endpoint.

The request may carry more than that one entry. Previous conversation, remembered preferences and a record read by a tool can all affect what is sent. Following those additions is more useful than asking whether the journal is simply “local” or “cloud.”

Start with the route, not the model name

In the inspected Memex client, model configurations select the client type, model and, where supported, a base URL. Different agents can resolve their own model configuration or a default. A familiar model name does not identify every organization between the phone and inference.

These routes describe model requests, not every connection the app or operating system might make. Check when your enabled workflow starts model work: capture and AI processing can be part of the same interaction. Responses return along the configured service connection; the archive and the request have separate lifecycles.

Three model-request routes to distinguish

Direct provider

  1. Phone app
  2. Chosen provider API

The provider receives the assembled request. This assumes the configured endpoint is actually that provider, without an added model gateway.

Model service or gateway

  1. Phone app
  2. Configured model service
  3. Upstream model, if forwarded

The service endpoint receives the request. Its downstream providers and handling need their own documentation.

Model on another device

  1. Phone app
  2. Your computer’s endpoint
  3. Local inference, if configured

Data leaves the phone. Verify that the receiving computer runs the model locally rather than forwarding it to a cloud model.

Memex: model-client construction and per-agent selection

What the provider receives can exceed what you just typed

A model needs a request assembled by the application. That can include instructions, conversation history, relevant records, attachments and results of earlier tools. In Memex’s SuperAgent source, user memory is added to the agent state as context, and the agent has record-recall and file-reading tools.

That does not mean every request uploads the entire archive. It means “I selected one note” is a statement about your action, not proof of a boundary enforced around the run. A model may already have memory context before it chooses a tool. Later tool results can add more material. The actual request depends on that run’s state and operations.

Possible request content to check for the feature you use
MaterialHow it can enter the workflowWhat to verify
Current noteIncluded as text for the task.The words you intended to send, including names and dates.
Memory and historyAdded context or earlier conversation.A fresh message is not necessarily an empty context.
Photo or audioAttached media supported by the selected model path.Whether media bytes, extracted text or both are processed remotely.
Tool resultsRetrieved records or outputs from a previous step.A later request may contain information absent from the first one.

Memex: SuperAgent memory and tools

A provider connection and a model service are different choices

For a direct connection, the request goes to the provider endpoint configured for that client. If you choose a compatible gateway instead, that gateway is the recipient even when the model name is unchanged. Bringing an API key does not establish which route is in use; inspect the effective endpoint as well.

Memex also has an optional Memex AI service setup. The client obtains a base URL and credentials from the account service and saves a model configuration using them. The receiving model-service endpoint is therefore part of the processing boundary. The client code alone does not prove its upstream routing, prompt retention or training policy.

Do not confuse this with the configuration’s optional network-proxy field. A transport proxy and an application-level model gateway serve different roles. The word “proxy” alone is not enough to determine whether an intermediary sees decrypted prompt content.

Memex: optional service configuration · Memex: account and model credentials

An Ollama address is not proof of phone-only inference

If the phone connects to an Ollama server on your laptop, that laptop receives the request. When the server actually runs the chosen model locally, inference happens there while the journal can stay on the phone. The endpoint must be reachable from the phone; localhost on the phone refers to the phone, not the computer beside it.

Ollama documents both local and cloud models, including using cloud models through a local server. Check the actual model and server configuration before describing the route as local inference. Its documentation also provides a way to disable cloud features. Downloading model files is another network operation, distinct from sending a journal entry for inference.

Ollama: local and cloud API endpoints · Ollama: local operation and cloud controls

Local transcription can still lead to a remote text request

Speech is a useful example because one recording can take several paths. The checked Memex implementation has a local speech-recognition path and a cloud-transcription path. The local path uses a downloaded on-device model. The cloud path encodes audio and submits it with a transcription instruction using the chat agent’s configured model resources.

If recognition happens on the device, that transcription step does not need to send the recording to a cloud model. But the transcript can later be given to an agent whose model runs remotely. Check transcription and subsequent analysis separately. A text-only model choice also does not guarantee that every media feature works with it.

Memex: local and cloud transcription paths · Memex: on-device recognizer and model download

Tools, logs and backups need their own route

Reading a local record and sending that record back to a model are different operations. If you enable a workflow with a remote tool, its input has another recipient; changing the main model does not automatically change that tool’s destination. Review the actual tools instead of assuming all work follows the chat endpoint.

The checked source also writes local diagnostic logs and can package workspace data, a database and settings into backups. A backup is broader than a note export. Treat diagnostic bundles and backup files as potentially sensitive, and inspect what they contain before sharing or storing them with another service.

Provider processing, retention and training are separate questions. The source inspected here cannot settle another operator’s server practices. Nor does deleting a local entry retract a request already sent, erase a backup or necessarily remove remembered context. Each copy needs its own lifecycle and deletion mechanism.

Memex: local diagnostic logging · Memex: backup contents

Trace one harmless example before using real records

Use invented content, such as “Dinner at Example Café on Tuesday,” without a real receipt. Write down the feature, the agent or agents doing the work, the effective model connection, the endpoint’s operator and any intermediary. Then list the possible payloads: text, history, memory, media and tool results.

Check the transcription setting separately if the test includes voice. If you intend local inference, verify the receiving host and the model running there. A new conversation can simplify the test, but it should not be treated as proof that memory and retrieval are absent.

The filled-in note should also leave room for unknowns: the service’s current retention terms, a downstream provider you have not identified, or an attachment path you have not inspected. It is a route inventory, not a packet capture. Establishing the full payload needs controlled inspection of request construction or traffic, using synthetic data and protecting credentials. We have not performed that device-level trace for this article.

A route note for your test

Feature and agent(s):
Effective model and endpoint operator:
Gateway or network proxy, if any:
Text / history / memory / media included:
Local or cloud transcription:
Additional tool destinations:
Backups or logs created:
What remains unverified:

Keep the record, choose the work you send

Open source lets you inspect how a request is built; model choice lets you choose a processing connection. Their practical value is a route you can examine and change. Neither label replaces checking the active configuration and the feature you are about to use. Trying a different configured endpoint does not require moving the primary archive to that service.

The dinner note can remain useful as a record even if you decide not to analyze it today. Later, a small question may justify sending some context to a model you trust. Keeping those two decisions separate leaves room for both a personal archive and useful AI.

Where the agent runs · The broader AI journal privacy checklist · Bring your own model connection