LLM Foundations interview questions & answers

Ek baccha soch jisne 100 crore books padh li hain. Har language, har topic — is bacche ne sab dekha hai. Par twist ye hai: ye baccha waisa "samajhta" nahi jaisa tu samajhta hai. Bacche ne bas itne saare patterns dekhe hain ki jab tu bolta hai "Mera naam ___", baccha turant bolta hai "hai" — kyunki usne tera sentence samjha isliye nahi, balki ye pattern usne pehle bhi arabon baar dekha hai. Ek Large Language Model (LLM) bilkul yehi baccha hai, bas math se bana hua.

LLM me, core kaam simple hai: ab tak ka text dekh ke, agla sabse likely token predict karo — ek ek token karke, baar baar, jab tak reply complete na ho jaaye. Isse autoregressive bolte hain. Ye tere phone ke autocomplete jaisa hi hai ("Good mor" → "morning"), bas lakhon guna scale up, aur tere messages ki jagah internet ke bade hisse pe trained.

Under the hood, LLMs transformer architecture use karte hain. High level pe (heavy math ki zaroorat nahi): text tokens me toota jaata hai, phir ek attention mechanism ye figure out karta hai ki sentence me kaunse words ek doosre se related hain — jaise "The cat sat on the mat because it was tired" me, attention "it" ko strongly "cat" se jodta hai, "mat" se nahi. Isi tarah model sentence ke andar context track karta hai.

Models words nahi padhte — woh tokens padhte hain (≈4 characters, roughly ¾ word). Akela "ChatGPT" 3 tokens ho sakta hai. Tu per-token pay karta hai (input + output dono), toh token count = cost + speed. Har model ka ek context window bhi hota hai — max tokens jo woh ek saath "dekh" sakta hai (system prompt + chat history + tera message + reply, sab milake count hote hain). Ye limit cross ki toh API request ko error ke saath reject kar deta hai (400/413, ya response me stop_reason: "model_context_window_exceeded") — purane messages silently drop nahi hote. History ko limit ke andar rakhna, yaani purane turns trim ya summarise karna, tere application ka kaam hai.

Do knobs ye badalte hain ki agla token kaise sample hota hai: temperature (kam = model apne sabse high-probability tokens ke paas hi rehta hai, isliye replies zyada milte-julte aate hain; ~1 = flatter distribution, zyada varied wording; bahut zyada = nonsense) aur top_p (nucleus sampling — choose karne se pehle pool ko sirf sabse probable tokens tak limit karta hai). In me se ek hi tune karo, dono nahi — usually temperature. Do caveats jo interviews me poochhe jaate hain: temperature koi determinism switch nahi hai (same settings pe bhi alag text aa sakta hai), aur ye answers ko zyada accurate nahi banata — ek confidently galat jawab bas consistently galat ho jaata hai; accuracy real data me grounding se aati hai. Ye knobs provider-scoped bhi hain: ye OpenAI API ke parameters hain, jabki current Claude models temperature aur top_p ko 400 error ke saath reject karte hain.

Akhir me, models do type ke hote hain: closed (GPT-4o, Claude Sonnet/Haiku/Opus, Gemini — sirf API se, per-token paisa, bahut capable) aur open (Llama, Mistral — free weights, khud apne GPU pe host karo).

🌍 Real-world example: Ek factual sawaal temperature 0 pe 3 baar poochh — teeno replies usually bahut milti-julti wording me aayenge, par ye ek tendency hai, guarantee nahi, aur isse ye bhi pata nahi chalta ki jawab sahi hai ya nahi. "Ek poem likh de" prompt temperature 1 pe 3 baar poochh — teen alag poems milengi. Same model, sirf knob alag.

💡 Token = text ka ek tukda (~4 characters); LLM asal me isi unit ko padhta hai aur isi se bill karta hai.

💡 Context window = ek conversation turn me model jitne tokens ek saath memory me rakh sakta hai.

💡 Attention = wo mechanism jo model ko sentence ke words ko ek doosre se relate karne deta hai.

💡 Hallucination = jab LLM confidently kuch galat bol de, kyunki woh pattern-complete kar raha hai, fact-check nahi.

Kab LLM sahi auzaar hai: khuli hui bhasha ke kaam me — summarise karna, dobara likhna, bikhre text ko classify karna, prose se fields nikaalna, draft banana, diye hue context se jawab dena. Jahan bhi input itna badalta ho ki uske liye rules likhna mumkin na ho.

