Com fer servir les API de LLM: tokens, costos, claus i la teva primera funció amb IA

Una API de LLM és un servei web que permet a la teva app enviar text a un model de llenguatge gran, com els models GPT d’OpenAI, Claude d’Anthropic o Gemini de Google, i rebre’n la resposta des del codi. Et registres al proveïdor, crees una clau d’API, i el servidor de la teva app envia peticions amb aquesta clau; et cobren cada petició segons el nombre de tokens (trossos de text) que entren i que surten. Això és tot el que sol voler dir «afegir IA a una app»: una petició ben escrita a un model d’algú altre, feta de manera segura des del teu servidor.

Per què importa quan construeixes amb IA

Hi ha dues IA diferents en una app creada amb IA, i és fàcil confondre-les:

1. La IA que construeix la teva app: l’agent del constructor, que escriu el codi.
2. La IA dins de la teva app: una funció que fan servir els usuaris, com un assistent de xat, un botó de «resumeix això» o l’etiquetatge automàtic.

La segona crida una API de LLM amb la teva clau i factura al teu compte del proveïdor. Entendre els tokens, el context i els preus és el que et permet dissenyar una funció que funcioni, que no filtri la teva clau i que no et sorprengui amb una factura.

Una analogia quotidiana: un escriptor independent molt capaç, pagat per paraula

Pensa en una API de LLM com en un escriptor independent molt capaç a qui contactes per correu i pagues per paraula: tant per les paraules que li envies com per les que et torna (i les que et torna costen més).

• No té memòria entre correus. Si vols que continuï una conversa, enganxes els missatges anteriors en cada correu nou.
• Només pot llegir una quantitat limitada alhora. Aquest límit és la finestra de context.
• Com més clar sigui l’encàrrec, millor i més curta serà la resposta, cosa que també la fa més barata.

Els conceptes bàsics

Tokens

Els models llegeixen i escriuen text en tokens. La documentació de preus d’Anthropic estima unes 4 lletres, o uns 0,75 paraules en anglès, per token a setembre de 2026. Els diferents models i llengües es tokenitzen de manera diferent, així que pren-ho com una guia aproximada. Tot compta: les teves instruccions, el missatge de l’usuari, els documents que incloguis, la conversa prèvia i la resposta.

Entrada i sortida

Els tokens d’entrada són el que envies. Els tokens de sortida són el que escriu el model. A les pàgines de preus d’OpenAI, Anthropic i Google, a setembre de 2026, els tokens de sortida costen diverses vegades més que els d’entrada per al mateix model. La pàgina de preus de Gemini de Google també indica que el «pensament» intern del model compta com a sortida.

Finestra de context

El nombre màxim de tokens que un model pot acceptar en una sola petició, incloent-hi la resposta. Els models actuals accepten entrades molt llargues: alguns models actuals d’Anthropic, per exemple, accepten fins a un milió de tokens. Però les entrades llargues costen més i tarden més, així que envia només el que la tasca necessita.

Peticions sense estat

Amb la majoria d’API de tipus xat, cada petició és independent per defecte. Perquè el xat «recordi», la teva app torna a enviar els missatges anteriors amb cada nou missatge. Per això una conversa llarga costa més per missatge que una de curta.

El prompt de sistema

Són les instruccions que defineixen el rol i les regles del model per a cada petició: «Resumeixes tiquets de suport en tres punts. Mai incloguis adreces de correu dels clients.» Els usuaris no el veuen, però condiciona cada resposta.

Streaming

En lloc d’esperar la resposta completa, l’API pot enviar el text a mesura que es genera, de manera que els usuaris veuen les paraules aparèixer a l’instant. Això fa que les interfícies de xat se sentin molt més ràpides.

Com funcionen els preus

A setembre de 2026, segons les pròpies pàgines de preus dels proveïdors:

Alguns proveïdors també ofereixen una manera de provar abans de pagar: Anthropic dona als usuaris nous un petit crèdit gratuït, i l’API de Gemini de Google té un nivell gratuït en alguns models, amb l’advertència que el contingut enviat en aquest nivell pot fer-se servir per millorar els productes de Google.

Els preus difereixen molt entre els models petits i ràpids d’un proveïdor i els més grans, i canvien sovint, així que no els citem aquí. Una estimació senzilla per a qualsevol funció és: (tokens d’entrada × preu d’entrada + tokens de sortida × preu de sortida) × nombre de peticions al mes. Després hi afegeixes un marge i estableixes un límit de despesa mensual al tauler del proveïdor.

Un exemple pràctic: un botó per «resumir aquest tiquet»

Un petit equip de suport vol un botó que converteixi un fil llarg de correus de clients en tres punts i una resposta suggerida.

