Character AI app कैसे बनाएं: architecture, code, और cost math

Quick answer: four-component architecture

आपको कोई model train या fine-tune करने की जरूरत नहीं है। आज बाजार में हर serious companion app, millions users serve करने वाले भी शामिल, hosted LLM APIs के ऊपर एक thin orchestration layer है। Character prompt और database में रहता है, weights में नहीं। बाकी यह guide एक standard OpenAI-compatible endpoint के against runnable code के साथ हर component बनाती है, फिर token math से गुजरती है ताकि launch से पहले आपको पता हो कि एक monthly active user actually कितना cost करता है।

• Persona prompt: एक structured system prompt (500 से 1,000 tokens) जो define करता है कि character कौन है और कैसे बोलता है।
• Memory: recent turns की एक rolling window plus एक periodically refreshed summary, ताकि conversations context limit के आगे भी survive करें।
• Moderation: एक age gate, एक input classifier, और जिस model पर आप route करते हैं उससे match करती हुई content policies।
• Routing: एक छोटा function जो casual chat के लिए एक cheap model और लंबी scenes के लिए एक stronger model चुनता है।

Component 1: persona prompt

Persona prompt ही product है। यह एक system message है जो हर request के साथ जाता है और typically पांच हिस्सों में होता है: identity (name, age, backstory), personality traits, दो या तीन example lines वाला speech style, hard behavioral rules (कभी character मत तोड़ो, replies को एक length cap के अंदर रखो), और current scenario। इसे 500 से 1,000 tokens के बीच रखें। छोटे personas drift करते हैं; बहुत लंबे personas हर single message पर input budget जलाते हैं और शायद ही adherence improve करते हैं। Personas को अपने database में rows की तरह store करें ताकि users characters बना और edit कर सकें, जो Character.AI-style products का core loop है। यह रहा एक complete request। यही shape किसी भी OpenAI-compatible backend के साथ काम करता है; यह example एक multi-model gateway endpoint use करता है ताकि आप एक string बदलकर models swap कर सकें:

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

Component 2: memory जो लंबी conversations में टिकती है

Companion app sessions लंबी चलती हैं। एक three-layer memory stack हर बार पूरी history भेजे बिना context को coherent रखता है: Layer 1 rolling window है: पिछले 10 से 14 raw turns, verbatim भेजे गए। Layer 2 running summary है: हर लगभग 20 turns पर, एक cheap model पुराने messages को एक ऐसे paragraph में compress करता है जो names, relationship state, और open plot threads track करता है। Layer 3 pinned facts हैं: durable user details (name, preferences, ऐसी past events जो character को याद रखनी चाहिए) जो आपके database में extract की जाती हैं और एक छोटे system message के तौर पर inject की जाती हैं। Python में official OpenAI SDK के साथ पूरा implementation यह रहा:

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

Component 3: moderation और content policies

Companion app में moderation के तीन अलग जॉब हैं, और इन्हें आपस में मिला देना सबसे common launch mistake है। पहला, अपनी audience को gate करें। अगर आपका app mature fictional themes allow करता है, तो इन्हें एक adult age gate के पीछे रखें और अलग से एक all-ages default रखें। App Store और Play Store review दोनों इसे check करते हैं, और payment processors भी इसकी परवाह करते हैं। दूसरा, inputs screen करें। User messages पर character model तक पहुंचने से पहले एक cheap classifier pass चलाएं, उन categories को block करते हुए जिन्हें कोई भी provider allow नहीं करता: minors से जुड़ा content, credible real-world harm, और illegal instructions। एक yes/no rubric वाला single deepseek-v4-flash call एक cent के छोटे हिस्से जितना cost करता है और latency में एक second से कम जोड़ता है। तीसरा, content policy को model से match करें। Providers fiction पर अलग-अलग हैं: xAI की published policy adult users के लिए mature fictional themes को explicitly allow करती है, DeepSeek और अन्य open-weight-derived models roleplay के लिए community favorites हैं क्योंकि उनकी hosted policies fiction के लिए flexible हैं, जबकि Anthropic की policy explicit content prohibit करती है, जो Claude को सिर्फ all-ages creative writing के लिए सही choice बनाती है। Traffic route करने से पहले इन policies को समझना आपको production में refusal storms से बचाता है। आप जो भी बनाएं, उसे हर provider की terms of service का सम्मान करना चाहिए जिसे आप call करते हैं।

Component 4: model routing और selection matrix

Companion app में ज्यादातर messages छोटे casual turns होते हैं जिन्हें एक budget model perfectly handle कर लेता है। एक अल्पसंख्यक हिस्सा लंबी emotional scenes या creative set pieces होता है जहां prose quality ही product है। Scene depth के हिसाब से route करना बिना users को नोटिस कराए costs dramatically कम कर देता है:

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

एक monthly active user actually कितना cost करता है

Launch से पहले token math billing surprise से बेहतर है। Memory table वाले context budget को use करते हुए: per message roughly 3,300 input tokens और 250 output tokens। Companion app users heavy होते हैं; community-reported figures engaged users को day में दर्जनों messages पर रखते हैं, तो 20 active days में roughly per day 40 messages मानें, यानी per MAU per month लगभग 800 messages। इससे per MAU per month 2.64M input tokens और 0.2M output tokens बनते हैं। Catalog rates से multiply करने पर:

Matrix के हर model के लिए एक endpoint

एक router चलाने के लिए पांच provider accounts में sign up करना real overhead है: पांच keys, पांच billing dashboards, पांच rate-limit sets। एक multi-model gateway इसे collapse कर देता है। APIsRouter ऊपर के हर model को single OpenAI-compatible base URL https://api.apisrouter.com/v1 के through expose करता है, तो router snippet सिर्फ model string बदलकर as-is काम करता है। Billing pay-as-you-go है बिना subscription के, global models official pricing से 20% नीचे चलते हैं Chinese models official rates से नीचे के साथ, और /topup पर no-signup checkout payment के बाद आपके email पर एक key भेजता है, पहला top-up +100% balance add करता है। आपकी key के साथ GET /v1/models live model list return करता है, जो आपके खुद के admin UI में model picker populate करने के लिए भी काम आता है।

Production tips जो real पैसा और pain बचाते हैं

• सब कुछ stream करें। Time-to-first-token वह metric है जो users feel करते हैं; 2 seconds पर एक streamed reply 4 seconds पर एक complete reply से तेज feel होती है।
• Stable prefix को stable रखें। Persona और pinned facts requests में byte-identical होने चाहिए ताकि prefix caching support करने वाले backends इसका फायदा उठा सकें।
• Per route max_tokens cap करें। Casual turns को शायद ही 300 output tokens से ज्यादा चाहिए होते हैं; एक uncapped model जो rambling करे आपका output bill double कर देता है।
• सिर्फ per request नहीं, per user cost log करें। Heavy users का एक छोटा हिस्सा spend पर हावी रहेगा; fair usage tiers design करने के लिए आपको उन्हें देखना जरूरी है।
• Router में fallback build करें। अगर primary model timeout हो या refuse करे, error surface करने से पहले एक sibling model पर एक बार retry करें।
• Rolling window को turns से नहीं, tokens से trim करें, ताकि एक लंबा paste budget ना उड़ा दे।
• Refusals को character में handle करें। Refusal को raw API text दिखाने की बजाय एक graceful in-story deflection में map करें।
• Raw chats को जरूरत से ज्यादा देर तक store मत करें, और अपनी privacy policy में यह बताएं। Companion chat logs स्वभाव से sensitive होते हैं।

अक्सर पूछे जाने वाले प्रश्न