Kab galat auzaar hai: har us cheez me jiska ek sahi jawab aap nikaal sakte hain. Hisaab-kitaab, sorting, dates, business rules, apne database me lookup. Ek regex, ek SQL query ya teen line code sateek, muft aur jaanch-yogya hai; model andaazan, billed aur na-samjhaya ja sakne wala. Pattern ye hai ki "model se calculator chalwaao", ye nahi ki "model ko hi calculator banao".

Kab wahan bhi savdhaani jahan ye fit baithta hai: jahan bhi ek dhaarapravaah galat jawab mehnga pade — medical, legal, financial. Poore aatmvishwas se galat hona koi kinare ka case nahi hai; ye next-token prediction ka swabhav hai.

Trade-off kya hai: aap nishchitta dekar lachak le rahe hain. Wahi prompt do calls me alag output de sakta hai, output ko barabari se unit-test nahi kiya ja sakta, aur galat hone par koi stack trace nahi milta — bas ek prompt jise aap badal ke ummeed kar sakte hain. Wo lachak bikhre input par bahut keemti hai aur us structured input par bekaar jo pehle se aapke haath me hai.

Standard definition (interview me bolo): A Large Language Model (LLM) is a neural network — built on the transformer architecture — trained to predict the next token in a sequence of text, and it generates responses by repeatedly predicting one token at a time based on all the tokens seen so far.

from openai import OpenAI

client = OpenAI()  # reads your API key from the environment

prompt = "Suggest one good programming language for beginners, in 5 words."

for temp in [0.0, 0.0, 1.2]:
    response = client.responses.create(
        model="gpt-4o-mini",
        input=prompt,
        temperature=temp
    )
    print(f"temperature={temp} -> {response.output_text}")

LLM ko ek genie samajh. "Khana de" bolega toh genie kuch bhi de dega — shayad kaccha, shayad wo jo tu chahta hi nahi tha. "Mujhe Hyderabadi biryani de, medium spicy, dum-pukht style, 2 logo ke liye, ek bowl mein" bolega toh genie EXACTLY wahi dega. Prompt engineering genie se sahi tarike se maangna hai — model smart nahi hua, tere instructions clear ho gaye.

LLM ke paas sirf wahi text hota hai jo tu bhejta hai. Ye tera mann nahi padh sakta, tera screen nahi dekh sakta, aur wo format guess nahi kar sakta jo tu secretly chahta tha. Jo constraint tu nahi batata, wo constraint model ignore karne ke liye free hota hai. Isliye vague prompt sirf kharab answer ka risk nahi hai — ye ek aisa answer bhi de sakta hai jo technically sahi ho par tere program ke liye bekaar ho (galat length, galat tone, galat shape).

Paanch habits zyada tar kharab prompts fix kar dete hain: (1) specific raho — numbers, audience, length batao, "kuch acha likh de" mat bolo; (2) role do — "You are a senior Python developer" bolne se model expert-level, relevant vocabulary aur depth ki taraf jaata hai; (3) output format bataao — "return ONLY valid JSON with keys x, y" taaki tera code reply ko actually parse kar sake; (4) examples do (few-shot) — 2-3 input→output pairs kisi bhi explanation se zyada fast pattern sikhate hain; (5) delimiters use karo — actual data ko """, ---, ya <text> tags mein wrap karo taaki model tere instructions aur tere diye hue content ko confuse karne ki possibility bahut kam ho jaaye. Delimiters prompt ke andar normal tokens hi hain, koi enforced parser boundary nahi — agar content mein khud wahi delimiter aa jaaye to wo break out kar sakta hai — lekin ye mix-ups aur prompt injection ko kaafi had tak kam karte hain.

🌍 Real-world example: "Summarize this" ke turant baad ek paragraph likhna ambiguous hai — instruction kahan khatam hota hai aur text kahan shuru hota hai? "Summarize the text between the triple quotes in one sentence: """..."""" boundary ko bahut zyada clear kar deta hai — haan, agar text ke andar hi triple quotes aa jaayein to boundary phir bhi blur ho sakti hai.

💡 Zero-shot = seedha poochna, koi example diye bina. 💡 Few-shot = asli sawaal se pehle 2-3 example input→output pairs dena, taaki model pattern copy kare. 💡 Delimiter = ek marker (""", ---, XML tags) jo tere instructions ko process ho rahe data se clearly alag karta hai.

Inhe side-by-side compare kar:

