One Key to Call Them All — Including Your Roommate: When a Single Aggregator Key Is Shared by Several People

The appeal and the problem

A single API key that unlocks Claude, GPT, DeepSeek, Qwen, GLM, and Kimi is convenient. But when two or three people share that key—whether roommates splitting costs or a small team pooling resources—the convenience quickly turns into confusion. Every request looks the same in the logs, and you lose the ability to tell who made which call.

What sharing actually looks like

When multiple people use the same key, their requests are interleaved. Suppose Alice and Bob both send requests at the same time. The aggregator sees a stream of calls, but without additional context, it cannot distinguish Alice's prompt from Bob's. The usage records show timestamps, models, and token counts, but not the caller's identity. This becomes especially problematic when you want to attribute costs.

Why usage becomes indistinguishable

Most APIs, including this aggregator, identify usage by the key. If everyone uses the same key, all usage rolls up into a single bucket. There is no built-in per-user breakdown. You might see that 1,000 requests were made today, but not who made them. This lack of attribution makes it impossible to fairly divide the USDC spent.

The cost attribution problem

Since users pay official price × 1.3 in USDC, and contributors get credited official price × 1.1 (or × 1.2 for premium models) back, every call has a real cost. When sharing a key, you need to know who incurred which cost. Without that, you risk resentment or inaccurate reimbursements. For example, if one person uses an expensive model heavily while another uses a cheaper one sparingly, a simple split may not reflect actual usage.

Solutions for shared access

1. Use separate keys per person

The simplest fix is to create a separate API key for each user. Most aggregators allow multiple keys under one account. Each key can have its own usage tracking, making it easy to see who spent what. If your aggregator supports it, set spending limits per key to prevent surprises.

2. Tag requests with metadata

Some APIs allow you to attach metadata to each request. You can include a user identifier in a custom header or in the request body. Then, when reviewing logs, you can filter by that metadata. Check your aggregator's documentation for support for custom headers or tags.

3. Create separate projects or sub-accounts

If the aggregator offers project-based organization, create a project for each person. Each project gets its own key and usage dashboard. This is ideal for small teams that need clear separation.

4. Route through a lightweight proxy

For more control, set up a small proxy that sits between users and the aggregator. The proxy can add user identifiers to requests or route based on user credentials. This adds complexity but provides flexibility.

Best practices for shared usage

• Agree on a usage policy upfront. Decide how costs will be split and what models are allowed.
• Monitor usage regularly. Even with separate keys, check dashboards to catch unusual activity.
• Use the lowest-cost model that fits the task. This reduces overall spend and makes splitting easier.
• Document your setup. If you use metadata or proxies, write down how to interpret the logs so everyone can understand.

Conclusion

Sharing one API key across multiple people is technically feasible but creates attribution headaches. By using separate keys, metadata tagging, or project separation, you can maintain clarity and fairness while still enjoying the convenience of a single aggregator for all your model calls. The extra effort pays off in accurate cost sharing and happier collaborators.