How to Set Up an LLM: A Clear Path for Developers

Setting up an LLM means making three decisions in order: where the model runs, how your application talks to it, and how you manage keys, cost, and access as usage grows. Most guides skip straight to code and leave out the part that actually determines whether your setup works six months from now — the infrastructure choice.

If you're building a product feature, an internal tool, or a prototype, the fastest and most reliable path is a hosted API from a model provider (OpenAI, Anthropic, Google) or a gateway service sitting in front of one. Self-hosting an open-weight model only makes sense if you have specific requirements around data residency, cost at very high volume, or offline use. This article walks through both paths, but focuses on the hosted route since that's what most teams should actually do first.

Step 1: Decide where the model runs

Hosted API (recommended default) You send HTTP requests to a provider's endpoint and get responses back. No GPUs, no model weights to manage, no inference optimization. You pay per token or per request. This is the right choice for almost every product use case, especially early on.

Self-hosted (only when you need it) You run the model yourself — locally on a workstation with enough VRAM, or on a cloud GPU instance. This gives you full control over data and no per-token billing, but you take on model serving, scaling, and update work yourself. Reasonable if you have strict compliance needs or genuinely massive, predictable request volume.

For most teams, "setting up an LLM" really means setting up reliable, authenticated access to a hosted model, not standing up your own inference stack.

Step 2: Get access and an API key

Once you've picked a provider, you need an account and an API key. If you're using Claude specifically, you have two common routes:

1. Direct provider access — sign up with Anthropic, generate a key, and call their API directly.
2. A wrapper/gateway service — sign up once, get an application key, and route calls through that instead of managing raw provider credentials in every app you build.

The second option matters if you're building more than one thing on top of Claude, or if you want usage metadata and team-level key management without building that tooling yourself. SubToAPI, for example, turns your existing Claude access into a standard HTTPS API: you get application keys prefixed sub_live_..., streaming support, tool use, and per-key usage data in one dashboard, without writing your own billing or key-rotation layer. Plans start at €9/month for solo use, with team seats above that — see /pricing.

Either way, the setup pattern is the same: get a key, store it as an environment variable, never hardcode it, and never commit it to version control.

export SUBTOAPI_KEY="sub_live_xxxxxxxxxxxxxxxx"

Step 3: Make your first request

Once you have a key, test it with a minimal request before wiring anything into your app. This confirms auth works and gives you a baseline for latency and response shape.

curl https://api.subtoapi.app/v1/messages \
  -H "Authorization: Bearer $SUBTOAPI_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "claude-sonnet-4-5",
    "max_tokens": 256,
    "messages": [
      {"role": "user", "content": "Say hello in one sentence."}
    ]
  }'

If that returns a clean JSON response with a message body, your setup is working. Full request/response details are in /docs/messages, and a step-by-step first-integration guide is at /docs/quickstart.

Step 4: Wire it into your application

From here, setup is standard backend work:

• Put the API call behind your own backend route — never call the LLM API directly from client-side JavaScript, since that exposes your key.
• Decide on streaming vs. non-streaming responses. Streaming improves perceived latency for chat-style UIs; see /docs/streaming for the event format.
• If your use case needs the model to call functions (lookups, calculations, database queries), set up tool definitions rather than trying to parse free-text output — see /docs/tools.

A minimal server-side call in JavaScript:

const response = await fetch("https://api.subtoapi.app/v1/messages", {
  method: "POST",
  headers: {
    "Authorization": `Bearer ${process.env.SUBTOAPI_KEY}`,
    "Content-Type": "application/json"
  },
  body: JSON.stringify({
    model: "claude-sonnet-4-5",
    max_tokens: 512,
    messages: [{ role: "user", content: "Summarize this in two lines: ..." }]
  })
});

const data = await response.json();
console.log(data);

Step 5: Add guardrails before you ship

A working call is not a finished setup. Before this goes to real users, add:

• Rate limiting on your own endpoints, separate from provider-side limits.
• Input length caps so a single request can't blow through your token budget.
• Error handling for timeouts and rate-limit responses, with retries and backoff.
• Logging of token usage per request so you can catch cost spikes early — this is where per-key usage dashboards (available in SubToAPI's dashboard) save time versus building your own metering.

Step 6: Plan for teams and scale

If more than one person or one app will use the setup, avoid sharing a single API key across everyone. Issue separate keys per developer or per application so you can revoke access individually and see usage broken down by key. This is a common gap in DIY setups — most provider dashboards give you one account-level key, not per-app keys with individual usage stats. If you need that structure without building it, a Team plan (€19/seat) or Scale plan (€49/seat) on SubToAPI gives you seat-based key management out of the box. You can try the whole flow with a free trial at /signup.

Summary checklist

• Choose hosted API over self-hosting unless you have a specific reason not to.
• Get an API key and store it as an environment variable.
• Make one test call before integrating anything.
• Put the LLM call behind your own backend, not client-side code.
• Add rate limits, input caps, and usage logging before launch.
• Use per-developer or per-app keys once more than one consumer exists.

questions

Do I need my own server to set up an LLM? No. For hosted APIs you only need a backend route that forwards requests with your API key — no GPU or model hosting required. Self-hosting is only necessary for offline use, strict data residency, or very high sustained volume.

What's the minimum I need to get started? An API key, an environment variable to store it, and one test request. From there you build out streaming, tool use, and rate limiting as your application needs them.

How do I avoid exposing my API key? Never call the LLM API from client-side JavaScript or mobile code directly. Route all requests through your own backend, keep the key in server-side environment variables, and rotate it if you suspect it's been exposed.