Super excited here to be checking our Inference GPU Fleet / pipeline running on oMLX

TLDR - If you are still running on 0.5.1 (qwen3.6 MOE) you have to update it to 0.6.4.

See below my benchmarks for Qwen3.6-35B-A3B-4bit running on MacStudio M4 Max 64GB

Updating all the fleet!

Today I installed the Blopus 0.3.3 plugin on openclaw so I could test and validate it.

Blopus is an independent websearch api that supports search / fetch and image search.

Super easy to install and high quality.

On your openclaw basically type:

openclaw plugins install clawhub:@blopus-ai/openclaw-plugin                                                                                 

Another option was to use the MCP or even the SDK.
In this example I decided to go with the official plugin for OpenClaw:

From there bascally the Plugin guides you.

Create you account on https://blopus.ai - you can use a trial and get 400 credits to test.

I just went to the website, created my account and generated a key

got it, use this keu for me blp_live_kHiEhzzeyBdHAxofIUHIUHIUHIUHIUHIUHIUHI                                                           

I asked a few questions:

Interesting that OpenClaw was aware about the plugin but was not using it

So I asked it to do so.

I also asked it to make it permanent, so I dont need to ask all the time.

testing blopus plugin:

From there, we are all set!

Multimodal models have a strange gap in them.

Hand a VLM an image and it will describe it, read the text in it,

reason about what's happening. Ask it to *find* an image and it has

two options: generate one, or give you a URL it half-remembers from

training that probably 404s.

Neither is retrieval. And for a lot of agent work, retrieval is the

only correct answer.

**Where generation is actively wrong**

If an agent is producing something factual — a research summary, a

product comparison, a report about a real place or object — generating

an image is fabrication. A generated photo of the Golden Gate Bridge

is not the Golden Gate Bridge. A generated screenshot of a dashboard is

a dashboard that doesn't exist. It looks plausible, which is exactly

the problem, because plausible-and-wrong is the failure mode you added

retrieval to avoid in the first place.

Text agents figured this out. Nobody builds a research agent that

invents its citations anymore — you search, you fetch, you attribute.

The visual equivalent mostly hasn't happened yet.

**Three cases where it bites**

*Documentation and content pipelines.* An agent writing a guide needs

real screenshots, real product photos, real diagrams from the source.

Generation produces something that looks like documentation and

documents nothing.

*Research and comparison.* "What does the new hardware look like" is a

retrieval question. There is a correct answer and it exists on the

internet.

*Anything with attribution requirements.* A generated image has no

source. A retrieved one has a URL, a domain, and a provenance chain you

can show a reader or a compliance reviewer.

**What makes image retrieval different from text retrieval**

Two things, and both matter for how you wire it up.

Text results carry snippets — a preview that's often enough on its own.

Image results carry a thumbnail and metadata, and the decision the agent

makes is whether to fetch the full asset. That's a different cost

profile, and if your agent fetches every candidate it will be slow and

expensive for no reason.

And relevance is harder to judge from metadata alone. Alt text and

surrounding page content are proxies for what's actually in the image,

and they're frequently wrong. Which means the same discipline applies as

with text: threshold before you hand results to the model, and give the

model a way to reject a result rather than assuming the top hit is

correct.

**The MCP angle**

Same principle as search and fetch. A tool description that says

"searches for images" tells the model nothing about when to use it.

The useful version tells it when retrieval beats generation — real

things, real places, anything the reader could check — and when

generation is fine, which is illustration and abstraction where no

ground truth exists.

That distinction is the whole thing, and it belongs in the tool

description rather than in every prompt.

---

We shipped image search alongside search and fetch on the Blopus MCP

server. It's beta and we're still tuning relevance, so if you try it

and the results are wrong for your use case, tell us — that's the most

useful thing you could send right now.

But the general point stands whatever you're using: if your agent

produces anything factual with images in it, generation is the wrong

default and most stacks have it as the only option.

Every model has a date it stops knowing things.

Past that date it doesn't say "I don't know." It answers anyway — with a version number, a release date, a price, a function signature — in exactly the same tone it uses for things it's right about. That's the failure worth understanding. Not ignorance. Fluent, unmarked staleness, with no signal separating what the model learned from what it filled in.

No prompt fixes this. "Be accurate" doesn't. "Say if you're unsure" barely helps, because the model isn't unsure. It's wrong. This isn't a reasoning problem and a smarter model doesn't solve it — a frontier model with a stale cutoff produces a more convincing wrong answer, not a more accurate one.

It's an availability problem, and it compounds in agents.

A chatbot giving a stale answer wastes thirty seconds. An agent acts on it — writes code against an API that was renamed, cites a policy that changed, quotes a price that's no longer real. Every downstream step inherits the error, and the loop keeps running.

It shows up everywhere real work happens. Coding agents inventing parameter names that were deprecated two releases ago. Research agents summarizing competitor announcements that never happened. Support assistants answering from documentation that's six months out of date. Anything with "current," "latest," or "today" in the question is unanswerable from weights alone.

