Una app con Google AI Studio y los modelos lite gratis

Google AI Studio es el sitio donde se prueba un prompt antes de convertirlo en algo, y donde se saca la clave para llamarlo desde tu web. Lo importante no es la pantalla: es que entre probar una idea y tenerla funcionando hay una tarde, y que en el camino hay tres o cuatro cosas que, si no sabes, te cuestan una semana.

Para qué	Dónde
Probar el prompt y ajustarlo	AI Studio, en el navegador
Fijar cómo tiene que responder siempre	Las instrucciones de sistema de AI Studio
Sacar la clave para tu web	AI Studio → «Get API key»
Que lo use la gente	Tu servidor, con la clave escondida ahí

Todo lo que ajustes en AI Studio es lo que después pones en tu código. Las instrucciones de sistema, el modelo y el tope de longitud se copian tal cual. Por eso conviene dejar el prompt ya afinado ahí antes de escribir una sola línea: probar cambios de texto en la pantalla es instantáneo y probarlos desplegando es lentísimo.

Qué significa «modelo lite gratuito» de verdad

Los modelos «lite» son las versiones pequeñas y rápidas de la familia, y tienen un tramo de uso sin coste. Pero hay tres cosas que casi nadie explica y que cambian cómo se diseña una aplicación entera:

El tramo gratuito es una cuota diaria, no un «gratis» sin fondo. Se agota, y cuando se agota la API responde con un error — no con una factura, pero tampoco con una respuesta.
Cada modelo tiene su cuota SEPARADA. Esta es la buena, y de aquí sale casi toda la lección: si el pequeño se agota, el siguiente conserva la suya entera.
Escribir cuesta bastante más que leer. La diferencia de precio entre modelos está sobre todo en lo que producen, no en lo que les mandas.

No pongo aquí las cifras de cuota ni las tarifas: cambian cada pocos meses y una lección con números caducados es peor que una sin ellos. Lo que no cambia es la mecánica, que es lo que se aprende.

Y antes de meter nada: lo que se envía a la API sale de tu farmacia. Sirve para un texto de una campaña, para clasificar tus propias ventas o para el chatbot del horario. No para el informe de un paciente. El criterio completo está en la primera lección.

De AI Studio a una app, en cuatro pasos

Afina el prompt en la pantalla

Con las instrucciones de sistema escritas —lo que hace, en qué formato y qué hacer cuando no sepa— y probado con cinco entradas distintas, no una. Una entrada basta para creer que funciona; cinco enseñan por dónde se rompe.

Y si necesitas la respuesta en un formato fijo para que tu código la lea, dilo ahí y compruébalo ahí mismo.
Saca la clave y guárdala en Vercel

En las variables de entorno del proyecto, nunca en el código ni en el repositorio (lección 4). Y la llamada la hace tu servidor: si la clave baja al navegador, la gasta cualquiera.
Pon una cascada de modelos, del barato al caro

Aquí está el truco que convierte el tramo gratuito en algo con el que se puede contar. Como cada modelo tiene cuota separada, defines una lista y, si el primero contesta que se ha agotado, pruebas el siguiente.
```
// del más barato al más caro
const MODELOS = ['...-flash-lite', '...-flash', '...-pro'];

for (const modelo of MODELOS) {
  const r = await llamar(modelo, prompt);
  if (r.ok) return r;          // salió: se acabó
  if (esFalloDelModelo(r)) continue;   // ese modelo no vale: siguiente
  // cualquier otro fallo: también se sigue (ver abajo)
}
```
El orden decide qué cuota gastas primero, no cuánta tienes. Poner el caro al final no te resta margen: hace que sólo se llegue a él cuando los baratos se han agotado.
Cachea, o pagarás por la misma respuesta cien veces

Si dos personas preguntan lo mismo, la segunda no tiene por qué costar. En una herramienta de farmacia la repetición es enorme: aquí, de las consultas del chequeador de interacciones, una de cada tres combinaciones ya se había preguntado antes.

Guarda también el fallo con una ventana corta —veinte minutos— o un mal rato se convierte en una llamada por visita hasta agotar el día.

Cuatro cosas aprendidas a base de romperlas

