Comment créer une app Character AI : architecture, code et calcul du coût

Réponse rapide : l'architecture à quatre composants

Vous n'avez pas besoin d'entraîner ou de fine-tuner un modèle. Toute app de compagnon sérieuse sur le marché aujourd'hui, y compris celles qui servent des millions d'utilisateurs, est une fine couche d'orchestration au-dessus d'API LLM hébergées. Le personnage vit dans le prompt et dans la base de données, pas dans les poids. Le reste de ce guide construit chaque composant avec du code exécutable contre un endpoint standard compatible OpenAI, puis parcourt le calcul en tokens pour que vous sachiez ce que coûte réellement un utilisateur actif mensuel avant de lancer votre produit.

• Prompt de persona : un system prompt structuré (500 à 1 000 tokens) qui définit qui est le personnage et comment il parle.
• Mémoire : une fenêtre glissante des derniers tours plus un résumé rafraîchi périodiquement, pour que les conversations survivent au-delà de la limite de contexte.
• Modération : un contrôle d'âge, un classificateur d'entrée, et des politiques de contenu adaptées au modèle vers lequel vous routez.
• Routage : une petite fonction qui choisit un modèle bon marché pour le chat occasionnel et un plus puissant pour les longues scènes.

Composant 1 : le prompt de persona

Le prompt de persona, c'est le produit. C'est un message system qui accompagne chaque requête et contient typiquement cinq parties : identité (nom, âge, passé), traits de personnalité, style de discours avec deux ou trois lignes d'exemple, règles de comportement strictes (ne jamais sortir du personnage, garder les réponses sous une limite de longueur), et le scénario actuel. Gardez-le entre 500 et 1 000 tokens. Les personas plus courts dérivent ; les beaucoup plus longs brûlent le budget d'entrée à chaque message et améliorent rarement la fidélité. Stockez les personas comme des lignes dans votre base de données pour que les utilisateurs puissent créer et modifier des personnages, ce qui est la boucle centrale des produits de style Character.AI. Voici une requête complète. La même forme fonctionne avec n'importe quel backend compatible OpenAI ; cet exemple utilise l'endpoint d'une passerelle multi-modèles pour que vous puissiez changer de modèle en changeant une seule chaîne :

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
  }'

Composant 2 : une mémoire qui survit aux longues conversations

Les sessions d'app de compagnon durent longtemps. Une pile de mémoire à trois couches garde le contexte cohérent sans renvoyer tout l'historique à chaque fois : La couche 1 est la fenêtre glissante : les 10 à 14 derniers tours bruts, envoyés tels quels. La couche 2 est le résumé courant : tous les 20 tours environ, un modèle bon marché compresse les anciens messages en un paragraphe qui suit les noms, l'état de la relation et les fils narratifs ouverts. La couche 3 est les faits épinglés : des détails durables sur l'utilisateur (nom, préférences, événements passés dont le personnage doit se souvenir) extraits dans votre base de données et injectés comme un court message system. Voici l'implémentation complète en Python avec le SDK officiel 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

Composant 3 : modération et politiques de contenu

La modération dans une app de compagnon a trois tâches distinctes, et les confondre est l'erreur de lancement la plus courante. D'abord, filtrez votre audience. Si votre app autorise des thèmes fictifs matures, placez-les derrière un contrôle d'âge adulte et gardez un mode par défaut tout public séparé. L'App Store et le Play Store vérifient tous les deux ce point, et les processeurs de paiement aussi. Ensuite, filtrez les entrées. Passez une couche de classification bon marché sur les messages utilisateur avant qu'ils n'atteignent le modèle de personnage, en bloquant les catégories qu'aucun fournisseur n'autorise : contenu impliquant des mineurs, préjudice réel crédible, et instructions illégales. Un simple appel deepseek-v4-flash avec une rubrique oui/non coûte une fraction de cent et ajoute moins d'une seconde de latence. Enfin, faites correspondre la politique de contenu au modèle. Les fournisseurs diffèrent sur la fiction : la politique publiée par xAI autorise explicitement les thèmes fictifs matures pour les utilisateurs adultes, DeepSeek et d'autres modèles dérivés de poids ouverts sont des favoris de la communauté pour le roleplay car leurs politiques hébergées sont flexibles pour la fiction, tandis que la politique d'Anthropic interdit le contenu explicite, ce qui fait de Claude le bon choix uniquement pour l'écriture créative tout public. Comprendre ces politiques avant de router le trafic vous évite des tempêtes de refus en production. Quoi que vous construisiez, cela doit respecter les conditions d'usage de chaque fournisseur que vous appelez.