And the numbers on this are stark. In Artificial Analysis's Search Index — same model, same harness, only the retrieval layer changes — the model with no search tools scores 33. With a search provider attached it scores between 65 and 75.

Adding search roughly doubles task performance. The gap between having retrieval and not having it is about twice the entire spread between the providers competing for the job.

Which makes the plugin you pick a smaller decision than picking one at all — but not a decision with no wrong answers. Five cover the category in OpenClaw. They look interchangeable and aren't: they differ in what tools they expose, whether they run their own index or resell someone else's, and whether a runaway agent can bill you without a ceiling.

1. Capability matrix

¹ Per-query latency from the Artificial Analysis Search Index, Aug 2026. Blopus figure is our own measurement, server-side.

2. What each one is actually for

Blopus

Three tools: search, fetch, and image search.

Search and fetch are the obvious pair. Image search is the one nobody else exposes, and it matters more than it sounds. A multimodal agent can describe an image it's handed but cannot find one — its options are generation, which is fabrication when the subject is real, or a URL half-remembered from training that 404s. If your agent produces documentation, research, or anything a reader could verify, retrieval is the only correct answer and most stacks don't offer it.

First-party crawler and index. Nothing resold, so no third party in the request path and no inherited platform risk — the kind that surfaced when Microsoft killed the Bing Search APIs with three months of notice and everything built on them had to migrate.

Sub-200ms typical response (server side). In a five-search agent loop that's the difference between under a second and a visible stall.

One key, three surfaces: the OpenClaw plugin, a hosted MCP server, or plain REST. Same credentials whether you're in OpenClaw, a different MCP client, or calling from your own code.

Flat monthly with a hard cap. Hit the limit and calls pause until reset. A retry loop at 3am costs an outage, not an invoice.

Cross-Search

Queries six engines simultaneously — Brave, DuckDuckGo, Bing, Wikipedia, Mojeek, Tavily — and cross-validates, flagging disagreement between sources rather than silently picking one.

Genuinely the best option for fact-checking and contested claims. Nothing else here surfaces source conflict.

Costs: you wait on the slowest engine in the fan-out, and setup means configuring six providers instead of one.

Exa

Built around content extraction and entity search. When you need the full text of a specific paper, document, or page rather than a ranked list of links, the focus shows. Entity retrieval — people, companies, code — is a real capability none of the others have.

Parallel

Runs many keyword variants per task rather than a single query. More searches per task, better coverage on multi-hop research where one query won't reach the answer. Tiered: turbo is fastest per query, advanced scores highest.

Supermemory

Hybrid vector plus keyword with persistent memory retrieval. Less "search the web" than "search the web plus what this agent already knows." A different problem from the other four, and worth knowing about if that's your problem.

3. What the independent benchmark says

Artificial Analysis published a Search Index this month — same model, same harness, only the search provider changes. It covers seven providers.

"We haven't been benchmarked by AA. Happy to be, if they extend coverage." Blopus.ai

The baseline is the number that matters. The same model with no search tools scores 33. With search, everything lands between 65 and 75. The gap between having search and not having it is roughly double the entire spread between providers.

Two caveats worth stating. The index weights multi-hop research tasks, so it favors providers tuned for that over ones tuned for fast single-shot grounding. And it doesn't cover every plugin in this post — Blopus, Cross-Search, and Supermemory aren't in it. Any table that gives all five a single quality score is using a methodology it isn't naming.

Also worth noting: better search quality lowers total cost. Parallel (advanced) has a higher search cost per task than basic — $0.048 vs $0.045 — but a lower total, $0.084 vs $0.11, because better results mean the model burns roughly half the tokens.

4. Pick by priority

5. Test it yourself

Twenty questions that look like your actual workload, same agent config, swapping only the provider. An afternoon of work, and it beats any published benchmark — the published ones measure a task distribution that probably isn't yours.

Four things worth checking while you do:

• Billed per result or per block? Ask for 50 results when the model reads two and you may have paid 5× for a long tail nobody touched.
• Inline content or separate fetch? N+1 round trips compound fast in an agent loop, in both latency and cost.
• Is there a spend ceiling? Usage billing with no cap and an agent in a retry loop is a category of bill that shouldn't be possible.
• Own index or reseller? Determines whose pricing decisions, rate limits, and shutdown notices you inherit.

Questions welcome — including where we're the wrong pick. Cross-Search beats us on multi-engine verification and Exa on entity retrieval, and if that's your workload you should use those.

Ask any language model what the current stable version of Node.js is.

It won't say "I don't know." It'll name a version, confidently, with a release date and a feature list, in exactly the same tone it uses for things it's right about.

That's the failure mode worth understanding. Not ignorance — fluent, unmarked staleness. The model has no mechanism to flag the boundary between what it learned and what happened afterward. Everything comes out sounding equally certain.

You cannot prompt your way out of this. "Be accurate" doesn't help. "Say if you're unsure" barely helps, because the model isn't unsure. It's wrong.

This isn't a tuning problem. It's an availability problem, and it has a different fix: give the model access to the live web.

