Wie man eine Character-AI-App baut: Architektur, Code und Kostenrechnung

Kurzantwort: die Vier-Komponenten-Architektur

Du musst kein Modell trainieren oder fine-tunen. Jede ernsthafte Companion-App auf dem Markt heute, einschließlich der, die Millionen Nutzer bedienen, ist eine dünne Orchestrierungsschicht über gehosteten LLM-APIs. Der Charakter lebt im Prompt und in der Datenbank, nicht in den Gewichten. Der Rest dieses Guides baut jede Komponente mit lauffähigem Code gegen einen Standard-OpenAI-kompatiblen Endpoint, und geht dann die Token-Rechnung durch, damit du weißt, was ein monatlich aktiver Nutzer tatsächlich kostet, bevor du launchst.

• Persona-Prompt: ein strukturierter System-Prompt (500 bis 1.000 Token), der definiert, wer der Charakter ist und wie er spricht.
• Memory: ein Rolling Window aus den letzten Turns plus eine periodisch aufgefrischte Zusammenfassung, damit Unterhaltungen über das Context-Limit hinaus überleben.
• Moderation: ein Age Gate, ein Input-Classifier, und Content-Policies, die zum Modell passen, an das du routest.
• Routing: eine kleine Funktion, die ein günstiges Modell für lockeren Chat wählt und ein stärkeres für lange Szenen.

Komponente 1: der Persona-Prompt

Der Persona-Prompt ist das Produkt. Es ist eine System-Message, die mit jeder Anfrage mitgeschickt wird und typischerweise fünf Teile enthält: Identität (Name, Alter, Backstory), Persönlichkeitsmerkmale, Sprechstil mit zwei oder drei Beispielzeilen, harte Verhaltensregeln (nie aus der Rolle fallen, Antworten unter einer Längengrenze halten), und das aktuelle Szenario. Halte ihn zwischen 500 und 1.000 Token. Kürzere Personas driften ab; deutlich längere verbrennen bei jeder einzelnen Nachricht Input-Budget und verbessern die Rollentreue selten. Speichere Personas als Zeilen in deiner Datenbank, damit Nutzer Charaktere erstellen und bearbeiten können, was der Kern-Loop von Character.AI-artigen Produkten ist. Hier eine komplette Anfrage. Dieselbe Form funktioniert mit jedem OpenAI-kompatiblen Backend; dieses Beispiel nutzt einen Multi-Modell-Gateway-Endpoint, sodass du Modelle durch Ändern eines Strings tauschen kannst:

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

Komponente 2: Memory, das lange Unterhaltungen übersteht

Companion-App-Sessions laufen lang. Ein Drei-Schichten-Memory-Stack hält den Kontext kohärent, ohne jedes Mal den gesamten Verlauf mitzusenden: Layer 1 ist das Rolling Window: die letzten 10 bis 14 rohen Turns, wörtlich mitgesendet. Layer 2 ist die laufende Zusammenfassung: alle 20 Turns oder so komprimiert ein günstiges Modell ältere Nachrichten zu einem Absatz, der Namen, Beziehungsstatus und offene Plot-Threads nachhält. Layer 3 sind gepinnte Fakten: dauerhafte Nutzerdetails (Name, Vorlieben, vergangene Ereignisse, an die sich der Charakter erinnern soll), extrahiert in deine Datenbank und als kurze System-Message eingefügt. Das ist die gesamte Implementierung in Python mit dem offiziellen OpenAI SDK:

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

Komponente 3: Moderation und Content-Policies

Moderation in einer Companion-App hat drei unterschiedliche Aufgaben, und sie zu vermischen ist der häufigste Launch-Fehler. Erstens: Grenze dein Publikum ab. Wenn deine App reifere fiktionale Themen erlaubt, stell sie hinter ein Erwachsenen-Age-Gate und behalte einen separaten Standard für alle Altersgruppen. Sowohl App-Store- als auch Play-Store-Review prüfen das, und Zahlungsdienstleister achten auch darauf. Zweitens: Screene Eingaben. Führe einen günstigen Classifier-Durchgang über Nutzernachrichten aus, bevor sie das Charakter-Modell erreichen, und blockiere Kategorien, die kein Provider erlaubt: Inhalte mit Minderjährigen, glaubwürdiger realer Schaden, und illegale Anleitungen. Ein einzelner deepseek-v4-flash-Call mit einer Ja/Nein-Rubrik kostet einen Bruchteil eines Cents und fügt unter einer Sekunde Latenz hinzu. Drittens: Bring Content-Policy und Modell zusammen. Provider unterscheiden sich bei Fiktion: xAIs veröffentlichte Policy erlaubt reifere fiktionale Themen für erwachsene Nutzer ausdrücklich, DeepSeek und andere von Open Weights abgeleitete Modelle sind Community-Favoriten fürs Roleplay, weil ihre gehosteten Policies bei Fiktion flexibel sind, während Anthropics Policy explizite Inhalte verbietet, was Claude nur für Creative Writing für alle Altersgruppen zur richtigen Wahl macht. Diese Policies zu verstehen, bevor du Traffic routest, erspart dir Ablehnungsstürme in Produktion. Was auch immer du baust, es muss die Nutzungsbedingungen jedes Providers respektieren, den du aufrufst.