Composant 4 : routage de modèles et matrice de sélection

La plupart des messages dans une app de compagnon sont de courts tours occasionnels qu'un modèle économique gère parfaitement. Une minorité sont de longues scènes émotionnelles ou des morceaux créatifs où la qualité de prose est le produit. Router selon la profondeur de la scène réduit les coûts drastiquement sans que les utilisateurs le remarquent :

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

Ce que coûte réellement un utilisateur actif mensuel

Le calcul en tokens avant le lancement vaut mieux qu'une mauvaise surprise de facturation après. En utilisant le budget de contexte du tableau de mémoire : environ 3 300 tokens d'entrée et 250 tokens de sortie par message. Les utilisateurs d'app de compagnon sont assidus ; les chiffres rapportés par la communauté placent les utilisateurs engagés à des dizaines de messages par jour, donc supposons environ 40 messages par jour sur 20 jours actifs, soit environ 800 messages par MAU et par mois. Cela donne 2,64M tokens d'entrée et 0,2M tokens de sortie par MAU et par mois. En multipliant par les tarifs du catalogue :

Un seul endpoint pour chaque modèle de la matrice

S'inscrire chez cinq fournisseurs pour faire tourner un routeur est une vraie surcharge : cinq clés, cinq tableaux de bord de facturation, cinq jeux de limites de débit. Une passerelle multi-modèles réduit ça. APIsRouter expose chaque modèle ci-dessus via l'unique URL de base compatible OpenAI https://api.apisrouter.com/v1, donc l'extrait de routeur fonctionne tel quel en changeant seulement la chaîne du modèle. La facturation est à la consommation sans abonnement, les modèles globaux tournent 20 % en dessous des tarifs officiels avec les modèles chinois sous leurs tarifs officiels, et le paiement sans inscription sur /topup envoie une clé à votre e-mail après paiement, avec la première recharge qui ajoute un bonus de +100 % au solde. GET /v1/models avec votre clé renvoie la liste de modèles en direct, ce qui est aussi pratique pour peupler un sélecteur de modèle dans votre propre interface d'admin.

Astuces de production qui font vraiment économiser argent et douleur

• Streamez tout. Le temps jusqu'au premier token est la métrique que les utilisateurs ressentent ; une réponse streamée en 2 secondes semble plus rapide qu'une réponse complète en 4 secondes.
• Gardez le préfixe stable stable. Le persona et les faits épinglés doivent être identiques octet pour octet d'une requête à l'autre pour que les backends qui supportent le prefix caching puissent l'exploiter.
• Plafonnez max_tokens par route. Les tours occasionnels ont rarement besoin de plus de 300 tokens de sortie ; un modèle non plafonné qui divague double votre facture de sortie.
• Journalisez le coût par utilisateur, pas seulement par requête. Une petite fraction d'utilisateurs assidus dominera la dépense ; vous devez les voir pour concevoir des niveaux d'usage équitables.
• Construisez un repli dans le routeur. Si le modèle principal expire ou refuse, retentez une fois sur un modèle voisin avant de montrer une erreur.
• Découpez la fenêtre glissante par tokens, pas par tours, pour qu'un long copier-coller ne fasse pas exploser le budget.
• Gérez les refus dans le personnage. Faites correspondre un refus à une esquive gracieuse dans l'histoire plutôt que d'afficher du texte brut d'API.
• Ne stockez pas les chats bruts plus longtemps que nécessaire, et dites-le dans votre politique de confidentialité. Les logs de chat de compagnon sont sensibles par nature.

Questions fréquentes