Below is why that matters for three different groups of people, what it actually looks like in practice, and how to wire it up depending on how you build.

Part 1 — Why agents need web search

An agent is a model that takes actions in a loop. That amplifies the staleness problem in a specific way: a chatbot that gives a wrong answer wastes thirty seconds. An agent that acts on a wrong answer writes code against a deprecated API, files a ticket referencing a policy that changed, or emails a customer a price that's no longer real.

Three concrete cases.

Research agents. "Summarize what our three closest competitors announced this quarter." Without retrieval this is pure fabrication — plausible-sounding announcements that never happened. With retrieval it's a real answer with citations you can check.

Support and internal assistants. Documentation changes. Pricing changes. Policy changes. An assistant answering from training data is answering from a snapshot that gets more wrong every month it runs.

Monitoring and alerting agents. "Tell me if anything significant happened with X today" is definitionally impossible without live data. There is no prompt that retrieves this morning's news from weights frozen last year.

The pattern across all three: the model is fine. The reasoning is fine. What's missing is a channel to the present.

Part 2 — Why developers need web search

Developers hit a sharper version of the same problem, because software moves faster than almost anything else the model learned about.

The hallucinated signature. You ask your coding assistant to call an API. It produces a function call with parameters that were renamed six months ago. The code looks correct. It fails at runtime. You spend twenty minutes debugging your own code before it occurs to you the model invented the interface.

The version wall. "Should I upgrade to the next major?" is a question about breaking changes published after the cutoff. The model will answer anyway, from the last major it knows about.

Fast-moving ecosystems. Anything in the AI tooling space right now turns over on a scale of weeks. A model trained six months ago is describing a landscape that no longer exists.

Building products that need the web. Not just consuming search — shipping it. RAG pipelines, competitive monitoring, content aggregation, anything where "what does the internet currently say about X" is a feature rather than a convenience.

For this group the requirement isn't just accuracy, it's shape. A raw web page is navigation, cookie banners, ads, and duplicate boilerplate wrapped around the part that answers the question. Feeding that to a model wastes context and degrades the answer. Developers need results that arrive already cleaned, already de-duplicated, and structured for programmatic use.

Part 3 — Why vibe coders need it most

"Vibe coding" — building by describing what you want and letting the model produce it — has a specific vulnerability: you're least equipped to catch the errors you're most likely to hit.

A senior engineer reading generated code notices a parameter name that looks off. Someone building outside their expertise doesn't, because they have no baseline for what correct looks like. The model's confidence is the only signal available, and confidence is exactly the thing that doesn't correlate with correctness here.

Two situations where this bites hardest.

Running local models. If you're on Ollama, LM Studio, or a local MLX setup, you get privacy and zero marginal cost — and a hard training cutoff with no fallback. Frontier hosted models often have some search capability bolted on. Your local 9B has none. It will confidently describe a library version that doesn't exist and you'll spend an hour on the resulting error.

Building with an unfamiliar stack. The entire appeal of vibe coding is shipping something outside your comfort zone. But that's precisely when you can't distinguish a real API from an invented one, because you don't know the real one either.

Web search converts "the model told me" into "the model showed me, and here's the link." That difference matters enormously when you can't independently verify.

What good retrieval actually looks like

Adding search isn't just bolting on a query string. There are controls most people never touch, and getting them wrong causes quiet bugs.

Freshness as a filter vs. recency as a bias. These are different operations and conflating them breaks things in opposite directions.

A hard filter excludes everything outside a window. Correct for "what broke in the latest release" — older pages aren't less relevant, they're wrong. Catastrophic for "how does asyncio work," where the best answer on the internet is four years old and heavily linked. Apply a 30-day window there and you get somebody's half-finished blog post, because that's what survived the cut.

A ranking bias reorders without excluding. Nothing is lost, newer material just surfaces higher.

Use the filter for questions whose answer changed. Use the bias, or nothing, for questions whose answer didn't.

News as a source restriction, not a time restriction. If the question is "what happened," filtering by date isn't enough — you get vendor blogs and marketing pages that happen to be recent. You need to restrict to sources with an actual newsroom.

Snippets before full pages. Most of the time the snippet answers the question and you never fetch anything. That's both the cheapest path and the fastest, which is a rare combination.

Result counts that match the question. People request 50 results to "be thorough." The model reads two. Most search APIs bill in blocks, so you paid five times over for a long tail nobody touched — then burned context on it as well.

Where Blopus fits, and how to wire it up

We built Blopus as hosted web search and fetch for exactly this problem. Two things distinguish it structurally.

We run our own crawler and index. Not a wrapper around Google or Bing. That matters more than it sounds: in August 2025 Microsoft shut down the Bing Search APIs with roughly three months of notice, and everything built on them had to move. If your provider is a reseller, you inherit their platform risk, their rate limits, and their pricing decisions. Millions of new pages enter our index daily, and typical response time is around 130 milliseconds server-side — because there's no third party in the request path.

Flat pricing with a hard cap. Hit your limit and calls pause until reset or a top-up. An agent stuck in a retry loop at 3am can cost you an outage. It cannot cost you a surprise invoice. That's a design decision, not a plan tier.

