The Price of Evidence: Providers, Credits, and Coverage
OpenSEO's data plane answers a practical question that is easy to miss in discussions of open-source software: who pays for the observations on which an SEO decision depends? This chapter follows one request through DataForSEO, OpenSEO's hosted metering or self-hosted path, caching, and provider routing. The aim is not to calculate a universal price, but to help the reader judge what a result means, what it costs to obtain, and when a missing field should change the recommendation.
The previous chapter separated the application, MCP, Agent Skills, project context, and human decision. Those boundaries become more consequential when the agent asks for live search results or a large keyword set. A tool call consumes an external resource, and the resource does not have uniform coverage or uniform certainty. OpenSEO's design makes that constraint visible rather than pretending that an open repository has made the web's historical data free.
Open source changes control, not data economics
OpenSEO's code and deployment model are open, but much of the data that makes a broad SEO platform useful is not costless to produce. Keyword volumes require collection and normalization. Rank tracking requires search results from particular places, devices, and times. Backlink indexes require continual crawling and storage. Historical trends require keeping records after the moment of collection. An application can be free to inspect and modify while the observations it retrieves remain metered.
OpenSEO uses DataForSEO as its main external SEO-data provider. A self-hosted operator needs an account and API credentials; a hosted user encounters the service's own usage-credit model. The distinction is important because the software and the data have different owners. OpenSEO can change its interface, choose which fields to display, and route a request to an appropriate endpoint. It cannot make the provider's collection, processing, or infrastructure costs disappear.
This gives open source a different economic meaning from “no bill.” The user can inspect how provider calls are wired, fork the application, run it in their own environment, or replace parts of the data layer if a better source becomes available. They gain leverage and choice. They do not gain a guarantee that every future search observation will be free, complete, or equally accurate.
The current repository separates hosted and self-hosted behavior. In hosted operation, OpenSEO checks the organization's available usage credits, executes the provider call, and records the resulting spend. The current billing constants apply a 1.28 markup to raw provider cost for hosted customers and put DataForSEO and agent-LLM usage into a shared credit pool. In self-hosted operation, the data client bypasses the hosted metering path and the operator pays DataForSEO directly. That can remove a layer of hosted billing, but it transfers account management, secret handling, usage monitoring, and infrastructure responsibility to the operator.
Neither path is automatically cheaper. Hosted use buys convenience, managed identity, and an application that someone else operates, in exchange for the service's pricing and usage rules. Self-hosting can provide more control and may reduce the platform's added charge, but it does not remove provider fees. It also introduces costs that are less visible on a pricing page: deployment, upgrades, backups, access control, troubleshooting, and the time required to understand failures.
One request has more than one ledger
It helps to think of an OpenSEO request as moving through two ledgers at once. The first ledger records evidence: what data was requested, for which market, and what came back. The second records resources: which provider calls were made, whether they were cached, how much they cost, and whether the user approved the operation.
Suppose an agent receives a request to research five seed topics. The keyword tool accepts a bounded batch, resolves the project market and language, and asks the research service for results. If the provider path is a paid one, OpenSEO meters the request. The response includes the returned rows and can identify the source or fallback used for each seed. A single failed seed does not necessarily invalidate the other four, but the failure should remain visible. The resource ledger says that work was attempted; the evidence ledger says which parts are usable.
The two ledgers explain why a result should not be summarized as simply “the agent researched the keywords.” A person may need to know whether the result came from a cache, whether a country used a different data source, whether a clickstream refinement was requested, whether one seed failed, and whether the metrics include the fields needed for the decision. A lower-cost result with less evidence can be the right choice for an early screen. It is not automatically an adequate basis for a final page strategy.
The same logic applies outside keyword research. A rank check can cover many keywords and devices in one run, so OpenSEO asks for an estimate and an approved maximum credit amount before starting it. A local rank grid multiplies searches across points, so the local SEO guidance treats each point as a paid observation and warns against expanding the grid casually. An AI-visibility lookup may fan out across platforms and competitor comparisons, while prompt responses are expensive enough to justify short-term caching. The apparent simplicity of the request hides the number of upstream operations it triggers.
A cost gate is therefore part of the workflow, not merely a billing feature. The MCP server instructs agents to ask for confirmation before planned batches above its current threshold, and individual tools can require a more specific ceiling. This gives the person a chance to compare the expected value of information with the cost of obtaining it. If the question is still vague, buying more rows is often a way to postpone the decision rather than improve it.
The sequence has an important asymmetry. A cache hit can avoid a fresh provider call, but it does not erase the conditions under which the original data was collected. A self-hosted request can avoid the hosted credit ledger, but it does not avoid the provider's bill. A returned row can be useful, but the presence of a row does not prove that it answers the user's business question.
Coverage shapes what the agent is allowed to infer
Provider routing is not just an implementation detail. It determines which claims are available to an agent. OpenSEO's accepted routing design uses DataForSEO Labs as the default source where it is supported. That path can provide keyword difficulty, search intent, and SERP-feature context alongside demand data. For countries outside Labs coverage, the application can use Google Ads-derived endpoints for some keyword research and metric operations. Those endpoints broaden country coverage, but the returned rows do not carry the same difficulty and intent fields.
The practical consequence is that two keyword requests can look similar while supporting different conclusions. In one market, an agent may be able to compare volume with difficulty and intent. In another, it may have a volume signal but no equivalent difficulty or intent. The second result is not worthless; it is narrower. The agent can use it to identify terms for further investigation, but it should not silently present the missing fields as if they were known.
The routing design also distinguishes features. SERP analysis and rank tracking can use a provider path that supports the relevant market even when domain-overview or ranked-keyword functions are unavailable for that country. A country can therefore be supported for one workflow and constrained for another. “OpenSEO supports this country” is too broad a statement unless the speaker names the feature and the evidence it returns.
The same care applies to optional refinements. OpenSEO makes clickstream refinement opt-in for relevant keyword calls because it doubles the request cost and changes the volume detail, not because it magically turns an uncertain metric into ground truth. The default path uses standard Google-Ads-derived volume behavior; the refinement can separate close variants more precisely when that distinction matters. The right choice depends on the decision. If the user is screening a broad set of themes, the extra cost may not be justified. If the decision hinges on variants that are grouped together, the refinement may be worth approving.
This is a general rule for evidence systems: a data source should be named together with its field set and operating conditions. “Keyword data” is not one object. It can mean a volume estimate, a difficulty score, an intent classification, a live SERP, a site's own impressions, or a page's observed clicks. OpenSEO's value lies partly in putting those signals behind a common project and workflow layer, but that common layer should not erase their differences.
Efficiency needs a freshness contract
Caching is one of the ways OpenSEO manages repeated provider work. The AI-search services, for example, cache successful brand-lookup results for a day and individual prompt/model responses for several days. That is reasonable when the provider data or generated response is expensive and does not need to change every second. A cached result can make an exploratory workflow faster and cheaper, and it can prevent an agent from buying the same answer repeatedly while a person refines the question.
But a cache is not a synonym for truth. It is a statement about acceptable staleness. A rank position, a SERP composition, a cited answer, and a business profile can all change on different time scales. A result should therefore carry enough scope and freshness information for a reader to decide whether it is still relevant. A seven-day prompt response might be suitable for comparing how models answer a stable question; it might be too old for a time-sensitive campaign or a newly changed page.
The implementation also distinguishes complete and partial AI-search results. If one platform call fails, the service can preserve usable results from another platform, but it should not cache a response as complete when a required sub-call did not succeed. That distinction prevents an operational failure from becoming a durable blank or a misleading “zero.” The same principle appears in other workflows: an audit that is blocked or rate-limited should expose the condition, and a Search Console connection error should not be read as an absence of traffic.
Caching and metering thus pull in opposite directions. Fresh calls provide newer evidence but cost more and may fail transiently. Cached calls reduce cost and latency but introduce a freshness boundary. The right design does not choose one side universally. It makes the boundary visible, keeps incomplete results from masquerading as complete ones, and lets the workflow decide whether the evidence is sufficient for the next action.
A practical rule for reading cost and certainty together
Before asking OpenSEO to spend, the user should be able to state the decision the data will inform. If the decision is “which of these three existing pages should be improved first,” a small, first-party-centered investigation may be enough. If it is “how does this market behave across locations and devices over time,” the request will naturally require more paid observations and a more careful scope. The cost is not evidence that the second question is more important; it is a property of the observation process.
The agent should also say what the result cannot establish. A Google Ads-served keyword row without difficulty or intent is a partial strategy input. A cached AI mention is a time-bounded observation. A rank estimate is not a promise. A self-hosted direct call is not free. A failed provider response is not a negative market signal. Those qualifications are not bureaucratic decoration. They are how the resource ledger and evidence ledger stay connected.
OpenSEO's data model is strongest when it makes these trade-offs explicit: pay for the evidence that answers a defined question, use the narrowest workflow that can answer it, reuse complete results when their freshness is acceptable, and stop when a missing field changes the decision. The next chapter turns that rule into a compact mental model for deciding what to ask, what to ground in existing context, what to measure, and what to authorize.