Cómo construir una app de Character AI: arquitectura, código y coste

Respuesta rápida: la arquitectura de cuatro componentes

No necesitas entrenar ni hacer fine-tuning de ningún modelo. Toda app de compañero seria en el mercado hoy, incluidas las que sirven a millones de usuarios, es una capa de orquestación delgada sobre APIs de LLM alojadas. El personaje vive en el prompt y en la base de datos, no en los pesos del modelo. El resto de esta guía construye cada componente con código ejecutable contra un endpoint estándar compatible con OpenAI, y luego recorre las cuentas de tokens para que sepas cuánto cuesta realmente un usuario activo mensual antes de lanzar.

• Prompt de persona: un system prompt estructurado (500 a 1.000 tokens) que define quién es el personaje y cómo habla.
• Memoria: una ventana móvil de turnos recientes más un resumen refrescado periódicamente, para que las conversaciones sobrevivan más allá del límite de contexto.
• Moderación: un control de edad, un clasificador de entrada y políticas de contenido acordes al modelo al que enrutas.
• Enrutamiento: una pequeña función que elige un modelo barato para el chat casual y uno más fuerte para escenas largas.

Componente 1: el prompt de persona

El prompt de persona es el producto. Es un mensaje de sistema que viaja con cada petición y suele contener cinco partes: identidad (nombre, edad, historia), rasgos de personalidad, estilo de habla con dos o tres frases de ejemplo, reglas de comportamiento firmes (nunca romper el personaje, mantener las respuestas bajo un límite de longitud) y el escenario actual. Mantenlo entre 500 y 1.000 tokens. Las personas más cortas se desvían; las mucho más largas queman presupuesto de entrada en cada mensaje y rara vez mejoran la adherencia. Guarda las personas como filas en tu base de datos para que los usuarios puedan crear y editar personajes, que es el bucle central de los productos estilo Character.AI. Aquí una petición completa. La misma forma funciona con cualquier backend compatible con OpenAI; este ejemplo usa el endpoint de un gateway multi-modelo para que puedas cambiar de modelo cambiando una sola cadena:

curl https://api.apisrouter.com/v1/chat/completions \
  -H "Authorization: Bearer $KEAI_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "deepseek-v4-flash",
    "messages": [
      {"role": "system", "content": "You are Mira, a sarcastic starship engineer in her 30s. Personality: dry wit, fiercely loyal, hates small talk. Speech style: short technical sentences, occasional teasing. Example: \"The coupling is fried. Again. Did you touch it?\" Rules: never break character, never mention being an AI, keep replies under 120 words."},
      {"role": "user", "content": "Mira, the reactor is making that noise again."}
    ],
    "temperature": 0.9,
    "max_tokens": 300,
    "stream": true
  }'

Componente 2: memoria que sobrevive a conversaciones largas

Las sesiones de apps de compañero se alargan mucho. Una pila de memoria de tres capas mantiene el contexto coherente sin reenviar todo el historial cada vez: La capa 1 es la ventana móvil: los últimos 10 a 14 turnos en bruto, enviados textualmente. La capa 2 es el resumen corriente: cada 20 turnos más o menos, un modelo barato comprime los mensajes más antiguos en un párrafo que sigue nombres, estado de la relación y tramas abiertas. La capa 3 son los hechos fijados: detalles duraderos del usuario (nombre, preferencias, eventos pasados que el personaje debería recordar) extraídos a tu base de datos e inyectados como un mensaje de sistema corto. Esta es toda la implementación en Python con el SDK oficial de OpenAI:

from openai import OpenAI

client = OpenAI(
    api_key="sk-...",
    base_url="https://api.apisrouter.com/v1",
)

def build_context(persona, summary, pinned_facts, recent_turns, user_msg):
    facts = "\n".join(f"- {f}" for f in pinned_facts)
    return [
        {"role": "system", "content": persona},
        *([{"role": "system", "content": f"Facts to remember:\n{facts}"}]
          if pinned_facts else []),
        *([{"role": "system", "content": f"Story so far: {summary}"}]
          if summary else []),
        *recent_turns[-12:],
        {"role": "user", "content": user_msg},
    ]

def refresh_summary(old_turns, prev_summary):
    prompt = (
        "Update this running summary of a roleplay chat. Keep names, "
        "relationship state, and open plot threads. Max 150 words.\n\n"
        f"Current summary: {prev_summary}\n\nNew messages: {old_turns}"
    )
    resp = client.chat.completions.create(
        model="deepseek-v4-flash",
        messages=[{"role": "user", "content": prompt}],
        max_tokens=400,
    )
    return resp.choices[0].message.content

Componente 3: moderación y políticas de contenido

