Octen AI Search API: 78 ms Inside, One Second End to End

Copy this line to your agent to give it Octen web search.

set up https://monid.ai/SKILL.md and use octen /search for a query

Octen puts its own latency in every response. On 2026-09-15 we ran the same search three ways and the field read 78, 83 and 78 milliseconds. The runs took 1,009, 1,005 and 1,041 milliseconds to come back. Both numbers are honest, and the gap between them is the first thing to understand about a search engine that sells speed. This guide runs through Monid, the OpenRouter for agent tools.

What does Octen search actually return?

Ten results with two dates each, a highlight per result, an optional full-text body that bills by the token, and a usage block that tells you exactly what you were charged for.

The result row

octen/search for reddit api pricing changes 2025, ten results, general topic:

{
  "title": "Reddit API in 2026: Pricing, Rate Limits & What Works",
  "url": "https://socialcrawl.dev/blog/reddit-data-api-2026",
  "authors": "SocialCrawl",
  "time_published": "2026-06-26",
  "time_last_crawled": "2026-09-12",
  "highlight": "…2,669 characters of query-relevant passages…",
  "full_content": "",
  "favicon": "…"
}

Eight fields. highlight carried between 254 and 2,876 characters on our ten rows: not a snippet, a set of passages selected for the query. full_content was empty because we had not enabled it, and the next section is about what happens when you do.

The two dates

Every row carries time_published and time_last_crawled, and they are different facts. Across our ten results the publish dates ran from June 2023 to June 2026. The crawl dates ran from 2026-04-12 to 2026-09-12, on a query made 2026-09-15. One result had not been re-crawled in five months; another had been crawled three days earlier.

That is what "fresh" looks like from inside a response. The index takes new pages quickly, which is the claim on the Octen launch page, and existing pages are re-visited on a schedule that varies by page. The field is what lets you tell one from the other, and an agent that filters on time_last_crawled is asking a question the engine can actually answer.

The usage block

{ "usage": { "num_search_queries": 1, "full_content_tokens": 0, "full_content_extra_count": 0 }, "latency": 78 }

num_search_queries is what the per-call line bills. full_content_tokens is what the token line bills, and it was zero because full content was off. latency is the engine's own timer. Every number on your bill is in this object, which is rarer than it should be.

General versus news

The same query with topic: "news" and a one-year window returned ten results, five of them shared with the general run. The other five were blogs and guides, not news outlets, because the query is not a news query. The topic switch changes the ranking bias, not the corpus, and on a how-much-does-it-cost question it did not surface anything the general run had missed.

📖 See also Octen search for AI agents

Is Octen really 62 milliseconds?

Inside the engine, close to it. Through any HTTP hop, no, and the response tells you both.

What the launch page measures

The Octen launch page reports 62 milliseconds at P50 and 68 at P90 for search retrieval, against 244 and 372 at P50 for two named rivals. That is retrieval latency, measured at the engine.

What we measured

Three search calls on 2026-09-15:

The engine's own number was within a few milliseconds of the launch-page figure on every single-query call. The round trip through Monid, which includes our gateway, provider authentication, the network both ways and the run record, was about a second.

Why both are true

Retrieval is one step in a call. The engine does it in under a hundred milliseconds and says so. Everything else a request goes through adds the other nine hundred, and that overhead is roughly constant whichever engine sits at the end of it. Two providers at 62 and 244 milliseconds retrieval are 1.0 and 1.2 seconds end to end, which is a real difference and a smaller one than the retrieval figures alone suggest.

The number to design on

meta.latency if you are comparing engines. Wall clock if you are budgeting an agent loop. An agent that fans out twenty searches in parallel sees the engine's number matter, because the gateway overhead overlaps; an agent that runs them one after another sees the wall clock. This is the same measured-versus-felt distinction that separated the two Reddit providers in the Reddit scraper comparison, where one returned in four seconds and the other in three minutes.

How do you use Octen through one key?

Four endpoints, and the first is enough for most agents.

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 learns the whole discover, inspect, run workflow itself. More in the agent quickstart.

For humans

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

Step 1. Search

What it does. Returns ranked results with highlights and two dates.

The endpoints. octen/search, billed per call, requires query.

The call.

monid run -p octen -e /search -i '{"query": "reddit api pricing changes 2025", "count": 10}'

What comes back. Ten rows with the fields above and the usage block.

What it costs. A tenth of a cent per call at the default, whatever count is. Current figures at monid.ai/tools.

Step 2. Search with full content, when the highlight is not enough

What it does. Adds the page body to each result, capped per result.

The call.

monid run -p octen -e /search \
  -i '{"query": "reddit api pricing changes 2025", "count": 5, "full_content": {"enable": true}}'

What comes back. full_content of 5,212 to 6,186 characters per result on our run, and meta.usage.full_content_tokens: 10359.

What it costs. The per-call base plus a per-thousand-token line for the content. Our bill reconciled to the token: base, plus 10,359 tokens at the content rate, and nothing else. The default cap is 2,048 tokens per result; raise max_tokens and the line grows with it.

Step 3. Broad search, when one query is not enough angles

What it does. Decomposes the query into sub-queries and runs them concurrently.

The endpoints. octen/broad-search, billed per sub-query.

The call.

monid run -p octen -e /broad-search \
  -i '{"query": "how do AI agents get live web data without a browser", "max_queries": 5}'

