Providers & models

Local-first on Ollama — free, offline, no API keys — with every major cloud provider also supported through one canonical streaming format.

OpenAgentic is local-first. The recommended default provider is Ollama — run the whole platform on your own machine, free, offline, with no API keys. Every major cloud provider is also supported, and one canonical streaming format means every model, on every provider, returns identical, consistent results.

Ollama is the keystone. It's the provider we develop against, the default the platform boots on, and the path that runs chat and embeddings with nothing else configured. Pull a model from the Ollama library and you're running.

Ollama — the recommended default

Ollama is the default provider OpenAgentic is built around. It runs open-weight models locally, so you stand up the entire platform with no cloud account and no API keys:

Run it on Ollama alone

You run OpenAgentic end-to-end on Ollama — chat and embeddings — without any other provider:

# 1. Install Ollama (see https://ollama.com) and browse https://ollama.com/library
# 2. Pull an embedding model and a tool-capable chat model
ollama pull nomic-embed-text
ollama pull qwen2.5:7b

# 3. Point OpenAgentic at your local Ollama
OLLAMA_HOST=http://host.docker.internal:11434
OLLAMA_EMBED_MODEL=nomic-embed-text
OLLAMA_CHAT_MODEL=qwen2.5:7b

That’s it — no API key. The shipped docker-compose.yml even bundles an ollama container that pulls nomic-embed-text on first boot, so a bare install has working embeddings with nothing else configured. The zero-config --quick installer probes for a tool-capable model already on your host and pulls one if it finds none.

Chat models must be tool-capable. OpenAgentic always attaches tools, so a model with no tool support is rejected at boot (e.g. plain gemma3:1b → 400 — does not support tools). On Ollama the recognized tool-capable families are qwen, llama, gpt-oss, and mistral. Capability is auto-probed on startup. See Configuration.

Developed and tested on Ollama

Ollama isn’t a bolt-on. It’s the provider OpenAgentic is developed against day to day:

• Over 200 test files across the suite reference Ollama — unit, integration, and end-to-end (SmartModelRouter.spec.ts, providers.spec.ts, live model-discovery, and more).
• Ollama is the default embedding provider in the shipped docker-compose.yml (EMBEDDING_PROVIDER=ollama, OLLAMA_EMBED_MODEL=nomic-embed-text), with an ollama container and an init job that pulls the embed model on boot.
• The .env.example ships Ollama-first: nomic-embed-text set by default and the “no API keys” path called out.
• The Ollama project is the runtime behind all of it — pull from its model library and the model is available immediately.

_{These are facts about the OpenAgentic source, not a claim of official partnership or endorsement by Ollama. Ollama is our recommended provider.}

Built on a homelab, not a datacenter

We don’t develop this on a rack of H100s. The platform is built, day to day, on a small k3s cluster that anyone could stand up:

Ollama NVIDIA RTX 2080 ×2 · RTX 3090 k3s · Raspberry Pi

• Raspberry Pi (ARM64) workers run the stateless services, web, and control plane — proof the platform is genuinely multi-arch and frugal.
• A couple of commodity GPU boxes — 2× NVIDIA RTX 2080 and 1× RTX 3090 — run Ollama, serving the open-weight chat and embedding models (qwen2.5, llama3.1, gpt-oss, nomic-embed-text) to the whole cluster.

That’s it. Three gaming-grade GPUs and a handful of Pis host the entire platform — chat, flows, code mode, embeddings, the agent fleet — comfortably for development and small-team use. You do not need a DGX or a cloud account to be your own AI provider; you need hardware you can already buy, and Ollama.

And the ceiling keeps rising on hardware you own: the new class of on-prem AI machines — NVIDIA DGX Spark and RTX AI PCs — bring datacenter-class inference to a desktop box, so the same Ollama path scales from a homelab to a serious sovereign deployment without ever renting someone else’s models.

And we dogfood it: OpenAgentic is built with its own tooling — the coding agent (Gnomus Code), Claude Code, and the platform’s own Code Mode running the HITL-gated agentic SDLC — against Ollama on that same cluster. The thing that ships is the thing we run.

_{Hardware specifics describe our own development cluster. Scale GPU capacity for heavier concurrent or production workloads. NVIDIA and Ollama names refer to the respective products; no endorsement is implied.}

Also supported: every major cloud provider

When a task warrants a frontier model, OpenAgentic talks to your cloud providers directly, with the keys you cut — so every control you already have upstream stays yours.

OpenAgentic doesn’t proxy your models through a middleman service. You bring an API key (or a service account, or static credentials) cut directly from your cloud provider, and the platform consumes that provider on your behalf. The credential is the control plane — everything you’d normally configure upstream stays in force:

Future-proof by construction

Because OpenAgentic consumes each provider through that provider’s own latest SDK, anything a provider ships — a new model, a new modality, a new guardrail, a new flag — is reachable the moment it lands. There’s no waiting on a re-implementation of a provider’s API surface: you upgrade the SDK and the new capability is there. The same holds for Ollama — pull a new open-weight model and it’s available immediately.

The point isn’t lock-in to one provider — it’s the opposite. Start free and local on Ollama, reach for a frontier cloud model when a task warrants it, and mix both, all with the same level of control.

One canonical streaming format

Every provider streams differently — different event shapes, different field names, different tool-call and thinking semantics, different terminators. OpenAgentic normalizes all of it.

The openagentic-api wraps each provider’s SDK and runs the stream through a canonical map → reduce standardization layer:

The result: consistent results from any model or provider. A Flow built against a local Ollama model runs unchanged against a cloud model. Your code doesn’t branch on the provider. Streaming, tool use, and extended thinking behave identically whether the tokens came from Ollama on the box next to you, Bedrock, Vertex, or Azure.

Switching models is a config change, not a code change. That’s the whole point — start local on Ollama, scale to any provider, one consistent surface.