First-Time User's Model Decision Tree on the Aggregator

Start with the task, not the model name

If you have never called an LLM API, the hardest part is usually not the code. It is choosing a model. On an aggregator, one API key reaches many models, so the decision is reversible. Work through the tree below in order and stop at the first answer that fits.

Step 1: Is the task mostly text in, text out?

• Yes, and the output should be short (classification, extraction, routing, short answers): start with a fast, lower-cost tier model. You can move up later if quality is not enough.
• Yes, and the output should be long or nuanced (summaries, rewrites, explanations, code generation): start with a mid-tier general model. Compare one or two alternatives on a small sample before committing.
• No, the task needs images or documents as input: choose a model that explicitly supports vision or file input. Do not assume every model in a family accepts the same inputs.

Step 2: Does the task need tool use or structured output?

• You need reliable JSON or a strict schema: prefer models with strong instruction-following and structured-output support. Test with a few real examples.
• You need function calling or multi-step agents: pick a model known for stable tool use, and keep the tool schema simple at first.
• Neither: you can stay with a general chat model and skip this branch.

Step 3: How sensitive is latency and volume?

• Interactive, low volume: a mid-tier model is usually fine. Measure the full round trip, not just the model call.
• Batch or background: you can use a stronger model because latency matters less.
• High volume: benchmark a smaller model against your quality bar. If it passes on a sample, use it for the bulk and reserve the stronger model for hard cases.

Step 4: Do you need a specific provider or family?

• You already know the behavior you want (for example, a particular Claude, GPT, DeepSeek, Qwen, GLM, or Kimi model): call it directly with the same key.
• You are comparing: send the same prompt and inputs to two or three candidates. Keep the winner and note the fallback.

Step 5: Are you cost-sensitive or contributing?

• You just want to call models: top up with USDC on Base, no KYC, and pay official price × 1.3. That multiplier is the aggregator's fee and applies across models.
• You can contribute a key: key contributors are credited official price × 1.1, or × 1.2 for premium keys, in USDC. This is a credit for usage, not a guarantee of income.
• Do not plan around a large discount. The pricing rule is fixed: pay × 1.3, contributor credit × 1.1 or × 1.2. Account for it in your budget.

Step 6: How will you validate before scaling?

• Write ten representative prompts with expected outputs.
• Run them against your first-choice model and one fallback.
• Check quality, latency, and token usage.
• Only then wire the model into your application, and keep the fallback model name in configuration.

A quick default path

1. Pick a mid-tier general model for your first call.
2. Send a small, real sample.
3. If quality is short, try a stronger model on the same sample.
4. If cost or latency is high, try a smaller model on the same sample.
5. Keep the best trade-off and record why you chose it.

Common first-time mistakes

• Choosing a model before describing the task.
• Assuming all models handle images, tools, or long context the same way.
• Testing with toy prompts instead of real inputs.
• Forgetting that pricing is official price × 1.3 for callers.
• Treating contributor credit as a promise rather than a usage-based credit.

What to do next

Create one API key, top up with USDC on Base if you have not already, and run the validation sample. Because the key works across models, you can change your decision later without changing your integration.