AI Features

This skill covers the model as a component of your product: your server calls an LLM, your users see the result, and you get the invoice. It prevents the four ways this goes wrong: unbounded spend, invented facts, silent failures, and tests that pass while the feature is broken.

Analogy: the model is a brilliant temp worker with no memory of your business and no sense of what things cost. You don't hand them the company card and the customer list and leave. You give them a brief, a spending limit, a rule that says "if it's not in the file, say you don't know", and someone to call when they're stuck.

Discovery (max 3 questions, only if unknown)

1. What does the model do — talk to end users, or produce something your code then uses (a score, a summary, a category)?
2. Who pays for the calls — you, or each customer with their own key?
3. Where does the call run — a serverless function, an automation tool, a long-lived server?

Step 1 — Credentials and who pays (decide before writing code)

• A product uses API keys, never a personal subscription. Consumer plans (the kind you log into as a person) are licensed for individual use; routing your users' work through one — yours or theirs — is typically prohibited by the provider's terms and can be cut off without notice. Read the current terms of your provider before designing around a subscription.
• Your key, you pay: simplest. Price it into the plan and enforce a quota (Step 4).
• Bring-your-own-key: each customer pastes their key. You owe them a ledger — cost per run, per model — and their key is a secret you now store (server-only table, never returned to the browser).
• One provider account per product, with a low-balance alert. A balance shared across projects ran dry and took a production bot down with a payment-required error; a "workspace" inside one account did not separate the balance.
• Keep the provider swappable: one module wraps the call (base URL, key, model from config). You will change models more often than you expect.