Lo que parece razonable	Por qué está mal
«Si devuelve un error de petición, corto la cascada: el prompt es malo»	No. Ese error casi siempre viene de que UN modelo rechaza un campo del cuerpo, no de tu texto. Cortar ahí deja la herramienta muerta cuando bastaba con probar el siguiente — y ese fallo no consume cuota. Sólo se avisa de «prompt rechazado» cuando fallan todos.
«Si la llamada no da error, tengo respuesta»	No. Puede volver correcta y vacía. Aquí hubo un modelo con 91 llamadas y cero fallos registrados que no había producido ni una frase. Comprueba que hay texto.
«Bajo el tope de longitud para gastar menos»	Cuidado. En los modelos que razonan, ese tope se comparte con el razonamiento: puedes dejarlo sin margen para escribir nada y llevarte una respuesta vacía. Aquí pasó con un tope que parecía de sobra.
«Le pido texto y le fuerzo formato de datos, por si acaso»	No. Si el prompt pide una frase, obligar a un formato de datos hace que la respuesta no se pueda leer y se queme la cascada entera.

Y una decisión de arquitectura que ahorra meses: la lista de modelos y sus precios en un solo fichero, que importe todo lo demás. Aquí llegó a haber seis copias con órdenes distintos, y una apuntaba a un modelo retirado: siete de sus últimas ocho llamadas fallaban y nadie se había enterado.

Qué construir primero

Lo que ya haces a mano cada semana y no lleva datos de nadie. Tres que funcionan bien y se montan en una tarde:

Clasificar tus propias ventas en categorías tuyas, a partir del CSV que exporta tu programa de gestión.
Redactar la ficha de un producto para la web a partir de sus datos — con el revisor de afirmaciones de la lección de la web detrás.
Resumir lo que te preguntan los clientes por WhatsApp para decidir qué contestar en la web de una vez.

De la prueba a algo publicado: los cuatro pasos

AI Studio es un sitio donde probar prompts contra un modelo y ver qué sale. Es excelente para eso y no es un hosting: lo que montes ahí no es tu app. La confusión es habitual y cuesta días, así que conviene tener claro el camino entero desde el principio.

Afinar el prompt en AI Studio, con ejemplos reales

Aquí es donde se trabaja de verdad. Pega cinco o seis casos de los difíciles —no de los fáciles— y reescribe el prompt hasta que los cinco salgan bien. Un prompt afinado contra los casos fáciles se cae el primer día.
Sacar la clave y guardarla donde toca

Una sola vez. Va a una variable de entorno de tu servidor, nunca a un fichero del repositorio y nunca al navegador.
Llamar desde TU función, no desde el navegador

Es la misma pieza de la lección del chatbot y por las mismas dos razones: la clave y los topes. Sin ella no hay app: hay una clave publicada.
Guardar lo que pasa

Modelo, tokens, si hubo error y cuánto tardó. Sin esto no se puede saber si funciona, ni cuánto cuesta, ni por qué un día dejó de ir.

El botón de «obtener código» de AI Studio te da un fragmento con la clave dentro. Sirve para probarlo en tu ordenador y nada más. Copiado tal cual a una web, esa clave viaja a cada visitante — y a partir de ahí cualquiera puede gastarla. Es el error número uno de quien empieza por aquí, y no da ningún aviso: funciona perfectamente.

Qué significa «modelo lite gratuito», exactamente

Lo que la gente entiende	Lo que es
«Es gratis»	Hay un tramo gratuito con límites por minuto y por día. Pasado eso, o pagas o esperas a mañana
«Lite es el modelo malo»	Es el rápido y barato. Para clasificar, extraer y resumir suele ser indistinguible del grande — y va tres veces más rápido
«Si me quedo sin cuota, se acabó»	Cada modelo tiene su cuota SEPARADA. Ésa es la base de la cascada
«Lo caro es la pregunta»	Lo caro es la respuesta. Escribir cuesta varias veces más que leer

La tercera fila es la que hay que interiorizar. Que cada modelo tenga cuota separada significa que el orden en el que los pruebas decide cuál se gasta primero, no cuánta cuota tienes en total. Poner el caro el último no te resta margen: hace que sólo se llegue a él cuando los baratos ya se agotaron.

