Running a research lab on one LLM API account: one key per student and per project

The simplest way for a research lab to use LLM APIs is one account for the whole group. The PI or lab manager registers it and tops it up, then creates an API key for every student and every project, with a spending cap from the budget, an expiry at the end of the term or project, and model limits that allow only the models needed. Every call is recorded under the key that made it, so exporting Logs by key at month end splits the bill by student and project, and invoices for reimbursement are requested with the top-up order numbers. When a student graduates or leaves, disable their key; scripts that pull usage on a schedule use a scoped personal access token, never the account password.

Who owns the account

• The PI or a lab manager (the owner below) registers the account and handles top-ups, keys and reconciliation. An account has no member sub-accounts: students do not sign in to the console and never get the password.
• The owner turns on two-step verification under Account settings → Security and checks the Security log regularly; it records creating, editing, enabling or disabling, deleting and revealing API keys.
• All keys share the account balance. ¥1 buys ¥1 of credit, deducted by actual usage, with no monthly fee and no minimum spend commitment.

Splitting keys across students and projects

One key per person or purpose, with a name that says who it belongs to, so Logs show where the money went:

What to set on each key

Set these when you add or edit a key on the API keys page; changes apply immediately:

• Quota cap: the most this key can spend in total. At the cap the key stops working and other keys are unaffected. The cap is cumulative and does not reset each month; for a monthly budget, set it at the start of each month to the amount used plus this month's budget.
• Expiry: quick picks from 1 hour to 1 year, or a date. Match the term, the project or the collaboration, and the key stops on its own.
• Model limits: with "Only allow selected models" on, the key can call only the models you tick. Allowing only the models an experiment needs means a mistyped model name never reaches an expensive flagship model.
• Group: decides the line and the price. When results go into a paper and you need to say where the model came from, choose a group labeled Official; see How to choose a group.
• IP allowlist: only requests from the listed IPs or ranges are accepted, which suits keys that run on a lab server.

What each limit returns when it is hit, and how to split keys by environment, is covered in Teams and multiple projects on one account.

Top-ups and balance alerts

• Online: on the Top up page of the console, choose a payment method and an amount; the methods are whatever the console shows, and the balance is credited once payment succeeds.
• Redemption codes: if your university buys through procurement or pays by bank transfer, contact support and pay offline; support sends a redemption code that you redeem on the Top up page. For bulk purchasing, see Enterprise.
• Balance alerts: under Account settings → Balance alerts, turn on the low-balance alert. When the balance drops from above the threshold to below it, you get one notice by email or webhook. The whole lab shares one balance, so send alerts to a shared lab mailbox rather than to one person.

Monthly reconciliation

1. In Logs, select last month in full, set the log type to Usage and choose Export to download a CSV; then switch the type to Refund and export again.
2. Sum Cost (¥) by the API key column and subtract refunds to get each student's and project's spend; add up the keys that belong to the same grant.
3. For a quick look at one key, choose View usage in that key's menu on the API keys page, or filter Logs by API key name and turn on Show stats to see Spend in period.
4. Keys and groups on the Dashboard sums spend by key, group and model, which shows each project's share; the Dashboard is for reference, and Logs are the record of actual charges.
5. File invoices, top-up records and the exported CSVs together so they match up at reimbursement and at the end of a grant.

Export details (at most 20,000 records per export, dates in your browser's time zone, the group column of the CSV) and a summing script are in Cost allocation and reconciliation.

Invoices and reimbursement

We issue both China domestic invoices (fapiao) and overseas invoices: add our WeChat support JsnonoChat and send the order number. Copy order numbers from All records on the Top up page. Which documents reimbursement needs, and which budget line the cost goes under, is up to your university's finance office.

When students graduate or leave

Disabling beats deleting: a disabled key can be turned back on at any time, while a deleted key only shows as a deleted key with its id under Keys and groups on the Dashboard, which makes reviewing a student's usage harder.

Personal access tokens for reporting scripts

To pull usage every month or check the balance on a schedule, create a personal access token under Account settings → Access tokens rather than putting the account password in a script:

1. Grant only the permissions the script needs, such as "View usage logs, statistics and security log" and "View balance and top-up history".
2. Pick an expiry: 7, 30, 90 or 365 days, or never.
3. You verify your identity to create it, and the token is shown only once, so store it somewhere safe right away.
4. The script sends it in the request header Authorization: Bearer <token> when it calls the console API.

Personal access tokens are not API keys: students get API keys, which call models; access tokens call the console API and stay in scripts the owner runs.

How students use their keys

• Keep the key in an environment variable on the server or on their own computer, never in code, a code repository or a group chat.
• The API address is https://www.tutujin.com/v1; OpenAI-compatible SDKs work after changing base_url and api_key; see the Quickstart.
• Record the model ID, parameters and call dates with every experiment; see Research and universities.

A checklist for each term

For what labs commonly build, see Research and universities, LLM evaluation and benchmarking, Social science text analysis and qualitative coding and Literature reading and review support.