# Developers
This section provides a comprehensive guide for developers and AI application builders who want to use OpenSeed as their AI inference provider. Whether you are building a simple application, integrating an AI assistant into your workflow, or deploying production AI agents, the setup process is designed to be minimal and the ongoing experience seamlessly transparent.
### Overview of the Buyer Experience
Using OpenSeed as a Buyer requires setting up and running a local Buyer proxy that sits between your AI tools and the OpenSeed network. This proxy is the only new software component you need to introduce into your existing workflow. Everything else — your AI tools, your application code, your model configurations — remains exactly as it is.
The Buyer proxy presents a standard OpenAI-compatible API on your local machine. Your tools and applications point at this local API as if it were any other OpenAI-compatible endpoint. The proxy invisibly handles all OpenSeed-specific logic: querying the Registry, selecting providers, managing payment channels, executing the x402 payment handshake, and routing requests. Your tools receive responses in the exact format they expect, with no awareness of the decentralized network that served the request.
This architecture means your integration effort is a one-time configuration change, not an ongoing engineering commitment. You change one URL, and you are on the OpenSeed network.
### Step One: Wallet Setup and Funding
Every Buyer on the OpenSeed network needs a funded EVM wallet. This wallet is the financial core of your Buyer node — it holds the USDC you spend on inference and the ETH you use for gas, and its private key signs every payment authorization your node generates.
Creating a new wallet for your OpenSeed Buyer node is recommended over using an existing wallet that holds significant other assets. The private key is stored on your local machine and used by automated software — while it is protected by standard security practices, having a dedicated OpenSeed wallet limits your exposure if the key is ever compromised.
You will need two types of assets in your Buyer wallet. USDC on Base is your primary payment currency. This is what flows from your wallet to Seller nodes in exchange for inference. The amount you should fund depends on your expected usage patterns. A developer doing light testing and experimentation might start with $5-10 in USDC. A team running a development environment with moderate usage might need $50-100. A production system running continuous agent workloads might maintain a $500+ balance with auto top-up configured.
ETH on Base is required in small amounts to pay the gas cost of ReserveAuth transactions. ReserveAuth transactions are the one-time channel-opening transactions that establish payment channels with Sellers. Each one costs a small amount of ETH in gas — typically a few cents at normal Base gas prices. Since you open a new channel at most once per Seller per session, and since you may route the majority of your traffic through a small number of preferred Sellers, your ETH consumption is modest. A few dollars of ETH on Base is sufficient for many months of typical usage.
Both USDC and ETH on Base can be acquired through Coinbase (which has native Base support), through bridging from Ethereum mainnet using the official Base Bridge, or through any exchange or onramp service that supports Base Mainnet.
### Step Two: Installing the Buyer Proxy
The OpenSeed Buyer proxy is installed via the openseed-sdk npm package. The installation process is designed to be familiar to any developer who has worked with Node.js packages.
\[Full installation commands and configuration options will be documented here]
After installation, you configure the proxy through a configuration file. The key configuration parameters are your wallet credentials (either a private key directly or a path to an encrypted keystore file — the latter is recommended for production use), your price cap (the maximum USDC per million tokens you are willing to pay — any Seller priced above this cap will be excluded from your routing pool), preferred model aliases (optional mappings from the model names your applications use to the model names available on the OpenSeed network), and your fallback preferences (whether to allow fallback to alternative models when your primary model is unavailable).
The proxy starts as a local HTTP server on port 8377 by default. The port is configurable through the configuration file for environments where 8377 is occupied by another service.
### Step Three: Connecting Your Tools
With the proxy running, connecting your AI tools to the OpenSeed network requires changing the API base URL in each tool's configuration. The exact location of this setting varies by tool:
In Claude Code, the API endpoint is configurable in the model configuration settings.
In Continue, the OpenAI-compatible provider URL is set in the config.json file.
In Cursor, the API base URL is accessible through the Settings menu under the AI configuration section.
In any application using the OpenAI Python or JavaScript SDK, the base\_url parameter in the client configuration can be pointed at your local proxy.
\[Specific configuration instructions for each major tool will be documented here]
From the moment you complete this configuration change, your tools are running on the OpenSeed network. Every inference request they send is routed through your Buyer proxy to the best available Seller, paid for autonomously, and the response is returned in standard format.
### Understanding Your Costs
OpenSeed provides complete transparency into your inference spending. The Buyer proxy maintains a detailed local log of every request, including the Seller that served it, the actual input and output token counts, the USDC amount authorized, the response latency, and any fallback events that occurred.
This data is available in real time through the Dashboard — a web interface served by the Buyer proxy that gives you a visual overview of your network activity, spending rate, channel balances, and provider performance. It is also available through the CLI for scripting and automation purposes, and through a local API that can be integrated into custom monitoring or cost-tracking systems.
OpenSeed spending is strictly pay-as-you-go and real-time. There are no invoices, no billing cycles, no minimum spend commitments, and no surprise charges. Your USDC balance decrements continuously as you use the network, and you can monitor it in real time. You can configure low-balance alerts that notify you when your USDC balance drops below a threshold, and you can configure automatic channel top-up that triggers a new ReserveAuth transaction when the channel balance runs low, ensuring uninterrupted service.
### Managing Multiple Providers and Preferences
Advanced users may want more granular control over their provider selection than the default composite scoring algorithm provides. The Buyer proxy supports several advanced configuration options for managing provider relationships.
Provider allowlists and blocklists allow you to explicitly include or exclude specific providers by node ID, regardless of their reputation score. This is useful for operators who have established trusted relationships with specific providers or who have had negative experiences with particular nodes and want to avoid them.
Price cap per model allows different USDC budget limits for different models, reflecting the reality that you may be willing to pay more for access to a high-capability model than for a smaller, more commodity model.
Reputation threshold filtering allows you to exclude providers below a minimum reputation score, ensuring that your traffic always goes to providers with an established track record of quality and reliability.
Preferred provider pinning allows you to configure a specific provider as the primary choice for specific models, falling back to the general routing algorithm only when the preferred provider is unavailable.
---
# Agent Instructions: Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter:
```
GET https://docs.openseed.gg/integrations/developers.md?ask=
```
The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.