Models & Compute

Choose by capability.
Adapt to availability.

The runtime layer is provider-neutral. Cloud services remain primary, optional Ollama models can participate where deployed, and user-controlled GPU endpoints can register as compatible runtimes without making Agent Forge itself GPU-dependent.

See Runtime Lanes →Platform Architecture
The Arsenal

Models change.
The routing contract remains.

The fleet is discovered from configured providers and compatible runtimes. The website does not promise a fixed model count or permanent roster. Three logical core slots organize primary work; a broader pool can support agents, subtasks, and fallback candidates.

OPTIONAL — USER RUNTIMEExternal compute
A user-controlled compatible endpoint can be registered through authenticated runtime APIs and kept current with heartbeats. It is not required for normal platform startup.
Active only while registered and healthy ↓
Compatible model server
Inference endpoint controlled by the user
Interface Compatible HTTP API
Auth Registration required
Availability User managed
External GPU compute
Colab · RunPod · Vast.ai · local hardware
Compute Outside Cloudflare
Use Inference or training
Control User owned
CORE — CONFIGURED CLOUDPrimary lanes
Three logical slots organize primary work: a fixed owner-selected anchor, a trusted lane, and a canary lane. Actual models are discovered live and can vary by account and provider.
3 logical slots ↓
Anchor slot
Fixed by owner choice
Model Live discovered
Role Owner anchor
Change Owner controlled
Trusted slot
Evidence-backed primary candidate
Model Live discovered
Role Trusted lane
Change Evidence aware
Canary slot
Bounded exploration candidate
Model Live discovered
Role Exploration lane
Guard Policy bounded
POOL — CONFIGURED PROVIDERSAgents + subtasks
The wider pool is assembled from providers with valid credentials, reachable endpoints, compatible models, and usable limits. Its size and roster change with live discovery.
Parallel dispatch ↓
Groq
Configured API models
Models Live discovered
Limits Tracked at runtime
Use Eligibility based
OpenRouter
Configured API models
Models Live discovered
Limits Provider specific
Use Eligibility based
Gemini
Configured API models
Models Configuration based
Limits Provider specific
Use Capability based
Ollama Cloud
API-key connected cloud models
Models Account list
Auth API key
Use Core or pool
Additional providers
Optional configured adapters
Examples Anthropic + compatible
Auth Explicit keys
Use Capability based
Dynamic roster
No fixed public model count
Source Live discovery
Rank Evidence aware
OPTIONAL — LOCAL RUNTIMEConfiguration based
A local Ollama-compatible runtime can participate when explicitly configured and reachable. It is not required by the production cloud-first deployment and is not guaranteed to be present.
Emergency fallback ↓
Local compatible model
Optional fallback or specialist
Model User selected
Health Runtime checked
Required No
Model Components

Provider-neutral routing.
Replaceable model components.

Agent Forge can use hosted APIs, Ollama-backed cloud or local models, and user-owned compatible endpoints. Open-weight components may support embeddings or classification, but the platform is not limited to Hugging Face models.

Embedding interface
Semantic retrieval component
The vector layer checks its active embedder and index configuration at runtime. BGE-M3 is supported by the codebase, but availability and dimensions must match the deployed index.
Runtime status · Atlas-compatible vectors
Task classification
Classifier behind a stable contract
Routing consumes task and capability signals through an internal interface. The deployed classifier can change without changing the public workflow, and diagnostics report whether it is ready.
Replaceable · Health reported
Training utilities
Operator-controlled exports and jobs
The platform exposes training-status and export surfaces. That does not mean a model is automatically trained, published, or updated from every conversation.
Explicit workflow · No automatic weight changes
Model registry
Discovered, not hardcoded
Provider model lists, compatible endpoints, owner choices, and routing evidence determine the active roster. Website examples are never treated as live inventory.
Provider discovery · Account specific
Model-neutral architecture
Provider adapters and runtime registration keep routing logic separate from any single model vendor. A compatible model still needs credentials, health, and capability metadata before it can receive work.
Credentials are explicit
Each optional provider or model source uses its own configured credential. No API key is embedded in the page, exposed to the browser, or promised to exist for every deployment.
server-side secrets → provider adapters → discovered models
Training boundary
Feedback and routing records can be reviewed or exported by an authorized operator. They are not a claim of automatic fine-tuning, collective training, or publication of user data.
GPU Infrastructure

A connected GPU
becomes a routing tier.

A user-owned GPU runtime can participate through an authenticated compatible endpoint. Registration, credentials, model metadata, reachability, and ongoing heartbeats are required. GPU connectivity is independent of the normal cloud-first path.

Authenticated Runtime Registration
Connect an endpoint you control
Colab, RunPod, Vast.ai, local hardware, or another compatible host can expose a model endpoint. The runtime must be registered through the protected API with the required metadata.
Authentication · Metadata · Reachability
Runtime Heartbeat
Availability is continuously qualified
Registered runtimes send heartbeats so stale or disconnected endpoints are not represented as permanently online. A reachable endpoint can still be excluded by policy, capability, or limit checks.
Health · Expiry · Eligibility
Routing Evidence
Same eligibility discipline
User runtimes join the same capability, health, limit, latency, quality, and exploration checks as other candidates. Local ownership alone does not guarantee selection.
Capability · Health · Limits · Evidence
What's available today
Authenticated runtime registration and heartbeat endpoints exist. GPU availability depends on a user actually running and exposing compatible compute; the production platform does not require one to start.
Compute stays external
Cloudflare proxies the Agent Forge web application; it does not run Python, Ollama, training jobs, or user GPUs. External compute remains on the host chosen and controlled by the user.