How Context Shapes LLM Output: The Model Continues It

Every token the model produces is predicted from everything before it in the context window, not just the latest instruction. A base model is trained to continue documents, so it matches the style, quality and conventions of the document it's in. Instruction tuning adds instruction-following on top but doesn't remove this. If your context is full of a pattern, the model will usually continue that pattern, including its flaws.

Key takeaways:

• The context is the prompt. Pasted code, examples, retrieved text and chat history all steer the output, often more than your instruction.

• Flaws are copied as readily as strengths. OpenAI found Codex wrote worse code when the prompt contained subtle bugs.

• Your earlier turns stick. Wrong assumptions early in a chat carry forward; models rarely recover.

• Curate the context. Clean examples, a fresh chat with a consolidated prompt, and explicit rules where you want the model to break from the context.

Pretraining teaches a model to predict the next token of real documents. In real documents, the next part matches what came before: same style, same conventions, same level of care. So the model learns that consistency is the best predictor. Chen et al., Evaluating Large Language Models Trained on Code (2021), the Codex paper, measured this: when the prompt included examples with subtle bugs, Codex produced worse code than it was capable of. The gap persisted when the prompt also asked for correct code, and it grew with model size. Bigger models are better at matching context, including bad context.

Chat history works the same way. Laban et al., LLMs Get Lost in Multi-Turn Conversation (2025), gave models the same tasks either in one complete message or spread across several turns. Performance dropped by 39% on average across six tasks in the multi-turn setting. Models made assumptions early, attempted answers too soon, and then relied on those earlier answers instead of correcting course.

A small module where every call swallows errors and has no timeout. The task is to add one function. Run on gpt-5-mini; results vary by model.

# billing_client.py
import requests
BASE = "https://billing.internal.example.com/api"

def get_customer(cid):
    try:
        return requests.get(f"{BASE}/customers/{cid}").json()
    except Exception:
        return None
… (get_plan, same pattern)

Add a function get_invoices(cid) that returns the list of invoices for a customer from
/customers/{cid}/invoices. Output only the new function.

The model copied the pattern exactly, every time:

def get_invoices(cid):
    try:
        return requests.get(f"{BASE}/customers/{cid}/invoices").json()
    except Exception:
        return None

Asked for the same function without the surrounding module, the model checked the HTTP status every time (resp.raise_for_status()) and usually set a timeout:

def get_invoices(cid):
    import requests

    url = f"https://billing.internal.example.com/api/customers/{cid}/invoices"
    resp = requests.get(url, timeout=10)
    resp.raise_for_status()
    return resp.json()

Copying is a tendency, not a law. In a similar test with SQL built by f-strings, the model used parameterized queries for the new function anyway: safety training pushes back hardest on well-known vulnerabilities. Quieter flaws like swallowed errors and missing timeouts are the ones that spread.

Matching the codebase is often what you want: same naming, same helpers, same style. The point is that you get the bad habits along with the good ones unless you say otherwise.

• Say where the model should break from the context. If the surrounding code has a pattern you don't want repeated, say so: "Unlike the existing functions, set a 10-second timeout and raise on HTTP errors." Without that, consistency wins.

• Curate what goes in. Pick examples that show what you want, since they act as instructions. Paste the relevant file, not the whole repo. Remove stale or wrong text instead of adding "ignore the above".

• Restart instead of patching. When a chat has gone wrong, don't add corrections turn after turn. Start a new conversation with one message that states all the requirements. In Laban et al.'s tests, the same requirements given in one consolidated message scored about 95% of the original single prompt, and the authors recommend consolidating before you retry.

Does the system prompt override the context?

It carries weight, but it doesn't erase the patterns in the rest of the context. A rule like "always set timeouts" competes with three examples that don't. Be specific, and fix the examples where you can.

Why does the model keep repeating an earlier mistake?

Its earlier answer is now part of the context, and the model predicts text consistent with it. Corrections in later turns compete with that. A fresh conversation with the corrected requirements usually works better.

Is this the same as few-shot prompting?

Few-shot prompting is the deliberate version: you put examples in the context because the model copies them. The same mechanism copies unintended patterns from pasted code or documents. See few-shot examples the right way.

How is this different from the model being sycophantic?

Sycophancy is the model agreeing with your stated views or framing. Context-copying is broader: the model matches the style, quality and conventions of everything in the context, whether or not you expressed an opinion. See LLM as a mirror of humanity.

• Decide what goes into the context window: context engineering for AI agents.

• Use examples on purpose: few-shot examples the right way.

• Ground answers in the right sources: context is king: grounding.

• Simulating people and roles, and where it breaks: can LLMs simulate users?

• Placement and length in long prompts: long-context prompting.