La cascada, con código y con las tres reglas que la sostienen

Una cascada que aguanta

// ⚠️ UNA sola lista, en UN solo fichero. Copiarla en cada
// endpoint es como se acaba con seis versiones y una de ellas
// apuntando a un modelo que ya no existe.
const MODELOS = ['lite-barato', 'medio', 'lite-nuevo'];   // barato -> caro
const caidos = new Set();   // se olvida al reiniciar, a proposito

async function preguntar(cuerpo) {
  let ultimo = null;
  for (const modelo of MODELOS) {
    if (caidos.has(modelo)) continue;
    const r = await llamar(modelo, cuerpo);

    if (r.ok && tieneTexto(r)) return { ...r, modelo };

    // El modelo no existe o rechaza un campo: lo apartamos y seguimos.
    if (esFalloDelModelo(r)) { caidos.add(modelo); ultimo = r; continue; }

    // ⚠️ Cualquier otro fallo TAMBIEN sigue. Ver la regla de abajo.
    ultimo = r;
  }
  throw new Error('Ningun modelo respondio: ' + (ultimo?.motivo || 'sin detalle'));
}

Un error de petición NUNCA corta la cascada

El razonamiento tentador es «si el prompt está mal, repetirlo con otro modelo sólo gasta cuota». Las dos mitades son falsas: un rechazo así falla al instante y sin consumir cuota de generación, y en la práctica viene de que UN modelo no admite un campo del cuerpo, no de que el prompt esté mal.

Compara los costes de equivocarte: si sigues con un prompt malo pierdes dos fallos instantáneos. Si cortas con un modelo malo, tu web se queda sin la herramienta. No hay color.
Una respuesta correcta SIN TEXTO es un fallo

Es el fallo más traicionero de todos: el servidor responde que todo ha ido bien y dentro no viene nada. Si sólo miras el código de respuesta, eso se registra como éxito — y entonces tienes un modelo que figura con cien llamadas y cero fallos sin haber producido una sola frase.

Un fallo que se registra como éxito no se arregla nunca, porque nadie lo busca. Por eso tieneTexto(r) está en la condición y no sólo el r.ok.
El cortacircuitos se olvida al reiniciar

Un modelo apartado no lo está para siempre: el Set vive en memoria y desaparece en el siguiente arranque. Si el fallo era pasajero, vuelve solo. Si era de verdad, se aparta otra vez a la primera llamada. Cero mantenimiento.

Los presupuestos de tokens, y el que se come la respuesta

Se puede limitar cuánto escribe el modelo, y hay que hacerlo: es lo caro. Pero hay una trampa que deja la herramienta muda sin dar ningún error.

Algunos modelos «razonan» antes de contestar, y ese razonamiento gasta del MISMO presupuesto. Si le pones un tope pensando sólo en la respuesta —«una frase, con 120 tokens sobra»— el razonamiento se lo come entero y la respuesta llega vacía: respuesta correcta, sin error, sin texto. Que es exactamente el caso de la regla anterior.

La señal que lo delata está en la propia respuesta: viene un motivo de terminación que dice «se acabó el presupuesto» en vez de «he terminado». Guardar ese motivo en tu registro cuesta una línea y convierte un misterio de tarde entera en un vistazo. Si no guardas nada, lo único que ves es una herramienta que a veces no dice nada.

Respuestas estructuradas: la decisión que más simplifica el código

Si lo que necesitas no es prosa sino datos —una clasificación, tres campos, una lista— puedes pedirle al modelo que responda en un formato fijo. Cambia por completo lo que hay que escribir después.

Sin y con

// ❌ Prosa: hay que "adivinar" leyendo el texto
"Parece que el producto es un protector solar SPF50, apto para
 pieles sensibles y sin perfume, aunque no puedo asegurarlo."

// ✅ Estructurado: se usa directamente
{ "categoria": "solar", "spf": 50, "sin_perfume": true, "confianza": "media" }

Y hay dos cosas que se ganan además de la comodidad. La primera: confianza — un campo en el que el modelo dice lo seguro que está es infinitamente más útil que un «parece que» enterrado en una frase, porque tu código puede actuar sobre él. La segunda: con un formato fijo, una respuesta rara se detecta sola; con prosa, hay que leerla.

