A Model Is Half an Agent: AIHubMix for Models, Monid for Tools

Wire a model gateway like AIHubMix into your application and something satisfying happens. One integration, a change of base_url, and hundreds of models are suddenly reachable across text, image, speech and retrieval. Swap the model ID, get a different brain, keep the code.

Then you ask the agent for something it cannot know, and the illusion breaks. How many people work at this company right now. What is this competitor charging today. What did that TikTok account post yesterday. The agent either declines or invents, and a better model ID does not fix either response.

This is not a model quality problem. It is a missing integration, and it is the one almost nobody plans for.

Fair disclosure before we go further: you are on the Monid blog, Monid is the tool layer described below, and the section near the end names the cases where you do not need one. AIHubMix appears throughout as the model-side example because the two products sit on opposite halves of the same problem, not because they compete. Their developer docs cover the model half in more depth than this article will.

Your model is connected. Why can your agent still not do anything?

Because a model integration and a tool integration are different things, and only one of them is usually done.

A model gateway solves selection at the model layer. You stop hard-coding one provider and start choosing per request. What it does not do, and does not claim to do, is give the agent hands. The model can reason about a company's headcount beautifully. It cannot go and find out.

The usual response is to wire in one API by hand. That works exactly once. The second capability means another vendor, another signup, another key, another schema to learn, another invoice, and a rebuild the moment the task changes shape. Browse r/mcp on any given week and you can watch this happening in public: one server for social data, one for a knowledge base, one for search, each announced separately, each wrapping one vendor. The fragmentation is not a complaint anyone is filing. It is just the shape of the ecosystem.

The workaround people reach for first is to describe the tools in the system prompt. It fails in a specific way worth naming, because it fails quietly. The model happily produces a call that looks right, against a schema it half remembers, with a parameter name that was renamed two releases ago. Nothing errors. You get a plausible payload, a 400 from the provider, and an agent that reports the task as done. A broken integration that throws is a Tuesday afternoon. A broken integration that returns confident nonsense is the class of bug that survives to production, and it is the reason the schema has to be read at run time rather than remembered at training time.

Which is a familiar shape. It is the same problem model gateways were built to solve, moved one layer over.

What does an agent actually need besides a model?

A catalogue it can search at run time, and a way to pay for one call without a contract.

Those two requirements sound modest and they rule out most of the obvious answers. A list of tools handed to the agent at build time fails the first, because the agent can only use what you predicted it would need. A vendor account per capability fails the second, because signing up is a human action and the agent is mid-task.

The symmetry with the model side is exact enough to be worth putting in a table.

Read the middle rows again, because that is the actual argument. Both layers move a decision that used to happen in your code, at build time, into the moment the request runs. That is the whole idea in both cases. An agent that picks its model per request and its tool per task is a different kind of program from one that was handed both.

Monid is the OpenRouter for agent tools: one key and one balance reach over a thousand tools across many providers, billed per call, with no separate signup per vendor. The agent searches the catalogue in plain language, reads a schema and a price before it commits, and then calls. If you want the mechanics rather than the pitch, how it works is the short version.

How do you connect the model side?

Point the SDK you already use at the gateway and pick a model ID.

We are not going to re-document someone else's product. AIHubMix keeps the OpenAI calling pattern, so the change is the base_url and the key:

from openai import OpenAI

client = OpenAI(
    api_key="<your-aihubmix-key>",
    base_url="https://aihubmix.com/v1",
)

response = client.chat.completions.create(
    model="auto",
    messages=[{"role": "user", "content": "..."}],
)

The detail worth noticing for agent work is model="auto". Instead of naming a model, you let AIHubMix read the request and pick one, and routing itself is not billed. Their Claude Code setup page covers the same thing for an agent runtime rather than a script.

That matters more for an agent than for a chatbot, because a single agent run is not a single kind of work. Deciding which tool to call is a cheap classification. Reading a page of scraped JSON and turning it into a paragraph is a summarisation. Writing the final brief is the part a reader will judge. A chatbot can pick one model for all three and accept the compromise. An agent making dozens of calls per task pays for that compromise dozens of times, which is why the routing variants matter: bias toward latency on the mechanical steps, toward quality on the one that gets read. AIHubMix exposes those as auto:balanced, auto:quality_first and auto:latency_critical.

Note what has and has not happened. Your agent can now think using any of hundreds of models, and pick a different one per step. It still has no way to look anything up.

How do I set up Monid with Claude or another AI agent?

One line, and the agent learns the rest itself.

For agents

Grab an API key at app.monid.ai, then paste this to your agent and hand it the key:

set up https://monid.ai/SKILL.md

It reads the file and learns the whole discover, inspect, run workflow without further instruction. More detail in the agent quickstart.

For humans