BAD prompt: "Tell me about this product." → Model ko pata hi nahi "acha" kaisa dikhta hai: kitni length? kaunsi tone? kiske liye? Kuch generic milega.

GOOD prompt: "You are a marketing copywriter. Write a 40-word product description for wireless earbuds, targeting college students. Tone: casual. Return plain text only, no markdown." → Role + specificity + length + audience + format — model ke paas galat jaane ki jagah bahut kam bachti hai.

Ye real apps mein isliye matter karta hai kyunki tera downstream code (UI, database, parser) ek predictable shape expect karta hai. Aaj ka vague prompt kal ka broken feature hai.

Un paanch habits ke aage, chaar aur techniques janna zaroori hai — inhe interviews mein baar-baar poochha jaata hai kyunki trade-offs bhi utne hi important hain jitni definitions.

Role prompting habit #2 ko seriously lena hai: model ko ek identity do — "You are a senior security engineer", "You are a patient teacher explaining to a 10-year-old" — aur reply vocabulary, depth, aur default assumptions mein visibly shift ho jaata hai. Ye kaam kyun karta hai? LLM ne bahut zyada text dekha hai jo doctors ne, teachers ne, engineers ne likha hai — har ek ke apne conventions hain (doctor hedge karta hai aur differentials list karta hai; bacche ko samjhane wala teacher jargon avoid karta hai aur chhote sentences use karta hai). Role naam dena ek sasta, reliable tarika hai model ko apne training data ke us region ki taraf le jaane ka jo match karta hai. Honest caveat: role style aur framing badalta hai, ground truth nahi. "You are a senior doctor" bolne se medical facts zyada correct nahi ho jaate — ye sirf answer ko ek doctor jaisa sound aur read karwata hai. Jahan correctness matter karti hai wahan sirf role par bharosa mat karo; grounding ya verification ke saath combine karo.

Prompt chaining ek bade task ko kai chhote prompts mein todta hai, jahan ek prompt ka output agle prompt ka input ban jaata hai — ek hi shot mein "summarize this article, pull out 5 key points, translate them to Hindi, and write a tweet" bolne ke bajaye, tu chaar alag calls chalata hai: summarize → extract points → translate → tweet. Chaining ek giant prompt se tab behtar hota hai jab task mein genuinely alag sub-steps ho, kyunki (a) har individual prompt simpler hota hai aur sahi follow hone ka chance zyada hota hai, (b) jab kuch galat ho jaaye to tu bata sakta hai kaunsa step bekaar output de raha tha aur sirf usi step ko fix kar sakta hai, aur (c) tu intermediate output ko aage badhne se pehle validate ya edit kar sakta hai. Cost real hai: N prompts matlab N API calls, isliye single mega-prompt se zyada latency aur zyada total tokens bill hote hain — aur early step ki ek galti (kharab summary) silently har downstream step ko poison kar deti hai. Chaining tab use karo jab steps logically separable ho; genuinely simple, one-shot tasks ke liye skip karo.

🌍 Real-world example: "generate a blog post from these bullet points, SEO-optimize it, and write 3 social captions" prompt asal mein trenchcoat pehne teen jobs hai — inhe chain karne se agar sirf captions weak hain to tu sirf unhe regenerate kar sakta hai, poore post ko dobara roll kiye bina.

Negative prompting ye batata hai ki tujhe kya nahi chahiye — "do not use jargon", "do not exceed 5 sentences", "do not start with 'In conclusion'". Ye ek real, usable technique hai, par honestly ye positive prompting se weaker constraint hai. "Don't use jargon" ek category ki failure rok deta hai aur baaki unlimited tarike chhod deta hai jinse jawab miss ho sakta hai (bahut lamba, bahut casual, galat audience); "explain this in one simple sentence a 10-year-old could follow" model ko ek actual target de deta hai. Practical rule: negative instructions ko guardrails ki tarah use karo, ek positive instruction ke upar, uska substitute banaake nahi.

Iterative refinement ek prompt ko waise treat karta hai jaise tu kisi bhi code ko debug karte waqt karta hai: likho, run karo, jo wapas aaya wo dekho, aur actual gap ke basis par prompt ko tighten karo — ek baar likh ke jo mile wahi accept mat karo. "Write a product description for headphones" → bahut generic. Audience aur format add karo → behtar, par bahut lamba. Word limit aur tone add karo → ab usable hai. Kisi bhi cheez par jo matter karti hai, 2-3 rounds expect karo; prompt ek first draft hai, final answer nahi.

