Come costruire un'app Character AI: architettura, codice e calcolo dei costi

Risposta rapida: l'architettura a quattro componenti

Non hai bisogno di addestrare o fare fine-tuning di un modello. Ogni app companion seria sul mercato oggi, incluse quelle che servono milioni di utenti, è uno strato di orchestrazione sottile sopra API LLM ospitate. Il personaggio vive nel prompt e nel database, non nei pesi. Il resto di questa guida costruisce ogni componente con codice eseguibile contro un endpoint standard compatibile OpenAI, poi ripercorre il calcolo dei token così sai quanto costa davvero un utente attivo mensile prima di lanciare.

• Persona prompt: un system prompt strutturato (da 500 a 1.000 token) che definisce chi è il personaggio e come parla.
• Memoria: una finestra scorrevole dei turni recenti più un riassunto aggiornato periodicamente, così le conversazioni sopravvivono oltre il limite del contesto.
• Moderazione: un gate d'età, un classificatore dell'input e policy sui contenuti abbinate al modello verso cui instradi.
• Routing: una piccola funzione che sceglie un modello economico per la chat casuale e uno più forte per le scene lunghe.

Componente 1: il persona prompt

Il persona prompt è il prodotto. È un messaggio di sistema che viaggia con ogni richiesta e tipicamente contiene cinque parti: identità (nome, età, backstory), tratti di personalità, stile di parlato con due o tre righe di esempio, regole comportamentali rigide (mai uscire dal personaggio, mantenere le risposte sotto un limite di lunghezza), e lo scenario attuale. Tienilo tra 500 e 1.000 token. Persona più brevi vanno fuori tema; persone molto più lunghe bruciano budget di input a ogni singolo messaggio e raramente migliorano l'aderenza. Salva le persona come righe nel tuo database così gli utenti possono creare e modificare personaggi, che è il loop centrale dei prodotti in stile Character.AI. Ecco una richiesta completa. La stessa forma funziona con qualsiasi backend compatibile OpenAI; questo esempio usa un endpoint gateway multi-modello così puoi cambiare modello cambiando una stringa:

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 che sopravvive a conversazioni lunghe

Le sessioni delle app companion durano a lungo. Uno stack di memoria a tre livelli mantiene il contesto coerente senza inviare l'intera cronologia ogni volta: Livello 1 è la finestra scorrevole: gli ultimi 10-14 turni grezzi, inviati testualmente. Livello 2 è il riassunto in corso: ogni 20 turni circa, un modello economico comprime i messaggi più vecchi in un paragrafo che tiene traccia di nomi, stato della relazione e filoni di trama aperti. Livello 3 sono i fatti fissati: dettagli durevoli dell'utente (nome, preferenze, eventi passati che il personaggio dovrebbe ricordare) estratti nel tuo database e iniettati come un breve messaggio di sistema. Questa è l'intera implementazione in Python con l'SDK ufficiale 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: moderazione e policy sui contenuti

La moderazione in un'app companion ha tre compiti distinti, e confonderli è l'errore di lancio più comune. Primo, limita il pubblico. Se la tua app permette temi fittizi maturi, mettili dietro un gate d'età per adulti e mantieni un default separato per tutte le età. Sia App Store che Play Store lo controllano, e ci tengono anche i processori di pagamento. Secondo, filtra gli input. Esegui un passaggio di classificazione economico sui messaggi utente prima che raggiungano il modello del personaggio, bloccando categorie che nessun provider permette: contenuti che coinvolgono minori, danno reale credibile e istruzioni illegali. Una singola chiamata a deepseek-v4-flash con una rubrica sì/no costa una frazione di centesimo e aggiunge meno di un secondo di latenza. Terzo, abbina la policy sui contenuti al modello. I provider differiscono sulla fiction: la policy pubblicata di xAI permette esplicitamente temi fittizi maturi per utenti adulti, DeepSeek e altri modelli derivati da open-weight sono i preferiti della community per il roleplay perché le loro policy ospitate sono flessibili per la fiction, mentre la policy di Anthropic proibisce i contenuti espliciti, rendendo Claude la scelta giusta solo per la scrittura creativa per tutte le età. Capire queste policy prima di instradare il traffico ti risparmia tempeste di rifiuti in produzione. Qualunque cosa costruisci, deve rispettare i termini di servizio di ogni provider che chiami.

Componente 4: routing dei modelli e matrice di selezione

La maggior parte dei messaggi in un'app companion sono brevi turni casuali che un modello economico gestisce perfettamente. Una minoranza sono scene emotive lunghe o pezzi creativi dove la qualità della prosa è il prodotto. Instradare in base alla profondità della scena taglia drasticamente i costi senza che gli utenti se ne accorgano:

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"]

Quanto costa davvero un utente attivo mensile

Il calcolo dei token prima del lancio batte una sorpresa in fattura dopo. Usando il budget di contesto dalla tabella della memoria: circa 3.300 token di input e 250 token di output per messaggio. Gli utenti delle app companion sono intensivi; i dati riportati dalla community mettono gli utenti coinvolti a decine di messaggi al giorno, quindi assumi circa 40 messaggi al giorno su 20 giorni attivi, ovvero circa 800 messaggi per MAU al mese. Questo dà 2,64M token di input e 0,2M token di output per MAU al mese. Moltiplicando per le tariffe di catalogo:

Un unico endpoint per ogni modello sulla matrice

Iscriversi a cinque account provider per far girare un router è un vero sovraccarico: cinque chiavi, cinque dashboard di fatturazione, cinque set di rate limit. Un gateway multi-modello riduce tutto questo. APIsRouter espone ogni modello qui sopra tramite l'unico base URL compatibile OpenAI https://api.apisrouter.com/v1, quindi lo snippet del router funziona così com'è cambiando solo la stringa del modello. La fatturazione è pay-as-you-go senza abbonamento, i modelli globali girano al 20% sotto i prezzi ufficiali con i modelli cinesi sotto le loro tariffe ufficiali, e il checkout senza registrazione su /topup invia una chiave alla tua email dopo il pagamento, con la prima ricarica che aggiunge +100% al saldo. GET /v1/models con la tua chiave restituisce la lista dei modelli in tempo reale, comoda anche per popolare un selettore di modelli nella tua UI di amministrazione.

Consigli di produzione che risparmiano soldi e dolori veri

• Fai streaming di tutto. Il time-to-first-token è la metrica che gli utenti sentono; una risposta in streaming a 2 secondi sembra più veloce di una risposta completa a 4.
• Mantieni stabile il prefisso stabile. Persona e fatti fissati dovrebbero essere identici byte per byte tra le richieste così i backend che supportano il prefix caching possono sfruttarlo.
• Limita max_tokens per rotta. I turni casuali raramente hanno bisogno di più di 300 token di output; un modello senza limite che divaga raddoppia la tua fattura di output.
• Registra il costo per utente, non solo per richiesta. Una piccola frazione di utenti intensivi dominerà la spesa; devi vederli per progettare livelli di uso equi.
• Costruisci il fallback nel router. Se il modello primario va in timeout o rifiuta, ritenta una volta su un modello gemello prima di mostrare un errore.
• Taglia la finestra scorrevole per token, non per turni, così un incollaggio lungo non sfonda il budget.
• Gestisci i rifiuti in carattere. Mappa un rifiuto su una deviazione elegante dentro la storia invece di mostrare il testo grezzo dell'API.
• Non conservare le chat grezze più a lungo del necessario, e dillo nella tua privacy policy. I log delle chat companion sono sensibili per natura.

Domande frequenti