No KYC, First Call in Five Minutes: A Minimal Path From Signup to a Working Chat Completion

What you need before you start

The goal is simple: one successful chat completion with as few steps as possible. Have these ready:

• A crypto wallet that can send USDC on the Base network.
• A small amount of USDC (plus a little ETH on Base for the network fee, depending on your wallet).
• A terminal with curl, or a Python/Node environment if you prefer an SDK.

No identity documents are required. The account is funded by USDC, and access is granted through an API key you create.

Step 1: Create the account

Sign up on the site with an email address and password, or whatever sign-in method the dashboard offers. This creates your account record; it does not yet give you API access or credit.

After signup you land in the dashboard. Two things matter there: the top-up section and the API keys section.

Step 2: Top up with USDC on Base

Open the top-up section and choose USDC on Base as the payment method.

The dashboard shows a deposit address (and usually a QR code). Send USDC on the Base network to that address from your wallet.

• Confirm the network is Base. Sending USDC on a different chain to a Base address is a common way to lose funds.
• Send a small test amount first if this is your first deposit, then confirm it appears in your balance before sending more.
• Wait for the transaction to be confirmed on-chain. Your dashboard balance updates after confirmation; this normally takes a short time but depends on network conditions.

There is no KYC step between payment and credit. Once the USDC lands, your balance is spendable.

How billing works, briefly

You pay the official model price multiplied by 1.3, deducted from your USDC balance as you make calls. That multiplier covers payment processing and platform operation. If you later contribute keys to the pool, you are credited at the official price multiplied by 1.1 (or 1.2 for premium keys) in USDC. For this walkthrough, the only relevant fact is that your balance is drawn down per request at 1.3× the official price.

Step 3: Create one API key

Go to the API keys section and create a new key. Name it something you will recognize, like first-test.

• Copy the key immediately. Most dashboards show the full key only once.
• Store it somewhere safe, ideally an environment variable rather than pasting it into source files.
• One key is enough. The same key works across the models the platform exposes, so you do not need a separate key per model.

Set it in your shell:

export LLM_API_KEY="your-key-here"

Step 4: Make the first call

Use the OpenAI-compatible chat completions shape that most aggregators follow. Replace the base URL and model name with the ones listed in the platform's API documentation.

curl https://YOUR_BASE_URL/v1/chat/completions \
  -H "Authorization: Bearer $LLM_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "MODEL_NAME_FROM_DOCS",
    "messages": [
      {"role": "user", "content": "Reply with the single word: ready"}
    ]
  }'

The equivalent in Python with the OpenAI SDK, pointed at the aggregator's base URL:

from openai import OpenAI
import os

client = OpenAI(
    api_key=os.environ["LLM_API_KEY"],
    base_url="https://YOUR_BASE_URL/v1",
)

resp = client.chat.completions.create(
    model="MODEL_NAME_FROM_DOCS",
    messages=[{"role": "user", "content": "Reply with the single word: ready"}],
)
print(resp.choices[0].message.content)

A short prompt like this keeps the first call cheap and makes the response easy to eyeball.

Step 5: Verify success

You have a working setup when all of these are true:

• The HTTP response is 200 and contains a choices array with a message.
• Your dashboard balance decreases by a small amount matching the request's token usage at the 1.3× rate.
• The usage block in the response (prompt, completion, total tokens) looks sensible for your prompt.

If the call fails, check in this order: the key is copied completely and has no stray whitespace; the base URL includes the version path the docs specify; the model name matches exactly what the docs list; and your balance is positive.

Step 6: Switch models with the same key

With one key and a funded balance, changing models is just changing the model string to another name from the documentation. Keep the same base URL, headers, and key. This is the main practical benefit of an aggregator: credentials and billing stay fixed while the model behind the request changes.

To compare models, send the same prompt with different model values and compare the outputs and the usage figures. Keep an eye on the balance as you go, since different models consume different amounts per call under the same 1.3× rule.

Common first-run snags

• Wrong network on deposit. USDC must be sent on Base. Verify the network in your wallet before sending.
• Deposit sent but balance unchanged. Confirm the transaction succeeded on-chain, then refresh the dashboard. Allow time for confirmation.
• 401 response. The key is wrong, truncated, or not being read from the environment variable. Print the variable's length to sanity-check it.
• 404 on the path. The base URL is probably missing or duplicating a path segment. Copy it from the docs exactly.
• Model not found. Model names are case-sensitive and platform-specific. Use the exact identifier from the documentation.

Where to go next

Once one call works, the shortest useful next steps are to wrap the call in a small script, move the key and base URL into configuration, and try a second model with the same prompt to see how outputs and token usage differ. Everything else—more keys, contributed keys, higher volume—builds on this same loop: fund with USDC, authenticate with a key, send a request.