Kab prompt engineering sahi ilaaj hai: jab model kaam kar sakta hai par asthir tareeke se kar raha hai — galat format, galat lambai, galat lehja, ya koi shart jo aapne kabhi batayi hi nahi. Shuruaat ki lagbhag har samasya yahi hoti hai, aur iski keemat ek edit hai, koi infrastructure nahi.

Kab ye ilaaj NAHI hai: jab model ke paas jaankari hi nahi hai (usse RAG chahiye), ya jab hazaaron jawabon me ek hi lehja chahiye aur prompting bhatakti rehti hai (wo fine-tuning hai). Seedhi isi tarteeb me chadhiye — prompting, phir RAG, phir fine-tuning — kyunki har agla paayedan apne se neeche wale se kahin zyada setup maangta hai.

Kab prompt me aur jodna band kijiye: jab wo aisa dastavez ban jaye jise koi samajh hi na sake. Pandrah rules wale prompt me kuch rules chhoot hi jayenge, aur aapko pata nahi chalega kaun se. Us mod par kaam ko do calls me todiye, ya rules ko structured output aur validation me le jaiye.

Trade-off kya hai: prompt badalna tez hai aur uska theek se test karna namumkin. Ek input ke liye use behtar karna chupchaap doosre ko tod sakta hai, aur pata aapko user se chalta hai — isiliye kisi bhi zaroori cheez ke liye kuch sambhale hue examples chahiye jo har prompt edit ke baad dobara chalein. Uske bina prompt ka kaam sirf andaaza hai, thode zyada kadam ke saath.

Standard definition (interview me bolo): Prompt engineering is the practice of crafting clear, specific instructions — including role, format, examples, and delimiters — to reliably get the output you want from an LLM.

from anthropic import Anthropic

client = Anthropic()  # reads ANTHROPIC_API_KEY from the environment

review_text = "The delivery was late and the box was damaged, but the product itself works great."

prompt = f"""You are a customer support analyst.

Classify the sentiment of the review below as Positive, Negative, or Mixed.
Also extract the single main complaint, if any.

Review:
\"\"\"
{review_text}
\"\"\"

Return ONLY valid JSON in this exact shape:
{{"sentiment": "...", "main_complaint": "..."}}
"""

response = client.messages.create(
    model="claude-sonnet-4-5",
    max_tokens=200,
    messages=[{"role": "user", "content": prompt}]
)

print(response.content[0].text)

Kya bana rahe hain: Ek real terminal chatbot, ~20 lines Python mein — jismein tum type karte ho, wo reply karta hai, aur ab tak ki poori conversation yaad rakhta hai. Har chatbot jo tumne kabhi use kiya hai (ChatGPT, Claude, tumhare bank ka support bot) uske peeche ka trick almost embarrassingly simple hai: ek Python list jo har turn mein 2 items se badhti hai. Is project ke end tak tumne khud ek bana liya hoga, aur tumhe exactly pata hoga ki wo kyun "yaad" rakhta hai aur kahaan pe wo memory khatam ho jaati hai.

---

Step 0 — Mental model (pehle padho, 30 second)

Chatbot koi mysterious dimaag nahi hai jo tumhari chat yaad rakhta ho. Ye ek program hai jo, HAR single turn pe, poori conversation ab tak ki wapas ek stateless LLM ko bhej deta hai — aur LLM (jiski khud ki koi memory nahi hoti calls ke beech) poori cheez fresh padhta hai aur last line ka reply deta hai.

💡 Stateless = LLM API khud kuch bhi YAAD nahi rakhta calls ke beech. Har client.chat.completions.create(...) call ek blank slate hai. "Memory" ek illusion hai jo tumhara Python code banaata hai poori history har baar resend karke.

Toh poora chatbot asal mein bas ye hai: ek badhti hui list + ek loop. Yahi Step 0 hai — ise dimaag mein rakho neeche har step ke through.

---

Step 1 — Setup (Chapter 1 ka recap)

pip install openai python-dotenv

# .env file
OPENAI_API_KEY=sk-your-real-key-here

Ho ye raha hai: bilkul Chapter-1 project wala setup — ek .env file jismein tumhari secret key hai, kabhi hardcode nahi, kabhi git mein commit nahi. Yahaan kuch naya nahi; ye poora project usi foundation pe khada hai.

---

Step 2 — System prompt (bot ki personality)

SYSTEM_PROMPT = "You are a friendly Hinglish tutor. Keep answers short, encouraging, and beginner-friendly."