npm install -g @monid-ai/cli
monid keys add --label main --key <your-api-key>

More detail in the CLI quickstart. There is also a remote MCP server if your runtime speaks MCP, which is what most agent frameworks want.

The asymmetry between the two setups is not an accident. The model side needs a config change because a human writes the config. The tool side needs a document the agent can read, because the agent is the one doing the choosing.

What does it look like when both layers are wired?

The agent picks a tool it was never told about. Here is the sequence, run by hand so you can see each step.

Step one: find something that can answer the question. Discovery is free, so the agent can afford to look before it commits.

monid discover -q "company profile and funding by domain"

It comes back with ranked endpoints, each with its provider, a description, a price and a verified flag. Nobody had to know in advance which provider covers company data.

That result set is written for a reader who is not a person. Each row carries the provider slug and endpoint path the next command needs, the billing shape rather than a marketing description, and a flag saying whether the endpoint has been tested. An agent can rank those rows against its own constraints, prefer a verified endpoint that bills per call over an unverified one that bills per result, and act on the answer without asking anyone. That is the difference between a catalogue and a directory: a directory is a page a human reads, a catalogue is a response an agent can branch on.

Step two: read the contract before signing it. Also free.

monid inspect -p pdl -e /v5/company/enrich

You get the input schema, the pricing shape and the docs. This is the step that stops an agent calling something expensive by accident, and it is why the price appears before the call rather than on an invoice afterwards.

Step three: call it. This is the only step that costs anything.

monid run -p pdl -e /v5/company/enrich \
  --query '{"website": "aihubmix.com"}'

Step four: the model does the part it is good at. The tool returned facts, not prose. The completion goes back through AIHubMix, where auto:quality_first is the sensible setting for the step whose output a human reads, and comes back as the brief you actually asked for.

In code, the two halves meet in about a dozen lines. The tool result is just context, and the AIHubMix client is the same one from earlier in this post:

from openai import OpenAI

client = OpenAI(
    api_key="<your-aihubmix-key>",
    base_url="https://aihubmix.com/v1",
)

# `facts` is the JSON your agent got back from the Monid run above
brief = client.chat.completions.create(
    model="auto:quality_first",
    messages=[
        {"role": "system", "content": "Write a two sentence brief. Cite only what is in the data."},
        {"role": "user", "content": str(facts)},
    ],
)

Four steps, two vendors, and at no point did anyone hard-code which model or which provider. That is the whole arrangement.

The moment that matters is step one. The agent needed company data, searched for it, and found a provider nobody had wired in. Add live web results, social data or transcripts to the same agent and none of it requires a new account. If web context is the specific job you have, give your agent live web context walks through that one end to end, and the best web search API for AI agents compares the options for it.

What does each layer cost?

Different units, and the difference matters more than either number.

Model calls bill per token. Tool calls bill per call or per result, depending on the endpoint, and the shape is visible in inspect before you run anything. Both layers make the choosing free: AIHubMix does not bill for routing, and discover and inspect cost nothing on ours. You pay for completions and for calls, not for having access to either catalogue.

The practical consequence is that the two bills answer different questions. A model bill tells you how much your agent thought. A tool bill tells you how much it went and found out. When a run costs more than expected, that split is the first thing worth looking at, because the fix is different in each case: a cheaper routing variant on one side, a more precise query or a per-call rather than per-result endpoint on the other.

That last point is the one that changes architecture. Because access costs nothing until it is used, an agent can carry the entire catalogue and still only pay for the handful of calls it makes. You are not buying a seat, a plan or a monthly minimum on either side. Current prices for every tool are on monid.ai/tools, which stays accurate in a way a sentence in a blog post does not.

If you are weighing this against a per-seat data subscription, pay per call versus subscription works through when each one wins, and subscriptions do win sometimes.

When do you not need a tool layer?

When the agent only ever calls one API, and you already know which.

A pipeline that fetches from one endpoint on a schedule should call that endpoint. Adding a layer in front of a single known dependency buys you nothing and costs you a hop. The same goes for anything with a hard compliance requirement about which vendor processes the data, where the point is that the choice is fixed and not the agent's to make.

There is a subtler case. If your agent's tool use is narrow and completely predictable, a single-vendor MCP server is simpler to reason about, and simpler is worth real money in production. Which MCP server gives an agent live web data works through that trade in more depth, and it does not conclude that the catalogue always wins.

The symmetric caveat holds on the model side too, and AIHubMix would tell you the same thing: if your workload is one prompt shape against one model you have already benchmarked, routing is solving a problem you do not have. Both layers are answers to variety. Neither is an answer to a pipeline that does the same thing every time.

The tool layer earns its place when you cannot list in advance everything the agent will need. That is a description of most agents people are actually trying to ship, but it is not a description of all of them.

FAQ

Last updated August 2026.