One Aggregator Balance, Five Side Projects: Attributing Usage Without Separate Accounts
Learn a simple tagging convention to track USDC usage across multiple side projects when using a single aggregator API key. Attribute costs accurately without opening separate accounts.
Why attribute usage?
When you run several weekend experiments through one API aggregator, your USDC balance drains without telling you which project caused it. Without attribution, you can't budget, compare model choices, or decide what to kill.
A lightweight tagging convention
You don't need separate accounts. You need to attach a consistent project identifier to every API call and log it. Three practical options:
- Request metadata: Many APIs accept a user-defined field (often called
metadataoruser). Set it to your project slug, e.g.weekend-rag-bot. - Per-project keys: If the aggregator lets you create multiple API keys under one balance, issue a key per project. Then your provider's usage dashboard shows spend per key.
- Log filename prefixes: If you log responses locally, prepend the project slug to each log file, e.g.
projweatherbot2025-04-05.jsonl.
Implementing the convention
- Choose a slug format: short, lowercase, hyphenated. Stick to it.
- Centralize slug injection: In your shared API wrapper, read the slug from an environment variable or config file, then pass it as metadata or use the matching key.
- Log the slug with every request: Include it in your local logs alongside the model, token counts, and timestamp.
- Aggregate locally: Write a tiny script to sum token usage per slug from your logs. Multiply by the official price and then by 1.3 to get your actual USDC cost.
Getting cost from usage
You pay official price × 1.3. If you are a key contributor, you are credited official price × 1.1 (or × 1.2 for premium models) in USDC. So your net cost per call is:
- User:
official_price * 1.3 - Contributor:
official_price * 1.1(or* 1.2for premium)
Apply that multiplier to the official price of the model you called, times the tokens used. Your tagging lets you do this per project.
Example: tagging with request metadata
If the aggregator supports metadata, your wrapper might look like:
def call_model(project_slug, model, prompt):
headers = {
"Authorization": f"Bearer {API_KEY}",
"Content-Type": "application/json",
}
payload = {
"model": model,
"messages": [{"role": "user", "content": prompt}],
"metadata": {"project": project_slug},
}
response = requests.post(API_URL, json=payload, headers=headers)
# Log usage with project_slug
log_usage(project_slug, response)
return response
Then later query your logs or the aggregator's metadata filter to see spend per project.
Best practices
- Be consistent: Always use the same slug format.
- Document your slugs: Keep a simple README or comment listing all active projects.
- Review regularly: Check per-project usage weekly to catch runaway experiments.
- Automate reporting: A small script that outputs a table of project, tokens, and USDC cost saves time.
Conclusion
With one aggregator balance and a simple tagging rule, you can attribute usage to each side project. No separate accounts, no KYC, just clear visibility into which experiment is eating your USDC.