La moderación en una app de compañero tiene tres funciones distintas, y mezclarlas es el error de lanzamiento más común. Primero, controla la edad de tu audiencia. Si tu app permite temáticas ficticias maduras, ponlas detrás de un control de edad para adultos y mantén un valor por defecto separado para todas las edades. Tanto la App Store como Play Store revisan esto, y los procesadores de pago también se preocupan por ello. Segundo, filtra las entradas. Ejecuta un pase de clasificador barato sobre los mensajes del usuario antes de que lleguen al modelo de personaje, bloqueando categorías que ningún proveedor permite: contenido que involucre a menores, daño creíble en el mundo real e instrucciones ilegales. Una sola llamada a deepseek-v4-flash con una rúbrica de sí/no cuesta una fracción de centavo y añade menos de un segundo de latencia. Tercero, ajusta la política de contenido al modelo. Los proveedores difieren en ficción: la política publicada de xAI permite explícitamente temáticas ficticias maduras para usuarios adultos, DeepSeek y otros modelos derivados de pesos abiertos son favoritos de la comunidad para roleplay porque sus políticas alojadas son flexibles con la ficción, mientras que la política de Anthropic prohíbe el contenido explícito, lo que hace de Claude la opción correcta solo para escritura creativa apta para todas las edades. Entender estas políticas antes de enrutar tráfico te ahorra tormentas de rechazos en producción. Sea lo que sea que construyas, debe respetar los términos de servicio de cada proveedor que llames.

Componente 4: enrutamiento de modelos y la matriz de selección

La mayoría de los mensajes en una app de compañero son turnos casuales cortos que un modelo económico maneja perfectamente. Una minoría son escenas emocionales largas o piezas creativas donde la calidad de la prosa es el producto. Enrutar según la profundidad de la escena reduce costes drásticamente sin que los usuarios lo noten:

ROUTES = {
    "casual": "deepseek-v4-flash",
    "scene": "deepseek-v4-pro",
    "prose": "claude-sonnet-4-6",  # all-ages creative writing only
}

def pick_model(user_msg: str, turns_in_scene: int) -> str:
    if turns_in_scene > 6 or len(user_msg) > 400:
        return ROUTES["scene"]
    return ROUTES["casual"]

Lo que realmente cuesta un usuario activo mensual

Las cuentas de tokens antes del lanzamiento ganan a una sorpresa de facturación después. Usando el presupuesto de contexto de la tabla de memoria: unos 3.300 tokens de entrada y 250 tokens de salida por mensaje. Los usuarios de apps de compañero son intensos; las cifras reportadas por la comunidad sitúan a los usuarios comprometidos en decenas de mensajes al día, así que asumamos unos 40 mensajes al día en 20 días activos, o unos 800 mensajes por MAU al mes. Eso da 2,64M tokens de entrada y 0,2M tokens de salida por MAU al mes. Multiplicando por las tarifas de catálogo:

Un solo endpoint para cada modelo de la matriz

Registrarse en cinco cuentas de proveedor para ejecutar un enrutador es una sobrecarga real: cinco claves, cinco paneles de facturación, cinco conjuntos de límites de tasa. Un gateway multi-modelo simplifica todo eso. APIsRouter expone cada modelo de arriba a través de la única URL base compatible con OpenAI https://api.apisrouter.com/v1, así que el fragmento del enrutador funciona tal cual con solo cambiar la cadena del modelo. La facturación es por uso sin suscripción, los modelos globales corren un 20% por debajo del precio oficial con los modelos chinos por debajo de sus tarifas oficiales, y el checkout sin registro en /topup envía una clave a tu correo tras el pago, con la primera recarga sumando +100% de saldo. GET /v1/models con tu clave devuelve la lista de modelos en vivo, útil también para poblar un selector de modelos en tu propia UI de administración.

Consejos de producción que ahorran dinero y dolores reales

• Transmite todo con streaming. El tiempo hasta el primer token es la métrica que sienten los usuarios; una respuesta transmitida en 2 segundos se siente más rápida que una respuesta completa en 4.
• Mantén estable el prefijo estable. La persona y los hechos fijados deben ser idénticos byte a byte entre peticiones para que los backends con caché de prefijo puedan aprovecharlo.
• Limita max_tokens por ruta. Los turnos casuales rara vez necesitan más de 300 tokens de salida; un modelo sin límite que divaga duplica tu factura de salida.
• Registra el coste por usuario, no solo por petición. Una pequeña fracción de usuarios intensos dominará el gasto; necesitas verlos para diseñar niveles de uso justos.
• Construye respaldo en el enrutador. Si el modelo principal se agota o rechaza, reintenta una vez con un modelo hermano antes de mostrar un error.
• Recorta la ventana móvil por tokens, no por turnos, para que un pegado largo no reviente el presupuesto.
• Maneja los rechazos dentro del personaje. Mapea un rechazo a una desviación elegante dentro de la historia en vez de mostrar el texto crudo de la API.
• No guardes chats en bruto más tiempo del necesario, y dilo en tu política de privacidad. Los registros de chat de compañero son sensibles por naturaleza.

Preguntas frecuentes