The Services section is the single place where every external service of Xedant Research Agent is configured. Search providers, page-download methods and LLMs — the AI models that read the downloaded pages and turn them into structured data — are connected here, in the interface, not through environment variables.
Service categories
- Search providers — Serper, Keenable, Brave, Tavily, DuckDuckGo and JSON SEO (each needs an API key — the access code the provider issues you; JSON SEO also lets you pick the search engine — Yandex, Google or Bing — and, optionally, a region; DuckDuckGo needs no key at all) and SearXNG (the base URL of your own instance); each provider is added as its own service entry;
- Download methods — five ways to get a page: Direct HTTP (a plain request), Proxied HTTP (through a proxy — an intermediate server that sends the request for you), Browser Emulation (a local browser), Nodriver (a local undetectable browser for protected pages) and Remote Browser (an external browser-control service). You only supply the proxy for Proxied and the service address for Remote Browser — the browsers for the local methods download themselves on first use;
- LLM — any OpenAI-compatible providers for data extraction.
A finished service configuration can be repeated without retyping anything: each service row has a copy button that puts the whole configuration, keys included, on the clipboard. Next to the “Add service” button sits a paste button: it creates a new service straight from the copied settings, which you can then rename. Handy when the same service is needed twice, or when settings are being moved to another server.
Priorities and fallbacks
Inside a category, services are ordered by priority: when one fails or is unreachable, the request automatically goes to the next — no intervention needed. For data extraction we recommend a cheap model at a low priority (the lower the number, the earlier it is tried) and a pay-as-you-go model at a higher priority as the fallback.
Every service has a limit on simultaneous jobs — how many requests go to the provider at once; new services start at ten. If a provider throttles how often you may call it, you can also set a rate limit: no more than a set number of requests per period.
Keys through environment variables
A secret in a service’s settings does not have to live in the database — it can be stored as a reference to a server environment variable: $NAME or ${NAME}. On every call the product substitutes the variable’s value, so the real key never lands in the database. In the interface the reference is shown as-is: it is a pointer, not the key itself, so there is nothing to mask.
What this gives you: to change a key you never touch the database — it is enough to change the variable’s value and restart the container the product runs in. If the variable is not set, the product reports it with a clear error naming the variable (for example, “ApiKey references environment variable ‘X’ which is not set in the server environment.”) instead of sending a request without a key.
Models and cost
Any OpenAI-compatible model works for data extraction. Our recommendation is DeepSeek-V4-Flash: a full research run costs $0.09–$0.27, and DeepSeek-V4-Flash-Mini (on OpenRouter) comes even cheaper. Heavier jobs — writing reports, planning — are handled by the agent with whatever model is configured on its side; the services of Research Agent only cover extraction.
Every request to a model provider is tagged with the string XedantResearchAgent/0.1.6 — the product name and its version — so providers can see which product is calling them.
LLM session header
Every model request made during extraction carries the job’s session id — sent in a dedicated request header. The header name is set in the LLM service’s settings (the “Session header name” field); left empty, the product fills it in itself: X-Opencode-Session for the opencode.ai provider and X-Agent-Session for everyone else.
Why this matters: the provider can group all of one job’s traffic under a single session, which makes it easy to track spend and logs per job instead of per individual call. The id stays the same for every call of the job, even when a request automatically switches to a fallback model. The header is sent on the in-interface service test as well (with a dedicated test value) — otherwise gateways that require a session would fail the test even though the working key is fine.
Testing services
Every service can be checked right from the editor — the tester makes a real request to the provider and shows the response, so a broken key is visible before it breaks a research run. When you press Test, the form is saved first, so the result always describes exactly the settings you are looking at.
Agent API status
REST access for external agents — the API, the way for other programs such as Xedant Agent to call Research Agent directly — is controlled by the RESEARCH_AGENT_API_KEY environment variable: while it is unset, every such request is answered with “Agent API is disabled”. The variable stores only a SHA-256 hash of the key, so the key itself is never displayed anywhere. Details in the Xedant Agent Integration section.
Statistics
- Completions — the history of LLM calls: tokens, cost and timing of each;
- Sessions — research sessions: the searches, downloads and extractions of one topic, with final counters.
- ClickHouse export — research statistics can be exported to an external ClickHouse database for your own analytics: set the connection string in the
RESEARCH_AGENT_CLICKHOUSE_URLvariable and the product creates the database and its table itself; from then on data flows out in the background once a minute. Until the variable is set there is no export; once it is, the Analytics page — the last entry in the sidebar — shows a “Backfill ClickHouse Stats” button for pushing the entire history over at once. Details in the Installation section.