Skip to content
TutujinAPI

LLM API guides

The 13 questions that come up most when you integrate an LLM API. Each guide starts with the answer, then explains it with concrete numbers and examples. Price examples are calculated from the live price list.

  1. A token is the unit a model reads and writes in, and the unit LLM APIs bill by. How tokens map to words, what counts as input and output, and what one request and one month cost at live prices.

    01Read
  2. LLM APIs bill three ways — input and output tokens priced separately, cached input at a lower rate, and per request for image models — and the same model costs different amounts in different groups. Worked examples at live prices.

    02Read
  3. Start from task difficulty — small, cheap models for classification, extraction and rewriting; mid-tier models for Q&A, summaries and writing; flagship or reasoning models for hard multi-step work. A tier table, an evaluation script and live price comparisons.

    03Read
  4. Context caching bills a prompt prefix you send again and again at a lower cache-read price. How OpenAI, Claude, Gemini and DeepSeek handle caching, how to write prompts that hit the cache, and how much it saves at live prices.

    04Read
  5. An OpenAI-compatible API keeps OpenAI's paths and request format, so the official SDKs, LangChain, Dify, n8n and other tools connect by changing base_url and the key. Which endpoints this site supports, how to migrate, and how compatible and native APIs differ.

    05Read
  6. Moving to Tutujin API usually means changing base_url, api_key and the model names. Check the model list, streaming, error codes and rate limits before launch, then shift traffic in stages and keep the old service until things are stable. A checklist, percentage-based routing code and a rollback plan.

    06Read
  7. A group decides which line an API key uses and which price tier it pays. What the lowest-price, official, cloud and mixed-sources labels mean, which group to use for development, batch jobs, production and failover, and live price differences for the same model across groups.

    07Read
  8. One API key can use up to 5 groups in priority order. Each request uses the first group that offers the model and is billed at that group; with cross-group retry on, a request that keeps failing moves to the next group. How switching works, how to order groups, console setup and when separate keys fit better.

    08Read
  9. LLM API spend comes down to unit price, input length, output length and call volume. Ten measures roughly in order of impact — choosing the right model tier, tiered routing, context caching, capping output and per-key spending limits — with savings shown at live prices.

    09Read
  10. Allocating LLM API costs by project starts with one key per project. Logs record every call's cost under its key and export to CSV; the Dashboard sums spend by key, group and model. How to split the bill, monthly reconciliation steps, export limits and how to request invoices.

    10Read
  11. Whoever holds your API key can spend your balance. Eight practices — server-side use only, environment variables or a secrets manager, one key per project and environment, spending limits and expiry, IP and model allowlists, rotation, watching usage — plus what to do after a leak.

    11Read
  12. An account has no member sub-accounts, so teams split access and spend with API keys — one per member, project and environment, each with its own cap, expiry, model limits, IP allowlist and group. Usage per key in Logs and on the Dashboard, CSV exports for finance, access tokens for scripts and two-step verification for the owner.

    12Read
  13. The PI or lab manager opens one account and tops it up; every student and project gets its own API key with a spending cap, expiry and model limits. Usage per key in Logs for monthly reconciliation, invoices by order number for reimbursement, disabled keys when students leave and access tokens for scripts.

    13Read