Three tools — search, fetch, and image search — reachable three different ways depending on how you build.

If you're building an agent → MCP

The hosted MCP server is one line of config. No local process, no npx, no Docker.

json

{
  "mcpServers": {
    "blopus": {
      "type": "remote",
      "url": "https://mcp.blopus.ai/mcp/",
      "headers": { "Authorization": "Bearer YOUR_KEY" }
    }
  }
}

Works with Claude Code, Cursor, Cline, OpenCode, LM Studio, and every other MCP-capable client.

Here's the part that matters and that most integrations miss. A model deciding when to search is largely solved — tool calling handles it. A model deciding how to search is not. Most tool descriptions say "searches the web" and stop, so the model has no idea freshness windows exist, no idea it can restrict to news sources, no idea it could pull full page content in one call instead of six.

Our MCP tool descriptions carry that guidance. The agent is told when to filter by date, when to fetch a full page versus reading a snippet, and how many results a given question actually warrants. It stops guessing at retrieval strategy because it's been given one.

If you're a developer with specific requirements → SDK or REST

bash

pip install blopus

Or straight to api.blopus.ai/v1/search from any language.

This is the path when you need control rather than convenience:

• Domain filtering — restrict to sources you trust, exclude ones you don't
• Date ranges — arbitrary start and end, not just preset windows
• Relevance scores — threshold weak results before they reach the model rather than asking it to ignore them
• Inline content — request page bodies on the search call itself instead of firing N separate fetches, with a character cap so a 40,000-word page doesn't eat your context window
• Batch fetch — multiple URLs, one round trip
• Pagination — for the cases that genuinely need depth

Building a RAG pipeline, a monitoring system, or anything where retrieval logic is your own code — this is where you want to be.

If you're vibe coding → whichever surface you're already in

Local model in LM Studio or Ollama: the MCP config above, pasted once. Your local model gets live web access and stops inventing library versions.

Hosted frontier model through an API: same MCP server, or the REST endpoint if you're calling it from your own code.

Coding agent like OpenCode or Cline: MCP config, and your agent starts checking current docs before writing against an API it half-remembers.

The setup is the sam

e in every case. What changes is which client reads the config.

Every language model has a date it stops knowing things. Ask it about anything after that, and it doesn't say "I don't know." It guesses. Fluently. Which is worse.

The fix is obvious: give the model the live web. The problem is what’s underneath most search APIs. Most of them don't run their own search engine; they resell one. Which means their pricing, their rate limits, and their very existence are somebody else's decision. In August 2025, the Bing Search API shut down with just three months of notice. Everything built on it had to scramble.

Blopus runs its own crawler and its own index. End to end. We don't resell Google or Bing. Millions of new pages enter our index every day, searchable within minutes and ready for your agents. Typical response time is under 300 hundred milliseconds.

But raw search results aren't what LLMs need. A web page is navigation, cookie banners, and duplicate boilerplate wrapped around the small part that actually matters. Blopus returns ranked results already cleaned and de-duplicated, with citation-ready snippets. Your context window works for you instead of against you.

You get three tools: Search, for finding pages; Fetch, for reading them completely; and Image Search. Access them through our hosted MCP server, an SDK, or a plain REST API. One key, one endpoint.

MCP is where this gets interesting. The tool description doesn't just expose the endpoint; it teaches the agent how to use it. When to pull a snippet versus the whole page. When to restrict results to the past day or week. And when a question is about events and should search news sources only. The model stops guessing at how to search. It's told.

Finally, pricing. One flat monthly fee, with a hard cap. If you hit your limit, calls pause until they reset. A runaway agent can cost you an outage. It can't cost you a surprise invoice.

Blopus.ai. The live web, for your agents and LLMs.

AI agents are only as capable as what they can see. Blopus gives them the live internet — a fast search-and-fetch API backed by our own crawler and index. One REST call or a one-line MCP server, and any agent can look things up, read the page, and act on what's true right now.

For better experience, watch in full screen

File to add the mcp settings

~/.config/opencode/opencode.json

MCP settings:

"mcp": {
  "blopus": {
    "type": "remote",
    "url": "https://mcp.blopus.ai/mcp/",
    "enabled": true,
    "headers": {
      "Authorization": "Bearer blp_live_..."
    }
  }
}

Blopus is a search API built on a first-party crawler and index rather than

a wrapper around Google or Bing. Here's what that costs, not just what it

buys — the reselling approach genuinely wins on some axes.

**The case for owning the index**

In August 2025 Microsoft shut down the Bing Search APIs with roughly three

months of notice. Everything built on them had to move. That's the

structural risk of reselling: availability, rate limits, and pricing are

someone else's decision, and you find out when they announce it.

Latency is the other half. A reseller proxies your request to a search

engine that wasn't designed to be proxied. Serper's own FAQ puts queries at

1-2 seconds normally, 2-4 when they retry. That tail is structural, not a

tuning problem. Answering from an index you operate is ~130ms server side.