Pero ojo al revés: si lo que pides es una frase para un humano, no le obligues a devolver un formato de datos. Es la combinación que produce el fallo más tonto de todos — pides texto, exiges estructura, y lo que vuelve no encaja en ninguna de las dos cosas. Una cosa o la otra, decidida antes de escribir el prompt.

Qué merece una llamada al modelo, y qué no

Sí	No — y qué hacer en su lugar
Clasificar un texto libre en tus categorías	Sumar, restar o aplicar un porcentaje. Eso es una fórmula: exacta, gratis y siempre igual
Resumir una ficha larga en tres líneas	Buscar en una lista que ya tienes. Es un filtro
Extraer campos de un texto desordenado	Formatear una fecha o un importe
Redactar un borrador que alguien va a revisar	Decidir algo que tiene que ser el mismo siempre

La primera fila de la columna derecha es la más cara de aprender. Pedirle cuentas a un modelo es regalarle la oportunidad de equivocarse en lo único que un ordenador no falla nunca. Y cuando se equivoca no avisa: devuelve un número con el mismo aplomo que si fuera bueno. Los números los calcula tu código; el modelo decide qué mirar y lo explica.

Una app entera, de principio a fin

Un ejemplo completo y pequeño, que es como hay que empezar: pegas la lista de un pedido tal cual viene y te la devuelve ordenada por categorías, marcando lo que no ha sabido clasificar.

Pieza	Qué hace	Cuánto cuesta escribirla
Una página con un cuadro de texto y un botón	Pegar y enviar	Veinte minutos
Tu función	Topes, caché, cascada y llamada	Una hora
El prompt	Categorías tuyas y formato fijo de salida	Dos horas, y son las que importan
La tabla del registro	Modelo, tokens, error, tiempo	Diez minutos

El prompt, que es donde está el trabajo

Clasifica cada linea en una de estas categorias EXACTAS:
analgesia · digestivo · respiratorio · dermo · infantil · higiene · otros

Devuelve una lista. Para cada linea:
  { "texto": "la linea tal cual", "categoria": "...", "seguro": true|false }

REGLAS:
- Si dudas entre dos, elige la mas probable y pon seguro: false.
- Si no encaja en ninguna, categoria "otros" y seguro: false.
- NO inventes categorias nuevas.
- NO corrijas la linea original: devuelvela tal cual llego.

El campo seguro es lo que convierte un juguete en una herramienta. Sin él, las líneas dudosas se mezclan con las buenas y hay que revisarlo todo — o sea, no ahorra nada. Con él, las dudosas se pintan en ámbar arriba del todo y se revisan diez de ochenta. El valor no está en clasificar: está en saber qué NO se ha clasificado bien.

Y el consejo de por dónde empezar: elige algo que hagas tú a mano y que te aburra. No algo que impresione. Lo que se usa todas las semanas se mejora todas las semanas; lo que se montó para enseñarlo se abandona en quince días — y la diferencia no tiene nada que ver con lo bien construido que esté.

Antes de dar esto por aprendido

Afino el prompt en AI Studio antes de escribir código.
La clave vive en las variables de entorno y la llamada la hace mi servidor.
Tengo cascada de modelos, del barato al caro, y sé por qué ese orden.
Compruebo que la respuesta TIENE TEXTO, no sólo que no dio error.
Cacheo lo que se repite, y también el fallo con ventana corta.
La lista de modelos vive en un solo fichero.

← Anterior: un chatbot para tu farmacia Volver a la escuela →

Una app con Google AI Studio y los modelos lite gratis

Qué significa «modelo lite gratuito» de verdad

De AI Studio a una app, en cuatro pasos

Afina el prompt en la pantalla

Saca la clave y guárdala en Vercel

Pon una cascada de modelos, del barato al caro

Cachea, o pagarás por la misma respuesta cien veces

Cuatro cosas aprendidas a base de romperlas

Qué construir primero

De la prueba a algo publicado: los cuatro pasos

Afinar el prompt en AI Studio, con ejemplos reales

Sacar la clave y guardarla donde toca

Llamar desde TU función, no desde el navegador

Guardar lo que pasa