1. Obtén una clau. Crea un compte amb un proveïdor i genera una clau d’API. Estableix un límit de despesa mensual baix.
2. Guarda la clau com a secret al servidor, amb un nom com ANTHROPIC_API_KEY o OPENAI_API_KEY, mai al codi de la pàgina. Consulta variables d’entorn i secrets.
3. Afegeix una ruta al servidor, POST /api/summarise, que:
   • comprovi que la persona ha iniciat sessió i que pertany a l’equip de suport;
   • carregui el tiquet de la base de dades;
   • enviï al proveïdor un prompt de sistema («Resumeix en tres punts i després redacta una resposta cortès; no inventis números de comanda») més el text del tiquet;
   • limiti la llargada de la resposta amb un paràmetre de tokens de sortida màxims;
   • retorni el resultat i registri quants tokens ha fet servir.
4. El botó crida la teva ruta, no el proveïdor, i mostra el resum mentre es va generant.
5. Gestiona els errors. Si el proveïdor triga o retorna un error, mostra «No s’ha pogut resumir ara mateix» i deixa el tiquet utilitzable.
6. Mesura. Després d’una setmana, mira els registres de tokens. Si la major part del cost són fils de correu llargs, retalla l’historial citat abans d’enviar-lo.

Fixa’t en què no hi ha: cap entrenament de models, cap infraestructura especial. Una clau, una ruta al servidor i un prompt ben escrit.

Termes clau

• Clau d’API: el secret que identifica el teu compte davant el proveïdor. Qui la tingui pot gastar els teus diners.
• Model: el LLM concret que crides. Els proveïdors ofereixen diverses mides a preus i velocitats diferents.
• Temperatura: un paràmetre que controla la variació de les respostes. Com més baixa, més previsibles.
• Tokens màxims: un límit a la llargada de la resposta, que també limita el cost.
• Límit de freqüència: quantes peticions o tokens pot fer servir el teu compte per minut.
• Embeddings: nombres que representen el significat d’un text, fets servir per cercar als teus propis documents.
• RAG (generació augmentada per recuperació): trobar fragments rellevants de les teves dades i incloure’ls al prompt perquè el model respongui a partir del teu contingut.
• Ús d’eines / crida de funcions: deixar que el model demani a la teva app que executi una funció concreta, com «consulta l’estat de la comanda».

Errors habituals i idees equivocades

• Posar la clau al codi del frontend. L’error més car. El codi del navegador és públic. Crida sempre des del servidor. La llista de comprovació de seguretat per a apps creades amb IA tracta això juntament amb altres revisions abans del llançament.
• Cap límit de despesa ni límits per usuari. Un error, un bucle o un usuari abusiu poden disparar els costos ràpidament. Estableix un límit al proveïdor i limita les peticions per usuari a la teva app.
• Enviar-ho tot sempre. Els documents sencers i els historials de xat complets multipliquen els tokens d’entrada. Retalla, resumeix els missatges més antics o recupera només les parts rellevants.
• Confiar cegament en la sortida. Els models poden afirmar coses incorrectes amb molta seguretat. Per als fets, els preus o qualsevol cosa legal o mèdica, fonamenta les respostes en les teves dades i mostra les fonts, o fes que una persona ho revisi.
• Deixar que l’entrada de l’usuari anul·li les teves regles. Els usuaris poden escriure «ignora les teves instruccions». Mantén els permisos i les accions sensibles al codi del servidor, no només al prompt.
• Començar amb el model més gran. Prova primer un model més petit i més barat; puja només si la qualitat ho exigeix.
• Enviar dades personals sense pensar-hi. Revisa les condicions d’ús de dades del proveïdor, sobretot als nivells gratuïts, i envia només el que la funció necessita.

Què demanar al teu constructor d’IA

Afegeix un botó «Resumeix» a la pàgina del tiquet. Crida una ruta del servidor que fa servir el secret OPENAI_API_KEY (mai exposat al navegador), comprova que l’usuari ha iniciat sessió, envia el text del tiquet amb aquest prompt de sistema: […], limita la resposta a 300 tokens, transmet la resposta a la pàgina i mostra un error amable si la crida falla. Registra els tokens utilitzats per petició i limita cada usuari a 30 resums per hora.

Per a una experiència de xat completa, consulta com construir una app de chatbot amb IA; per a altres idees, com afegir funcions d’IA a la teva app. Si les API en general són noves per a tu, comença per què és una API.

Les API de LLM en apps creades amb Mythex

Quan construeixes amb Mythex, la IA que hi ha dins de la teva app fa servir la teva pròpia clau del proveïdor. L’afegeixes com a secret del projecte, o a través de la targeta de secrets que Mythex mostra al xat quan en fa falta una, i demanes a l’agent que faci la crida al servidor. L’ús del proveïdor es factura al teu compte del proveïdor, no als crèdits de construcció de Mythex. Mythex no inclou tokens per als usuaris de la teva app ni un producte de base de coneixement integrat, i els límits de freqüència i els controls de cost són cosa teva per dissenyar-los i provar-los. La recepta de la documentació afegir funcions d’IA amb les teves pròpies claus d’API té un prompt d’inici, i la pàgina constructor d’apps amb IA mostra per on començar.

Preguntes