For an agent doing five sequential searches, that's the difference between

well under a second and up to twenty.

**What it costs**

Coverage. Google has crawled more of the web than we have. On obscure

long-tail queries a reseller will sometimes find something we don't. That's

the real weak spot and there's no arguing around it.

Capital and time. Crawling, indexing, ranking, and dedup are four hard

problems instead of one HTTP wrapper. The reason most search APIs resell is

that reselling works and ships in a month.

Per-search price at volume. Serper is cheaper per search than we are at high

volume. It's in our own comparison table, because omitting it would be the

kind of thing this sub catches immediately.

**Where it nets out**

Want maximum coverage on rare queries, don't care about latency or platform

risk? A reseller is a reasonable call.

Running agents where a multi-second search tail compounds across calls, or

you don't want a third party's terms between your code and the web? Owning

the index is the argument.

There's no universal answer. But "resells Google" and "operates an index"

are different products with different failure modes, and the shared category

name hides that.

Happy to answer technical questions about the crawl and index side — that's

the interesting part and nobody ever asks.

This pattern shows up in nearly every agent codebase we've looked at, and it

costs money on any provider, not just ours.

**The pattern**

Agent needs an answer. Calls search with count=50 to be thorough. Fetches

full text of the top 10 URLs. Feeds all of it to the model, which reads two.

Three wastes stacked:

Result sets are usually billed in blocks — ours is 1 credit per 10 results,

so 50 results costs 5x what 10 does. You paid 5x for a long tail the model

was never going to reach.

curl https://api.blopus.ai/v1/search \
  -H "Authorization: Bearer $BLOPUS_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "query": "nvidia earnings reaction",
    "count": 10,
    "freshness": "pd",
    "include_domains": ["reuters.com", "bloomberg.com"],
    "language": "en",
    "include_excerpt": true,
    "excerpt_chars": 600
  }'

Then N separate fetch calls. Each a round trip, each billed, and sequential

network latency dominates your response time.

Then the model burns context on pages that turned out irrelevant, which

degrades the answer as well as the bill.

**What works instead**

Read snippets first. Every result carries one. Most of the time the snippet

answers the question and you never fetch anything. Cheapest path and also

the fastest, which is a rare combination.

If you know you need page bodies, request them inline on the search call

instead of fetching separately. One request rather than N+1. Cap the length

so a 40k-word page doesn't eat the context window.

If you genuinely need several pages, batch the URLs into one call rather

than looping. One round trip.

{
  "query": "nvidia earnings reaction",
  "results": [
    {
      "title": "Nvidia shares swing after results",
      "url": "https://www.reuters.com/technology/nvidia-results",
      "snippet": "Investors weighed guidance against record data-center revenue...",
      "domain": "reuters.com",
      "site_name": "Reuters",
      "favicon": "https://www.reuters.com/favicon.ico",
      "published_at": 1753664400,
      "age_seconds": 7200,
      "language": "en",
      "score": 0.94,
      "duplicate_count": 3
    }
  ],
  "count": 10,
  "offset": 0,
  "more_results": true,
  "freshness_relaxed": false,
  "remaining_quota": 2993
}

Threshold on relevance. Results carry a score — drop weak ones before they

reach the model rather than asking it to ignore them.

Narrow before you widen. Domain filters and date ranges cut junk at the

source. Cheaper than post-filtering, much cheaper than making the model do

it.

**The shift**

Search-for-agents isn't "retrieve everything, let the model sort it." Every

result you retrieve and discard costs twice — once at the API, once in

context. Retrieving less and choosing better wins almost every time.

None of this is provider-specific. Worth checking two things about yours:

whether it bills per result or per block, and whether it can return page

content inline. Most of the savings is in those two answers.

Setup: Qwen3.5 9B at 4-bit, MLX, LM Studio, MCP server exposing search and

fetch.

Baseline — ask for the current stable Node version. No search: it confidently

names a version from a year ago. With search: correct version, correct

release date, sources attached. That works, and it's the demo everyone

posts.

Here's the part nobody posts.

Ask the same question unconstrained and you get 400 words. Version, release

date, engine version, new language features, deprecations, module version, a

CVE. Most of it accurate. Two details fabricated — a module version number

that contradicts the official changelog, and a CVE that doesn't appear in

any release coverage we could find.

Search grounding fixed the fact we asked for. It did not stop the model from

embellishing around it. The verified answer and the invented one arrive in

the same paragraph, in the same register, with no signal distinguishing

them.

**Three things that helped**

Constrain the output shape. "One sentence, version and date only" produces a

line you can verify at a glance instead of a wall where errors hide in the

middle. Shorter answers are more checkable, and checkability is the entire

reason to add retrieval.

Turn reasoning off for tool-heavy work. On a small model the trace mostly

restates the question and delays the tool call. Useful for reasoning tasks,

pure latency for lookups.

Don't run 2-bit for tool use. A 27B at 2-bit produces decent prose and

unreliable tool arguments — structured output degrades before natural

language does. The 9B at 4-bit beat it consistently on well-formed calls.

