SideNote ProUse local models for private work
Some work should not go to a hosted provider, and deciding case by case under time pressure is how mistakes happen. A local profile turns that decision into a one-click switch you make before sending.
What local actually means here
With a local provider such as Ollama or LM Studio, SideNote Pro sends the request to localhost. Inference runs on your own hardware. Nothing goes to a hosted AI provider.
This is the only configuration where *nothing leaves the machine* is literally true, which is why it is worth setting up even if it is not your everyday default. Everything else about SideNote Pro is already local: settings, history, folder indexes, usage. The provider request is the one thing that leaves, and a local profile closes that too.
One honest caveat: SideNote Pro does not supply the local model and cannot guarantee third-party software. It controls where the request is sent. Whether that destination keeps everything local depends on how you configured it, and that software's own documentation is the authority.
When to route work locally
- Content under contractual confidentiality, where sending it to a third party would breach an agreement regardless of that party's policies.
- Personal data you have no lawful basis to share with a processor you have not assessed.
- Unreleased material where the risk is not privacy but disclosure.
- Anything under a client restriction that names third-party AI services.
- High-volume repetitive work such as bulk rewriting or summarizing, where the reason is cost rather than confidentiality.
- Working offline, where a local model is the only one available at all.
Note that the last two are not privacy reasons. Local profiles are useful for cost and availability quite independently of confidentiality.
The two-profile split
- Keep your hosted profile as the defaultIt is more capable and faster for ordinary work. Most requests should still go there.
- Add a local profileFrom the Ollama or LM Studio preset. Name it something unmistakable, like Local, private, so the composer picker leaves no doubt.
- Switch before attaching, not afterSwitch profiles first, then attach the document. Doing it in that order means a mistimed keystroke cannot send the file to the wrong place.
- Check the picker before sendingThe composer names the profile and model receiving the next request. One glance is the entire safeguard.
What you give up
Being straight about this matters, because a local model that disappoints on the first try tends to get abandoned for the wrong reason.
| Local | Hosted | |
|---|---|---|
| Capability | Bounded by your hardware | Generally higher |
| Speed | Depends on your GPU, often slower | Usually faster |
| Cost per request | None | Metered |
| Image input | Uncommon in small models | Common in current models |
| Long context | Expensive in time | Handled better |
| Availability | Requires the local server running | Requires network |
| Data destination | Your machine | Your provider |
Practical adjustments: lower the context budget on a local profile, since prompt processing is where local hardware hurts most; expect context compaction to be noticeably slow, because it is a full model call on your own machine; and check image support before assuming a screenshot will work.
A realistic expectation
A small local model will not match a current frontier model on a hard reasoning problem. It does not have to. For summarizing a document you cannot send elsewhere, rewriting confidential text, or extracting structure from private notes, a modest local model is frequently entirely adequate.
The right comparison is not local model against frontier model. It is local model against not asking at all, because the alternative for this material was never the hosted one.