Three Team Shapes, One API Key: Solo Dev, Pair, and a Small Squad Sharing a Single Aggregator Key

Why Share a Single Key?

Using one aggregator key across a team simplifies billing and access. Instead of managing multiple accounts, you top up once with USDC on Base (no KYC) and everyone calls models like Claude, GPT, DeepSeek, Qwen, GLM, and Kimi through the same key. But sharing requires conventions to prevent collisions and keep costs transparent.

Solo Developer

As a solo dev, you are the only user. Your main concerns are tracking spend and avoiding accidental overuse.

• Set a budget alert: Most aggregators let you set a spending limit or alert. Use it to avoid surprises.
• Tag requests: If the API supports metadata, add tags like project:myapp to distinguish usage across your own projects.
• Rotate keys periodically: Even solo, rotate your key if you suspect exposure.
• Monitor usage: Check your dashboard regularly to understand your consumption patterns.

Since you pay official price × 1.3, keeping an eye on usage helps you optimize.

Pair (Two Developers)

When two people share a key, coordination becomes essential. Without conventions, you might duplicate work or exceed budgets.

• Agree on a spending split: Decide how you will divide the cost. Since billing is unified, you can track each person's usage via tags or separate API keys if the aggregator allows sub-keys.
• Use request tags: Tag requests with dev:alice or dev:bob to attribute usage.
• Communicate about model choices: If one person uses an expensive model for experiments, the other should know. Set a guideline for which models are appropriate for which tasks.
• Rotate keys when roles change: If one person leaves the project, rotate the key immediately.

If your aggregator supports multiple keys under one account, consider issuing separate keys per person for better isolation.

Small Squad (3–10 People)

With more people, you need clearer structure. Without it, usage can become opaque and costs can spiral.

• Designate a key administrator: One person manages the key, rotates it, and monitors overall usage.
• Issue sub-keys if possible: If the aggregator allows creating multiple keys under one account, assign each team member their own key. This provides individual usage tracking and easy revocation.
• Establish naming conventions for tags: Use consistent tags like team:backend, project:chatbot, or env:staging to categorize requests.
• Set a shared budget and review regularly: The admin should review usage weekly and share summaries with the team.
• Document model access policies: Specify which models are approved for which purposes (e.g., production vs. experimentation).
• Onboard and offboard rigorously: When someone joins or leaves, update key access promptly.

Remember, contributors to the aggregator (e.g., open-source maintainers) get credited official price × 1.1 (or × 1.2 for premium) in USDC, which can offset costs if team members contribute.

Common Conventions for All Shapes

Regardless of team size, these practices help:

• Use environment variables: Never hardcode the key in source code. Store it in environment variables or a secrets manager.
• Implement retry and fallback logic: Handle rate limits and errors gracefully to avoid unnecessary retries that increase cost.
• Log request metadata: Keep logs of model used, tokens consumed, and tags for auditing.
• Review usage before topping up: Understand where your USDC goes.
• Stay informed about pricing: You pay official price × 1.3, so factor that into budgeting.

Conclusion

A single aggregator key can serve solo devs, pairs, and small squads efficiently. The key is to adopt conventions that match your team shape: simple tracking for solo, clear communication for pairs, and structured access control for squads. By doing so, you avoid stepping on each other's toes and keep costs predictable.