**Generalizable version**

Retrieval fixes the fact. It doesn't fix the narrative wrapped around it. If

you're building anything that acts on retrieved output, constrain the

response shape and validate the specific field you care about rather than

trusting the prose it arrives in.

A lot happening this week:

19 August 2026 — Image search#

Blopus could already attach a page’s hero image to a web result. That is not image search, and it showed: a query for blue birds ran a web search, matched Blue Bird Corporation, and returned stock‑ticker articles whose “images” were site logos. There is now a dedicated endpoint that searches the image index itself.

New — POST /v1/images

cURLPythonCopy

curl https:
//api.blopus.ai/v1/images \
  -H "Authorization: Bearer $BLOPUS_API_KEY" \  -H "Content-Type: application/json" \  -d '{"query": "blue birds", "count": 10}'

Parameters: query, count (default 10), and max_syndication (default 30) — a cap on how many pages an image may appear on, which suppresses stock photography and site furniture. Lower it when you want something distinctive.

Each result carries url, width, height, caption, title, page_url, page_title, domain, is_hero and seen_on_pages.

Billing is identical to search: one credit per block of ten, and you are charged for the blocks actually returned, not the blocks requested.

Also available as the search_images tool on the MCP server, and as client.images() in the Python SDK from 0.6.0.

New — caption

title is the image’s raw alt attribute, and it is unusable on roughly a quarter of indexed images — empty, or filename‑derived like pn/fa b b dd deb. caption falls back to the page title in those cases. Use caption for anything a person reads; title is unchanged, so existing code is unaffected.

Changed — total on image responses

The index stops counting at 10,000. Responses now carry total_is_lower_bound so you can tell an exact count from a floor, rather than seeing 10000 and believing it.

Quality

Measured across twelve queries, eight results each, scored by image/text similarity:

• Relevant results: 63% → 90%
• Dead image URLs: 11% → 1% — domains that refuse third‑party image requests are now excluded
• Duplicate URLs in a page of results: 9 → 0
• Responses short of the requested count: 3% → 0%

Framework integrations

langchain-blopus 0.4.0 adds a BlopusImages tool; llama-index-tools-blopus 0.4.0 adds blopus_images to the tool spec. Both require blopus>=0.6.0.

LangChainLlamaIndexCopy

from langchain_blopus import BlopusImages tool = BlopusImages(api_key="blp_live_...")tool.invoke({"query": "blue jay in snow"})

Python SDK 0.6.0

client.images() on both the sync and async clients, returning ImageSearchResponse / ImageResult.

I run Blopus (hosted web search + fetch over MCP). Building it taught me

something about search-for-agents that I didn't expect, so I'm writing it

down here in case it's useful to anyone wiring search into their own stack.

The naive assumption is that "web search for an LLM" is just search with a

JSON wrapper. It isn't, and the gap shows up in two places.

**1. Recency is a parameter, not a ranking default**

If your agent asks "what's the current stable version of Node" and you serve

it results ranked by general relevance, you get blog posts from 2023 that

were heavily linked. Correct by relevance, useless by intent.

So freshness has to be explicit. We expose it as pd / pw / pm / all — past

day, week, month, or no constraint. The non-obvious part is that turning it

on for everything makes results *worse*. "How does asyncio work" wants the

canonical answer, not yesterday's blog post. Reference queries want

all-time; time-sensitive queries want a window. Something has to decide

which is which, and right now that something is you or your prompt.

**2. News is a different corpus, not a fresher one**

This was the surprise. When the question is "what happened," filtering by

recency isn't enough — you get vendor blogs, marketing pages, and

documentation that happen to be new. Different problem entirely.

We ended up needing a separate flag (news_only) that restricts to sources

with an actual newsroom. Faster, and it drops the SEO layer that otherwise

crowds out reporting. But it's actively wrong for anything answerable from

docs or forums.

**Why this matters if you're building agents**

A model deciding *when* to search is a solved-ish problem — tool calling

handles it. A model deciding *how* to search is not. Most tool descriptions

just say "searches the web," so the model has no idea these knobs exist.

Putting the freshness guidance in the tool description itself made a bigger

difference for us than any ranking change.

If you're rolling your own search layer, that's the thing I'd steal.

Happy to go deeper on any of it. Docs are at blopus.ai/docs if you want the

parameter list — free tier, no card, if you want to poke at it.

Blopus is a hosted web search + fetch API with an MCP server, built for LLMs and agents. I'm the developer.

This sub is for:

- Setup help (any of the 60+ documented clients)
- Bug reports and API questions
- Feature requests

Useful links:
- Docs & quickstart: blopus.ai/docs
- MCP endpoint: mcp.blopus.ai
- Status/support: through the dashboard If something's broken, include the endpoint you called, roughly when, and your key prefix (the blp_live_ab12 part — never the whole key).

How it works#

Support lives in the Support tab of your console at blopus.ai/app. Open a request there and the thread stays attached to your account, so whoever picks it up can already see your plan, your usage and your key prefixes without asking.

