Skip to content

Providers

Four routes, each one a different decision.

Provider support is deliberately selective. Each of these is here because it represents a genuinely different routing alternative — a different cost curve, latency profile, context ceiling or trust boundary. Adding a provider strictly dominated by one already supported would lengthen the list without giving the router a new decision to make.

At a glance

ProviderExecutionConfigured modelPrivate tierStatus
OpenAIHosted APIgpt-4o-miniGated outImplemented
AnthropicHosted APIclaude-opus-4-8Gated outImplemented
GroqHosted API — open modelsllama-3.3-70b-versatileGated outImplemented
Private / self-hostedSelf-hosted — Ollamallama3.2EligibleImplemented

Each provider runs one configured model per deployment, selected by environment variable; the defaults are shown above. Waymesh does not claim support for every model a provider offers, and the routing engine treats the configured model’s real capabilities — context window in particular — as a hard eligibility gate.

Provider detail

OpenAI

openai

Hosted API

OPENAI_MODEL
default: gpt-4o-mini

Use case
Broad commercial model ecosystem. The widest spread of model sizes behind one integration, which makes it the route most likely to have something that fits an unusual requirement.
Privacy characteristics
Third-party execution. Requests leave your infrastructure, so workloads on the private tier are gated out of this route before scoring.
Availability requirements
  • OPENAI_API_KEY
  • Reachable api.openai.com
  • Health check lists models
Integration status
Implemented — real adapter, live pricing, health check
  • One configured model per deployment, not the full OpenAI catalogue
  • Text analysis task type only

Anthropic

anthropic

Hosted API

ANTHROPIC_MODEL
default: claude-opus-4-8

Use case
An independent frontier route. A capability or availability problem at one vendor does not remove the whole top tier at once, which is most of the argument for having two.
Privacy characteristics
Third-party execution. Same gating as any hosted API: ineligible for workloads whose policy forbids external egress.
Availability requirements
  • ANTHROPIC_API_KEY
  • Reachable api.anthropic.com
  • Health check lists models
Integration status
Implemented — real adapter, live pricing, health check
  • One configured model per deployment
  • Text analysis task type only

Groq

groq

Hosted API — open models

GROQ_MODEL
default: llama-3.3-70b-versatile

Use case
A high-speed inference option. An order-of-magnitude lower latency and cost for work that does not need a frontier model, which is what makes high-volume routing worth doing at all.
Privacy characteristics
Third-party execution. Ineligible for private-tier workloads on the same basis as the other hosted routes.
Availability requirements
  • GROQ_API_KEY
  • Reachable api.groq.com
  • Health check lists models
Integration status
Implemented — real adapter, live pricing, health check
  • One configured open model per deployment
  • Smaller context window than the frontier routes — a real exclusion reason, not a footnote
  • Text analysis task type only

Private / self-hosted

ollama

Self-hosted — Ollama

OLLAMA_MODEL
default: llama3.2

Use case
Execution on infrastructure you control, so a workload whose policy forbids third-party egress has a legal route rather than no route.
Privacy characteristics
Prompts stay on your endpoint. The adapter refuses a remote plaintext HTTP endpoint outright — sending prompts in the clear would contradict the private tier it exists to serve — unless that refusal is explicitly overridden.
Availability requirements
  • OLLAMA_BASE_URL reachable from the worker
  • Local, private-network or HTTPS endpoint
  • Health check lists models
Integration status
Implemented — real adapter, endpoint safety classification, health check
  • One configured model per deployment
  • Throughput and latency are whatever your hardware provides
  • Text analysis task type only

Roadmap

Provider roadmap is driven by customer workload demand.

New providers are added when a real workload needs a routing alternative the current set cannot offer — a context ceiling, a latency floor, a modality, a residency requirement. That is a better reason than coverage for its own sake, and it is the reason design partners have outsized influence over what lands next.

No dates are published for integrations that are not committed. A provider appears on this page when its adapter exists in the repository and has been exercised, not when it has been planned.

Waymesh is independent of every provider it routes to and is not affiliated with, endorsed by or partnered with any of them. Provider names appear here to describe compatibility only.

Tell us which route your workload needs

Which of these routes is right for a given workload is a measurement, not an opinion. Shadow mode makes it one against your own traffic.

Apply for Design Partner Access