All reasons
Bring your own model

Your model. Your endpoint. Your cost curve.

The agent layer and the model layer are separate here. Point agent4.io at any OpenAI-compatible endpoint — a frontier API, a small open model on hardware you control, or several at once — without rebuilding a single agent.

Any OpenAI-compatible endpoint — hosted frontier model or self-hosted open weights
Several backends at once, weighted, with failover between them
Capabilities probed at startup, never hardcoded — small context windows are respected
Built for the specific ways small open models break on tool calls

The model is a setting, not an architecture

Most agent platforms are built against one model family and inherit its assumptions — its context window, its tool-calling format, its price. Swapping the model then means rebuilding the platform.

Here the model sits behind a gateway. Backends are rows in a table: a base URL, a key, a model name, a kind, a weight. Adding one is a configuration change, not a deployment. Your agents, prompts, knowledge bases and skills do not know or care which model answered.

That indirection is what makes everything else on this page possible — cost control, a model inside your own network, and mixing model tiers by job. It is one architectural decision doing four jobs.

Small open models break in specific ways

"Supports open models" is easy to say and usually means "the HTTP call succeeds." The failures show up later, in production, on the tool-calling path. Four of them are common enough that we build for them directly:

Tool calls arrive as text. Plenty of open models ignore the structured tool_calls field and write the call into the reply body instead, as XML or as JSON. Left alone, the user sees a wall of markup and nothing executes. agent4.io parses both forms, runs the tool, and strips the markup so it never reaches the end user.

Streamed tool calls arrive in fragments. OpenAI-compatible servers disagree on how to slice tool calls across streaming chunks. The fragments are reassembled by index before anything is executed.

Context windows are far smaller. A model with a 32K window cannot be driven like one with a million. The usable input budget is derived from the window actually probed at startup, minus the output reservation and a safety margin — not from a number hardcoded at build time.

Reasoning eats the answer. On models that think before answering, a naive output budget gets consumed by reasoning and the real answer is truncated. The budget is raised to account for it.

How this works in detail — the engineering, for the person on your team who will be asked whether this is real.

Route by job, not by vendor

Not every step needs the same model. Classification, extraction and routine replies behave well on a small model; the hard reasoning steps may not. Because backends carry a kind and a weight, you can run them side by side and put each job where it belongs.

The practical split is usually by consequence, not by difficulty: read-only and low-stakes work on the cheaper model, anything that writes or commits on the stronger one.

What this changes about cost

Token pricing is the objection that ends most agent projects — the pilot is cheap and the rollout is not. Separating the model from the platform gives you three levers instead of none: move high-volume, low-stakes traffic to a cheaper model, run open weights on hardware you already own, and keep the strong model for the work that earns it.

The point is not that open models are always the right answer. It is that the decision stays yours, and stays reversible.

Frequently asked

Can I use my own model with agent4.io instead of the default one?
Yes. agent4.io talks to any OpenAI-compatible endpoint, and the model backend is configuration rather than code. You can point it at a hosted frontier API, at an open model you run yourself on vLLM or Ollama, or at several backends at once. Your agents, knowledge bases and skills are unchanged when you switch.
Does agent4.io work with open-source models like Qwen?
Yes, and the compatibility work goes further than accepting the endpoint. Small open models routinely emit tool calls as plain text instead of structured fields, stream partial tool calls in fragments, and ship far smaller context windows than frontier models. agent4.io handles all three rather than assuming frontier-model behaviour.
What happens if a model does not support native function calling?
agent4.io also parses tool calls that arrive as text in the response body, in both the XML and JSON forms that open models commonly produce, and strips that markup so it never reaches the end user. A model without native function-calling support can still drive tools.
Can agent4.io run against a model inside my own network?
Yes. Because the model is reached over a plain OpenAI-compatible HTTP endpoint, that endpoint can be a server inside your own network with no route to the public internet. This is the usual arrangement where regulation or policy prevents customer data from reaching a third-party model provider.
If I bring my own model, am I still billed per token by agent4.io?
No. Token quotas apply to the inference agent4.io provides. When you supply your own endpoint, the inference cost is whatever your provider or your own hardware costs, and agent4.io is licensed separately. Talk to us about the arrangement that fits.
Can I use different models for different jobs?
Yes. Backends are registered per tenant with a kind and a weight, so chat and embedding can run on different models, and traffic can be split across several backends of the same kind. If one backend fails or is unreachable, agent4.io retries against the others before giving up.
See it working on your own knowledge base.Start freeTalk to us