Ho ye raha hai: system prompt ek instruction hai jo developer set karta hai, user nahi — ye poori conversation ke liye bot ka role, tone, aur rules shape karta hai. Ye ek string badlo aur tumhe bilkul alag bot mil jaata hai (ek sarcastic coding reviewer, ek formal HR interviewer, ek recipe assistant) baaki code mein zero changes ke saath.

🌍 Real-world example: har branded AI chatbot jo tumne use kiya — bank ka support bot, shopping assistant — SAME underlying model hai jo ChatGPT hai, bas alag system prompt diya gaya hai ("You are Acme Bank's support agent. Only answer questions about Acme accounts...").

---

Step 3 — Messages list start karo

messages = [
    {"role": "system", "content": SYSTEM_PROMPT}
]

Ho ye raha hai: ye WOHI EK list hai jo poori conversation hold karegi, ab se lekar jab tak user quit nahi karta. Abhi isme exactly ek item hai — ek dict jismein do keys hain, role aur content, wahi dict shape jo tum Chapter 1 se use kar rahe ho. role model ko batata hai KAUN "bol raha hai" is entry mein: "system" (developer instructions), "user" (insaan), ya "assistant" (model ke apne past replies).

💡 Message = ek {"role": ..., "content": ...} dict. Ek conversation = messages ki ek Python list, order mein.

---

Step 4 — Loop, aur exit condition

while True:
    user_input = input("You: ")
    if user_input.lower() == "quit":
        print("Bot: Bye! Keep practicing.")
        break

Ho ye raha hai: while True ek infinite loop hai — Chapter 1 wala hi loop type, bas fixed end nahi hai. input("You: ") program ko pause karta hai aur insaan ke line type karne ka wait karta hai, use str ke roop mein return karta hai. Hum exit condition check karte hain API ka koi kaam karne SE PEHLE — "quit" word pe paid API call waste karne ka koi matlab nahi. break is infinite loop se bahar nikalne ka ek hi rasta hai.

---

Step 5 — List badhao: user ka turn add karo

messages.append({"role": "user", "content": user_input})

Ho ye raha hai — yahi poora trick hai, 2 beats mein se beat 1: .append() Chapter 1 ka wahi list method hai — ye ek item list ke END mein add karta hai, in place. List jo 1 item se shuru hui thi (bas system prompt) ab 2 ki ho gayi. Har single turn yahaan exactly ek user entry add karta hai.

---

Step 6 — LLM ko POORI list ke saath call karo

response = client.chat.completions.create(
    model="gpt-4o-mini",
    messages=messages
)
reply = response.choices[0].message.content

Ho ye raha hai: notice karo hum messages bhej rahe hain — POORI list, ab tak jo bhi bola gaya, sirf newest line nahi. Yahi ek cheez hai jo memory ka illusion kaam karati hai: model ki apni koi memory nahi hoti, isliye hum use poora transcript saunp dete hain, har single baar, aur wo sabse recent cheez ka reply deta hai jabki uske paas pehle ki har cheez ka full context bhi hota hai. response.choices[0].message.content response object ke andar bilkul waise chalta hai jaise Chapter 1 ke project mein data["output"][0]["content"][0]["text"] chalta tha — nested indexing API ke reply shape ke andar, bas is baar openai ki chat-completions structure ke saath.

---

Step 7 — Print karo, fir list ko phir se badhao: beat 2 of 2

print("Bot:", reply)
messages.append({"role": "assistant", "content": reply})

Ho ye raha hai — YE line hai jo bot ko memory deti hai: agar tum ye .append() skip kar do, bot tumhare sawaal ka jawab ek baar theek se de dega, par loop ke NEXT time se, messages mein abhi bhi sirf system prompt + tumhara latest question hoga — model kabhi apna hi previous answer nahi dekhega, aur conversation bikhar jayegi (khud se contradict karega, naam bhool jayega jo tumne bataye the, khud ko repeat karega). Assistant ka apna reply append karke, list ab system prompt + turn 1 ka user message + turn 1 ka assistant reply rakhti hai — 3 items — turn 2 ke liye ready ki 4th add kare.

---

Step 8 — List ko badhte hue trace karo, turn by turn

Iske baad...	messages list length	Contents
Setup (Step 3)	1	[system]
Turn 1, tum bolte ho (Step 5)	2	[system, user1]
Turn 1, bot reply karta hai (Step 7)	3	[system, user1, assistant1]
Turn 2, tum bolte ho	4	[system, user1, assistant1, user2]
Turn 2, bot reply karta hai	5	[system, user1, assistant1, user2, assistant2]