Komponente 4: Modell-Routing und die Auswahlmatrix

Die meisten Nachrichten in einer Companion-App sind kurze lockere Turns, die ein Budget-Modell perfekt bewältigt. Eine Minderheit sind lange emotionale Szenen oder kreative Glanzstücke, bei denen die Prosa-Qualität das Produkt ist. Routing nach Szenentiefe senkt die Kosten drastisch, ohne dass Nutzer es merken:

ROUTES = {
    "casual": "deepseek-v4-flash",
    "scene": "deepseek-v4-pro",
    "prose": "claude-sonnet-4-6",  # nur Creative Writing für alle Altersgruppen
}

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

Was ein monatlich aktiver Nutzer tatsächlich kostet

Token-Rechnung vor dem Launch schlägt eine Abrechnungsüberraschung danach. Mit dem Kontext-Budget aus der Memory-Tabelle: rund 3.300 Input-Token und 250 Output-Token pro Nachricht. Companion-App-Nutzer sind intensiv; von der Community berichtete Zahlen setzen engagierte Nutzer bei Dutzenden Nachrichten pro Tag an, geh also von etwa 40 Nachrichten pro Tag über 20 aktive Tage aus, also rund 800 Nachrichten pro MAU pro Monat. Das ergibt 2,64 Mio. Input-Token und 0,2 Mio. Output-Token pro MAU pro Monat. Multipliziert mit den Katalogpreisen:

Ein Endpoint für jedes Modell in der Matrix

Fünf Provider-Konten anzulegen, um einen Router zu betreiben, ist echter Overhead: fünf Keys, fünf Billing-Dashboards, fünf Sätze von Rate-Limits. Ein Multi-Modell-Gateway löst das auf. APIsRouter stellt jedes Modell oben über die eine OpenAI-kompatible Base-URL https://api.apisrouter.com/v1 bereit, sodass das Router-Snippet unverändert funktioniert, wenn du nur den Modell-String änderst. Die Abrechnung ist Pay-as-you-go ohne Abo, globale Modelle laufen 20 % unter dem offiziellen Preis, chinesische Modelle unter ihren offiziellen Preisen, und der Checkout unter /topup ohne Anmeldung schickt nach der Zahlung einen Key an deine E-Mail, wobei die erste Aufladung zusätzlich +100 % Guthaben bringt. GET /v1/models mit deinem Key liefert die aktuelle Modellliste, was auch praktisch ist, um einen Modell-Picker in deiner eigenen Admin-UI zu befüllen.

Produktions-Tipps, die echtes Geld und Ärger sparen

• Streame alles. Time-to-First-Token ist die Metrik, die Nutzer spüren; eine gestreamte Antwort nach 2 Sekunden fühlt sich schneller an als eine vollständige Antwort nach 4.
• Halte den stabilen Präfix stabil. Persona und gepinnte Fakten sollten über Anfragen hinweg Byte-identisch sein, damit Backends mit Prefix-Caching davon profitieren können.
• Deckel max_tokens pro Route. Lockere Turns brauchen selten mehr als 300 Output-Token; ein ungedeckeltes Modell, das abschweift, verdoppelt deine Output-Rechnung.
• Logge Kosten pro Nutzer, nicht nur pro Anfrage. Ein kleiner Anteil intensiver Nutzer wird die Ausgaben dominieren; du musst sie sehen, um faire Nutzungs-Tiers zu gestalten.
• Bau Fallback in den Router ein. Wenn das primäre Modell in Timeout läuft oder ablehnt, versuch es einmal mit einem Schwester-Modell erneut, bevor du einen Fehler anzeigst.
• Kürze das Rolling Window nach Token, nicht nach Turns, damit ein einziger langer Paste nicht das Budget sprengt.
• Behandle Ablehnungen in der Rolle. Bilde eine Ablehnung auf ein elegantes In-Story-Ausweichmanöver ab, statt rohen API-Text anzuzeigen.
• Speichere rohe Chats nicht länger als nötig, und sag das in deiner Datenschutzerklärung. Companion-Chat-Logs sind naturgemäß sensibel.

Häufige Fragen