What comes back. Five generated sub-queries, each with ten results: fifty rows, forty-three unique URLs. The sub-queries it wrote for us were "AI agents live web data access methods", "how AI agents get real-time web data", "AI agents web scraping without browser", "AI agents API integration for web data" and "AI agents data retrieval techniques".

What it costs. Five sub-queries, five per-call charges. max_queries is the budget.

Step 4. Extract and embed

What it does. Turns URLs into markdown, and text into vectors.

The endpoints. octen/extract, per successful URL, up to twenty per call. octen/embedding, per token by model.

The calls.

monid run -p octen -e /extract -i '{"urls": ["https://monid.ai/blog/guides/reddit-scraper"], "format": "markdown"}'
monid run -p octen -e /embedding -i '{"input": ["reddit api pricing", "how much does the reddit api cost"]}'

What comes back. Extract: 16,091 characters of markdown, plus category and page_structure classifications the page did not ask for. Embedding: two vectors of 2,560 dimensions from the default 4b model, at a cosine of 0.781 for two paraphrases of one question.

What it costs. Extract, per successful URL; a 404 and a 504 in our batch were returned with status: "failed" and not billed, twice measured. Embedding, per token: twelve tokens rounded to zero on the run record.

📖 See also What Is the Best Web Search API for AI Agents in 2026?

Why does the extract payload change when you pass a query?

Because query is not a filter on extract. It is a mode switch, and the schema describes it as an option rather than as one.

The measurement

Five URLs through octen/extract with query: "reddit api". The three successes came back with highlights arrays of five, one and five passages, plus title, both dates, category and page_structure. No full_content field at all.

Two URLs through the same endpoint with no query. The success came back with full_content of 16,091 characters and no highlights.

What the schema says

The query parameter is described as "intent-focused keywords; when provided, returns query-relevant highlights". That reads as an addition. On the wire it is a substitution: highlights replace the body. A pipeline that passes a query to focus the extraction and then reads full_content will read an absent field on every row.

What to do with it

Decide which payload you want and pass query accordingly. For a RAG index you want the body, so leave query off. For an agent deciding whether a page is worth reading, you want the highlights, so pass one; the response is smaller and the decision is faster. If you want both, that is two calls, and the second is billed too.

The free classification

Both modes returned category: {primary, secondary} and page_structure: {primary, secondary}. Our own guide came back as "Computers, Electronics & Technology / Programming and Developer Software" and "Content Page / Article". Nobody asked for that and it is useful: a crawl frontier can drop everything that is not an article before extracting it, which is the same triage argued for a URL list in the Firecrawl guide, where map runs before crawl.

Failures are free, and the row says why

The 404 came back "error_message": "Target returned HTTP 404", the timeout "Target server error (HTTP 504)", both with status: "failed", and the run billed only the successes: three of five, then one of two. That matches the endpoint's own pricing note, and it means an unvetted list of URLs costs only what it yields. The URL-to-markdown cookbook builds a whole pipeline on exactly that property.

Which endpoint should I use for which job?

Every row was verified with monid inspect on 2026-09-15. The table gives billing shape rather than figures, because shape drives design and current numbers live on monid.ai/tools.

The shapes are the design. Search is per call, so count is free to raise. Broad search is per sub-query, so max_queries is the budget. Extract is per success, so a bad URL list costs nothing. Embedding is per token, so batch the inputs. Four endpoints, four different levers, one key.

When is Octen the wrong tool?

Four cases.

You are comparing engines on the round trip. The engine's latency is in the response and it is very low. If your comparison is wall clock through your own stack, the gap between providers narrows to the retrieval difference, and a benchmark that quotes only the engine figure is describing a component. Measure the loop you will actually run.

You need a page that has not been crawled recently. time_last_crawled ranged over five months on one result set. For a page whose freshness matters, check the field, and if it is old, extract the URL directly; extract fetched our own page on demand with a crawl timestamp of the same minute.

You want full content and highlights from one extract call. The query switch gives you one or the other. Two payloads is two calls, and the schema will not warn you.

You already run a vector store on a different model. Octen's embeddings are 2,560 dimensions on the default model, and vectors from different models do not mix. If your index is built on another provider's space, embedding new documents here means re-embedding everything or running two indexes. The same lock-in shape is discussed in the mixed-documents ingestion guide.

And the disclosure: this is Monid's blog and we resell Octen, and the page that makes the performance claims is ours too. This article's job was to check them from the outside. The retrieval number held; the round trip is a second; the extract payload has an undocumented switch; failures were free twice. That is the measurement, favourable and otherwise.

Conclusion

Octen's search returns ten rows with a highlight, two dates and a usage block that accounts for every line on the bill, and it puts its own latency in the response. That number was 78 milliseconds on our calls, a few milliseconds from the launch page's 62 at P50, and the round trip through a gateway was about a second. Both are true; design on the one your agent will feel.

What matters more than the speed is the fields. time_last_crawled is what "fresh" actually means per result. meta.usage.full_content_tokens is the whole content bill, reconciled to the token. And on extract, query is a switch between two payloads rather than a filter on one, which the schema does not say and the response does.

Free next step: run monid inspect -p octen -e /extract and read the query description, then call it once with a query and once without on the same URL and diff the keys. It costs two tenths of a cent and it is the fastest demonstration of the point in this article. Start at monid.ai.

FAQ

Last updated September 2026.