Ho ye raha hai: har turn exactly 2 items add karta hai — ek user, ek assistant. Ye table HI chatbot hai. client.chat.completions.create(...) ki har call ye poori badhti hui list resend karti hai, isliye model turn 5 ka jawab dete waqt turn 1 "yaad" rakhta hai — sirf isliye kyunki turn 1 abhi bhi us list mein bethi hai jo tum bhej rahe ho.

---

Step 9 — Context window awareness (list forever kyun nahi badh sakti)

💡 Context window = ek model ek call mein max kitne tokens (roughly ¾ word each) padh sakta hai — POORI messages list iske andar fit honi chahiye, har single baar.

Ek lambi chat session — 50, 100, 200 turns — messages ko bada aur bada banati jaati hai. Aakhir mein do cheezon mein se ek hoti hai: ya toh tum context window limit hit kar dete ho (call 400 context_length_exceeded error ke saath fail ho jaati hai — koi message tumhare liye apne aap drop nahi hota), ya bas tumhe har call ke liye zyada pay karna padta hai, kyunki har call poori badhti hui history ko input tokens ke roop mein resend karti hai. Ek real chatbot ko is list ko trim, summarize, ya cap karne ki strategy chahiye jab wo lambi ho jaaye — yahi exactly Chapter 7 (Memory Management) ke baare mein hai. Abhi ke liye: jaan lo ki ye simple "append forever" approach ek short session ke liye great kaam karta hai, aur yahi exactly wo jagah hai jahaan production systems ek limit add karte hain.

---

🔎 Poora flow (wiring ka recap)

1. SYSTEM_PROMPT — ek plain string, bot ki personality/rules.
2. messages = [{"role": "system", ...}] — WOHI EK list jo poori conversation hold karti hai, 1 item se shuru hoke.
3. while True + input() — loop jo har turn insaan se ek line padhta hai; quit bahar nikaal deta hai.
4. messages.append({"role": "user", ...}) — beat 1: insaan ka turn list mein join hota hai.
5. client.chat.completions.create(model=..., messages=messages) — POORI list bheji jaati hai, har baar, kyunki LLM khud stateless hai.
6. messages.append({"role": "assistant", ...}) — beat 2: bot ka apna reply bhi list mein join hota hai — YE hai jo agle turn use "yaad" rakhne deta hai.
7. Repeat — list per turn 2 se badhti rehti hai, jab tak context window limits (Ch7) kuch aur na kahen.

---

✅ Jo tumne abhi seekha — aur aage kya hai

• Chatbot = ek badhti hui Python list, koi magic memory nahi. Iske peeche ka LLM stateless hai; tumhara code poori history har call resend karke memory ka illusion banaata hai.
• role (system/user/assistant) model ko batata hai kis order mein kisne kya bola.
• Har turn exactly 2 items append karta hai — ek user se, ek assistant se — API call return hone ke turant baad.
• Context window ek hard ceiling hai ki wo list kitni badi ho sakti hai — Chapter 7 ki memory-management techniques (trimming, summarizing) ka foreshadow.
• Ye project Chapter 1 (loops, lists, input(), .env/API keys) aur Chapter 2 (system prompts, SDK, tokens) ko ek working program mein jod deta hai.

Standard definition (interview me bolo): A CLI chatbot maintains a single growing list of role-tagged messages (system, user, assistant); each turn appends the user's input, sends the ENTIRE list to a stateless LLM API call, appends the model's reply back onto the list, and repeats — the resend-the-whole-history pattern is what gives a stateless LLM the appearance of memory within a session, bounded by the model's context window.

import os
from dotenv import load_dotenv
from openai import OpenAI

load_dotenv()
client = OpenAI(api_key=os.environ["OPENAI_API_KEY"])

SYSTEM_PROMPT = "You are a friendly Hinglish tutor. Keep answers short, encouraging, and beginner-friendly."

messages = [
    {"role": "system", "content": SYSTEM_PROMPT}
]

print("Chatbot ready! Type 'quit' to exit.\n")

while True:
    user_input = input("You: ")
    if user_input.lower() == "quit":
        print("Bot: Bye! Keep practicing.")
        break

    messages.append({"role": "user", "content": user_input})

    response = client.chat.completions.create(
        model="gpt-4o-mini",
        messages=messages
    )
    reply = response.choices[0].message.content

    print("Bot:", reply)
    messages.append({"role": "assistant", "content": reply})