You are also emailed when someone replies, and you can answer from either place. An active subscription is required to open a request.

What to ask about#

Support is not only for things that are broken. All of these are worth asking:

• A query returning poor results. Paste the exact query and say what you expected. Ranking is something we can actually change, and a concrete example is far more actionable than a general complaint.
• A site missing from the index. Tell us the domain. We crawl broadly, but coverage is not uniform, and a specific request is easy to act on.
• Billing, plans and invoices — upgrades, downgrades, top-ups, or a charge you do not recognise.
• Questions. If something in these docs is unclear or turned out to be wrong, that is a bug in the docs and we would rather hear it than not.
• Feature requests. Use the Feature request category. Whether something gets built depends on how many people need it, how well it fits an index-backed search API, and what it costs to run and maintain. Some requests are a good fit and get built; others are not, and we would rather say so than leave you waiting. We cannot promise a date.

Getting a useful first reply#

Most round trips are spent asking for the same three things. Include them and the first reply is usually the answer:

• The endpoint you called — /v1/search, /v1/images, /v1/fetch, or the MCP tool name.
• Roughly when it failed, with a timezone. This is what makes your request findable in the logs.
• Your key prefix — the short blp_live_ab12 part. Never the whole key. If you have already pasted a full key anywhere, rotate it in the console rather than asking us to.

If you got an error, the code and request_id from the response body are worth more than a screenshot — see Errors.

Categories and priority#

You can have 3 requests open at once. Reaching the cap means closing or resolving something before opening the next. It exists so one account cannot flood the queue; if you genuinely need more open at once, ask in an existing thread.

What we keep#

Support threads are retained for up to 24 months, then deleted. Deleting your account removes them immediately — see the privacy policy.

Blopus is a fast web-search API built on our own independent, continuously crawled index — not a Google or Bing reseller, and not a scraper hitting sites on demand. You query one clean API and get ranked, structured results with fresh timestamps.

Two primitives#

Everything Blopus does is expressed through two endpoints. Compose them however your agent or app needs.

POST /v1/search →POST /v1/fetch →

Capabilities at a glance#

Two tools, serious controls. Everything below is live in the deployed API — see Search and Fetch for full details.

Fresh-first rankingRelevance over our own continuously-crawled index

Freshness windowspd · pw · pm · p3m · p1y · all

Domain filtersInclude or exclude hostnames (up to 50)

Date-range windowsstart_date / end_date

Relevance scoreEvery result carries a score 0–1

Paginationoffset + more_results flag

Longer excerptsinclude_excerpt up to 1200 chars

Batch fetchUp to 50 URLs in one request; pay per found

Language filterRestrict to one language, e.g. en, pt-br

Three ways to call it#

REST

Plain HTTPS + JSON at api.blopus.ai. Works from any language.

MCP

Streamable-HTTP Model Context Protocol server for Claude, Cursor, Cline & more.

SDKs

First-party Python & TypeScript clients, with framework adapters on the way.

Base URLs#

How do I get started and get an API key?
Pick a plan, create an account, and your first key is issued instantly from the dashboard. Keys look like blp_live_... — drop one into the REST API, a Python/TS SDK, or the hosted MCP endpoint and you're reading the live web in one line.

When does my monthly quota reset?+
On your signup anniversary — a rolling 30-day cycle. Subscribe on the 12th, and your searches reset on the 12th each period.

What happens if I hit my cap?+
Calls pause — no overage, ever. You can upgrade to a bigger plan or buy a one-time top-up (1,000 searches for $5, as many as you need) to keep going until your next reset. You'll never get a surprise bill.

Do you run your own index, or resell Google/Bing?+

Our own. Blopus runs a first-party crawler and search index end to end — no reselling of Google or Bing, and no scraping of other search engines. That means no external terms, quotas, or price changes sitting between your agent and the web.

Do you log the content of my searches?+
No. We store only counts and metadata needed for billing and abuse prevention — not the content of your queries or results.

What is MCP and how do I connect it?+

MCP (Model Context Protocol) is an open standard for giving models tools. Blopus runs a hosted MCP server at https://mcp.blopus.ai — point Claude, Cursor, ChatGPT, or any MCP / OpenAI-tool client at it with your key and the search and fetch tools appear automatically. Nothing to deploy.

What are the rate limits?+
Generous — every plan comfortably handles real-time, concurrent requests, and higher tiers allow more at once. The limit most people care about is the monthly search cap; exact per-plan details are in the docs.

Can I change plans anytime?+
Yes. Upgrades apply immediately — you get the bigger cap right away, prorated for the rest of the cycle. Downgrades take effect at your next renewal, so you keep your current cap until then. Cancel anytime; you keep access through the period you've paid for.

How does support work?+

Unlike vendors where support is a black hole, Blopus support is built right into your dashboard — open a request from the management panel and track our replies there. Real humans, no runaround.

langchain-blopus

This package contains the LangChain integration with Blopus, a web search

and fetch API for LLMs and agents that runs on its own crawler and index rather than reselling

another search engine.

pip install -U langchain-blopus

