Models and Providers

Maabarium supports local-first workflows, but it does not force every workflow to use the same provider model.

Local-first default

If privacy, inspectability, and control matter most, start with a local runtime such as Ollama where available in your workflow.

Benefits:

• lower data exposure
• fewer external dependencies during experimentation
• easier reproducibility on a single machine

If you are using the desktop app with Ollama, the setup flow keeps local model downloads explicit. After Ollama is installed and running, use Pull Recommended Models to fetch the suggested local models for the bundled workflows instead of manually running ollama pull for each one.

Remote providers

Remote providers may still be useful when you need:

• stronger frontier-model reasoning
• specific APIs required by an existing blueprint
• a comparison baseline against local runs

Configuration guidance

• Keep secrets outside committed blueprint content whenever possible.
• Validate provider access during setup instead of during an important run.
• Prefer explicit model naming so later readers understand what generated a proposal.

Operational advice

Do not mix providers casually inside a workflow unless that is part of the evaluation design. Otherwise, interpreting outcomes becomes harder because performance changes may be model-related rather than workflow-related.

For research workflows, provider setup now includes the search path as well as the model path. In the desktop app you can keep the default DuckDuckGo scrape mode for a lower-friction setup, or switch to Brave API when you want the Brave-backed search path and have the necessary credential configured.

For local runtimes, separate these concerns when debugging:

• Ollama installed versus missing
• Ollama app running versus port 11434 not responding
• recommended models missing versus already downloaded

Maabarium’s desktop onboarding reflects those states directly so you can fix the right problem instead of guessing.