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
| Provider | Execution | Configured model | Private tier | Status |
|---|---|---|---|---|
| OpenAI | Hosted API | gpt-4o-mini | Gated out | Implemented |
| Anthropic | Hosted API | claude-opus-4-8 | Gated out | Implemented |
| Groq | Hosted API — open models | llama-3.3-70b-versatile | Gated out | Implemented |
| Private / self-hosted | Self-hosted — Ollama | llama3.2 | Eligible | Implemented |
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
openaiHosted 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
anthropicHosted 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
groqHosted 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
ollamaSelf-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 needsWhich 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