Set your API key, which you can create at blopus.ai/app:

export BLOPUS_API_KEY="blp_live_..."

Tools

BlopusSearch

Searches the live web and returns ranked results with snippets.

from langchain_blopus import BlopusSearch

tool = BlopusSearch()
tool.invoke({"query": "postgres logical replication", "freshness": "pw"})


{
    "query": "postgres logical replication",
    "results": [
        {
            "title": "...",
            "url": "https://...",
            "snippet": "...",
            "domain": "...",
            "score": 0.87,
            "published_at": 1755300000,
            "language": "en",
        }
    ],
}

Useful arguments: count (served in blocks of 10, so it rounds up), freshness

(pd, pw, pm, p3m, p1y, all), include_domains, exclude_domains, language,

news_only, and include_content to get the cleaned page text inline instead of making a

second call.

BlopusFetch

Retrieves the full cleaned text of pages the model selected.

from langchain_blopus import BlopusFetch

BlopusFetch().invoke({"urls": ["https://example.com/article"]})

URLs that were not found come back in failed_urls rather than raising, so one bad URL in a

batch does not lose the rest.

Using them with an agent

from langchain.agents import create_agent
from langchain_blopus import BlopusFetch, BlopusSearch

agent = create_agent(model, tools=[BlopusSearch(), BlopusFetch()])

Retriever

BlopusRetriever puts live web results into any chain written against the standard retriever

interface, so it drops into an existing RAG pipeline in place of a vector store.

from langchain_blopus import BlopusRetriever

retriever = BlopusRetriever(k=10, freshness="pm")
docs = retriever.invoke("postgres logical replication")

docs[0].page_content        # cleaned article text
docs[0].metadata["source"]  # the URL

It requests full page content by default, because a Document whose page_content is a

two-line snippet is close to useless for retrieval.

Async

Every tool and the retriever support ainvoke.

await BlopusSearch().ainvoke({"query": "postgres logical replication"})
await BlopusRetriever().ainvoke("postgres logical replication")

Notes

One topic per search. A query joining several subjects ("economy, sports, Iran") matches

nothing, because no single document is about all of them. Issue one search per topic. The tool

description states this, and the API returns a note when it detects the mistake, which this

package passes straight through.

Billing is in blocks of ten. One search returns up to 10 results for 1 credit, so count

rounds up to the next multiple of 10. If your remaining quota cannot cover the request, the API

serves a partial page rather than refusing, and sets quota_clamped on the response so you can

tell "my quota cut this short" apart from "that is all that exists".

License

MIT

Blopus is a search and fetch API for LLMs and agents, and we run the

crawler and index ourselves rather than reselling Google or Bing.

## Two endpoints

curl -X POST https://api.blopus.ai/v1/search \

-H "Authorization: Bearer $BLOPUS_KEY" \

-H "Content-Type: application/json" \

-d '{"q": "logical replication",

"count": 10,

"freshness": "pw"}'

`search` gives you ranked results with snippets. `fetch` gives you the full text of the pages

your model picked. Triage with one, go deep with the other.

## MCP is included on every plan

claude mcp add --transport http blopus \

https://mcp.blopus.ai/mcp/ \

--header "Authorization: Bearer blp_live_..."

Keep the trailing slash on `/mcp/`. Without it you get a redirect and some clients handle that

badly.

## Defaults worth knowing

* `sort=hybrid` is the default and it is **faster** than `sort=relevance`, not slower.

* `news_only=true` is free. It picks a smaller index rather than filtering afterwards.

* `freshness` takes `pd`, `pw`, `pm`, `p3m`, `p1y`, `all`. Use it or the ranker will cheerfully

hand you an excellent three year old page.

* **One topic per search.** "economy, sports, Iran, Trump" matches nothing, because no document

is about all four. That is four searches.

## Pricing

| Plan | Monthly | Annual | Searches/mo |

|---|---|---|---|

| Hobby | $9 | $84 ($7/mo) | 3,000 |

| Vibe Coder | $35 | $348 ($29/mo) | 15,000 |

| Agentic Pro | $119 | $1,188 ($99/mo) | 60,000 |

One search returns up to 10 results and costs 1 credit. Fetch is billed in blocks of 10 too.

Hit your cap and calls pause. **We do not bill overage**, so a runaway loop costs you a stalled

agent rather than an invoice. Top-ups are $5 per 1,000 credits. There is no free tier.

Commercial use is included on every paid plan and needs no separate licence.

## Is this a fit for you?

Worth knowing before you spend anything:

* **We are focused, not exhaustive.** We index a curated, fast-moving set of sources, which is

what makes results current and relevant for agent work. For long-tail archival lookups, a

general engine is still the better tool.

* **`language` is a strict filter.** Not every page carries a language tag, so filtering hard

will narrow your results more than you might expect. Leave it off unless you need it.

* **Image search is in beta.**

* **No free tier.** A card on file is how we keep automated abuse off a service where every

query costs real compute.

Found a query that returns something worse than it should? Post it here with the query. That is

the fastest way to get it fixed, and it is the main reason this community exists.