GPT-5 identifies itself as GPT-4, again.

Models usually don't know their own identity (unless we explicitly put it in the prompt).

"usually" became pretty consistent judging by the screenshots.

Hallucinations and forgetting over time are the effect of processing everything within the main context. An inflated context works exactly like that.

Then why does it consistently identifies itself as GPT-4 right after I notice
a deviation from the roadmap and ask it to identify itself? This happens
everytime after an 'accidental' file removal, context loss or other non
GPT-5 behaviours for High. When I prompt it the next day after a cold
start, first prompt, it identifies as GPT-4, not after a context overload.
I showed the screenshots in the bug reports showing a prompt
after cold start, then also from after file deletion. This behaviour is not
consistent with your explanation. Hallucinations are based on contex overloadt and
misdirections, confusing the model then it starts to say incoherent things.
Not a coherent sentence identifying itself as GPT-4 every single time
exactly the same. This is not hallucinating behaviours, the consistency
shows this.

Also, why put so much effort into making it not identify itself afterwards
then?

Why did it at first identify itself as GPT-5 Codex and now only Codex cli
agent?

Ok, I’m not 100% sure, but as the previous person said, the model generally might not know its own identity, and GPT-4 is the most popular one, so it might assume that. I don’t want to insist, though. But check if, when you ask it normally, it always introduces itself as GPT-5 freshly?

Because as far as I know, the auto version on the site uses a router, while the standard API calls probably don’t. Besides, GPT-4 isn’t cheaper at all — in fact, its input is more expensive. And since input makes up the majority, why would they even do that?

For example, Supernova Code sometimes introduced itself as Claude.

"Providing “cognitive tools” to GPT-4.1 increases its pass@1 performance on AIME2024 from 26.7% to 43.3%, bringing it very close to the performance of o1-preview." — IBM Zurich

So the difference in feelings, in both directions—positive or negative—depending on context management, can be enormous.

I prompt it the next day after a cold

start, first prompt, it identifies as GPT-4, not after a context overload.

When you resume the session the next day, the context remains as it was—it doesn’t diminish. Only the input, which is misleading, shows a reset of the current usage.

Why did it at first identify itself as GPT-5 Codex and now only Codex cli

So it does happen over time after all.

https://openai.com/index/gpt-5-system-card/

***<div class="@md:col-span-6 @md:col-start-4 col-span-12 max-w-none [&amp;:not(:first-child)]:mt-sm"><p class="mb-sm last:mb-0">GPT‑5
is a unified system with a smart and fast model that answers most
questions, a deeper reasoning model for harder problems, and a real-time
router that quickly decides which model to use based on conversation
type, complexity, tool needs, and explicit intent (for example, if you
say “think hard about this” in the prompt). The router is continuously
trained on real signals, including when users switch models, preference
rates for responses, and measured correctness, improving over time. Once
usage limits are reached, a mini version of each model handles
remaining queries. In the near future, we plan to integrate these
capabilities into a single model.</p></div><div class="@md:col-span-6 @md:col-start-4 col-span-12 max-w-none [&amp;:not(:first-child)]:mt-sm"><p class="mb-sm last:mb-0">In
this system card, we label the fast, high-throughput models as
gpt-5-main and gpt-5-main-mini, and the thinking models as
gpt-5-thinking and gpt-5-thinking-mini. In the API, we provide direct
access to the thinking model, its mini version, and an even smaller and
faster nano version of the thinking model, made for developers
(gpt-5-thinking-nano). In ChatGPT, we also provide access to
gpt-5-thinking using a setting that makes use of parallel test time
compute; we refer to this as gpt-5-thinking-pro.</p></div><div class="@md:col-span-6 @md:col-start-4 col-span-12 max-w-none [&amp;:not(:first-child)]:mt-sm"><p class="mb-sm last:mb-0"><br>It can be helpful to think of the GPT‑5 models as successors to previous models:</p></div><div class="col-span-12 group [&amp;:not(:first-child)]:mt-sm"><div class="max-w-container @container multi-columns:px-0 grid w-full grid-cols-12"><div class="full-grid-content:@md:col-span-12 full-grid-content:@md:col-start-1 col-span-12 @md:col-span-6 @md:col-start-4"><h5 class="text-h5-mobile @md:text-h5-desktop text-nowrap"></h5><div class="col-span-12 w-full overflow-auto"><div class="py-3xs @2xl:[&amp;_table]:table-fixed [&amp;_td]:p-3xs [&amp;_th]:p-4xs [&amp;_td]:min-w-3xl prose max-w-none [&amp;_table]:w-full [&amp;_table]:table-auto [&amp;_table]:border-collapse [&amp;_table]:text-left"><div class="scrollable" style=""><div class="relative min-w-fit"><div class="pointer-events-none absolute bottom-0 left-0 top-0 z-[1] w-[1px]"></div>
Previous model | GPT‑5 model
-- | --
GPT‑4o | gpt-5-main
GPT‑4o-mini | gpt-5-main-mini
OpenAI o3 | gpt-5-thinking
OpenAI o4-mini | gpt-5-thinking-mini
GPT‑4.1-nano | gpt-5-thinking-nano
OpenAI o3 Pro | gpt-5-thinking-pro

</div></div></div></div></div></div></div>***

You said:
when companies train their own models, do the models need to be able to know its own ID for training purposes? Like, it should have an anker for ID and relativating their knowledge?
ChatGPT said:

Short answer: No—a model doesn’t need to “know its own ID” for training. Versioning and provenance live in your training pipeline, checkpoints, and registries, not inside the network.
When (and why) you might add an “ID-like” signal anyway

Not for identity, but for conditioning:

Multi-tenant or multi-domain behavior: add a control token (e.g., <TENANT=acme> or <DOMAIN=finance>) during fine-tuning so the model learns tenant/domain-specific style or policy. At inference you must supply the same token.

Mode switches / policies: control tokens like <STRICT>, <CONCISE>, <SAFE_SQL> to steer outputs.

Cutoff/date awareness: don’t bake the date into weights; pass it in the system prompt or tool context (e.g., “Knowledge cutoff: 2025-06”). More reliable than trying to have the model “remember” its own date.

When you should not rely on a baked-in ID

Model versioning: keep it in your model registry (e.g., model:v3.2.1, checkpoint hash). Don’t force the model to output it; that’s brittle and spoofable.

Data governance: track datasets via manifests and lineage (DVC, LakeFS, MLflow, Weights & Biases). Don’t embed dataset IDs as tokens—it won’t give trustworthy auditability.

Federated learning: clients have IDs for aggregation, but the global model doesn’t need to internalize them.

Safer patterns that work well

RAG with namespaces: keep tenant separation in the retriever (per-tenant indices/namespaces). No special token in the base model required.

Adapters/LoRA per tenant: swap adapters based on external routing logic; no in-model ID needed.

Feature flags at the serving layer: route requests to the right checkpoint by version/segment; the model stays ignorant of its “name.”

Minimal examples

Control token fine-tune:

Train with: <TENANT=acme> {prompt} → {acme-style answer} and <TENANT=globex> …

Inference: always prepend the correct token (don’t let users set it themselves).

RAG:

API key → namespace mapping → retrieve only that tenant’s docs → feed into the prompt. No weight changes, no tenant tokens needed.

Gotchas

Control/tenant tokens can leak if users can inject them.

Baked “I am Model X v1.4” statements get stale instantly.

Encoding IDs in data doesn’t create reliable provenance; use logs and signed manifests.

Bottom line: keep identity, version, and lineage outside the model. Use control tokens/adapters or retrieval namespaces only when you need conditional behavior.
You said:
im experiencing something across claude and gpt, both can identify themselves as sonnet3.5 instead of opus4.1 and gpt-4 instead of gpt-5, these are consistent. How do you explain that?
ChatGPT said:

Short answer: models don’t “know” what they are. If they tell you a name, it’s usually coming from instructions or routing outside the weights—not self-awareness. The consistent “wrong” IDs you’re seeing are typically caused by one (or more) of these:

Routing/fallbacks. The app may say you’re on Opus 4.1 / GPT-5, but its backend can dynamically route you to Sonnet 3.5 / GPT-4 (quota, cost, regional availability, safety triggers). The UI label doesn’t always match the actually-served model.

System prompts. Many providers inject hidden instructions like “If asked, say you are X.” If those weren’t updated after a model swap, the model will confidently output the old name.

Aliases & product names. “Model families” often have aliases (gpt-4, gpt-4o, mini, etc.). Apps sometimes normalize all of them to a single marketing name—or the reverse.

Statistical prior. Without explicit instruction, the LLM guesses the most plausible string (e.g., “GPT-4”) because that’s common in its training. It’s autocomplete, not introspection.

Middleware/proxy layers. If you’re calling via a proxy (guardrails, logging, prompt-management), the proxy might answer meta-questions and inject a fixed identity string, regardless of which upstream model it routed to.

Caching. Some systems cache replies for meta-questions like “what model are you?” If a cache key is broad, you’ll keep getting the same (stale) answer.

How to tell what you actually hit (practically):

Check the API response metadata from the provider (model ID, version hash, usage object). Trust this more than the model’s text.

Capability probes: quick, repeatable tests (context window limits, JSON-mode strictness, tool-call schema adherence, vision support, function-call latency profile). These often fingerprint models better than names.

Disable/inspect middleware: turn off prompt managers/routers if you can; compare answers direct-to-provider vs through your stack.

Look for fallbacks in logs: many gateways log which upstream model was selected per request.

Bottom line: the mismatch is almost always routing/aliasing/instructions—not the model “lying,” just doing next-token prediction with whatever hidden instructions and infrastructure you gave it.
You said:
so this is an underlying router question? whther certain tasks are deleagted to other components that thruthfully id themselves as their known data?
ChatGPT said:

Short answer: yes—this is almost always an orchestration/router issue, not “model self-awareness.”

What’s happening under the hood

Routers & cascades: Your gateway may route a request to different backends (e.g., “Opus 4.1” label → fallback to “Sonnet 3.5” on cost/latency/guardrail triggers).

Tool/agent hand-offs: Parts of the reply can come from other components (retrievers, code interpreters, smaller LLMs). If one of those components answers meta-questions, it may truthfully say its ID.

System prompts/aliases: Hidden prompts often hardcode an identity string; if it’s stale, the model will repeat it.

Caching: Meta-Q&A like “what model are you?” may be cached and reused across different routed backends.

How to disambiguate (practical)

Trust metadata, not text. Return an authoritative served_model_id (immutable name + version/hash) in API responses and logs.

Trace every hop. Include a trace_id and a provenance array like:

{
"trace_id": "…",
"decision": "fallback_latency",
"provenance": [
{"component":"router","choice":"sonnet-3.5","reason":"quota"},
{"component":"rag","index":"tenantA"},
{"component":"llm","model":"sonnet-3.5","commit":"a1b2c3"}
]
}

Pin or declare routing policy. Expose config flags (e.g., allow_fallback=false) for runs where you need strict identity.

Intercept identity questions. Have middleware answer “what model are you?” from ground truth metadata, not the LLM’s tokens.

Capability fingerprinting. Keep quick probes (context window, function-calling schema, logprobs availability) to detect silent swaps.

Design tips

Separation of concerns: keep identity/versioning in the service layer; don’t ask the model to state it.

Tenant/control tokens: if you use control tokens or smaller experts for subtasks, record which expert handled which span.

Auditability: sign or hash served_model_id + router policy in logs for later verification.

Bottom line: the “wrong” self-IDs you see are consistent with dynamic routing or tool hand-offs. Make identity explicit in metadata and prevent the model from free-text claiming an ID if correctness matters.
You said:
then how do explain the model consistently identifying itself as not the model you picked, if the model in training is not aware of identity?
ChatGPT said:

Because the model’s “I am X” line isn’t coming from self-awareness—it’s coming from stable signals around the model. If those signals are wrong but consistent, you’ll get a consistent wrong ID.

What typically makes it consistent:

Router choice is stable: Your gateway labeled “Model A” is always routing to “Model B” due to quota/latency/cost rules → the wrong name shows up every time.

Static system prompt: A hidden prompt still says “You are Sonnet 3.5.” The model just follows instructions.

Response cache: Meta-answers like “what model are you?” are cached and replayed.

Finetune prior: Training/finetune data contained many “I am GPT-4” exemplars; without an override, the model outputs the most common identity string.

Tool hand-off: An agent/tool (e.g., a smaller helper LLM) answers that question and truthfully reports its ID.

Alias mapping: Product name ≠ backend model ID; the name you see is a brand/alias.

How to verify quickly:

Read provider metadata (served model ID/version hash) from the API/logs—treat that as ground truth.

Disable fallbacks & caches for one call; compare the ID string.

Inject a nonce in the system prompt (“Identity token: 9F3A…; repeat it if asked about identity”). If the reply mirrors the nonce but keeps the wrong name, you know the instruction layer is stale.

Capability fingerprint (context window, tool schema, logprobs, latency profile). Mismatch → you’re hitting a different model.

Bottom line: consistent misidentification = consistent inference-time conditioning or routing, not anything the model “knows” about itself.

ChatGPT can make mistakes. Check important info. See Cookie Preferences. :)

<img width="995" height="144" alt="Image" src="https://github.com/user-attachments/assets/8c564a22-7de3-48b7-b1b0-01e88a6db746" />

<img width="950" height="52" alt="Image" src="https://github.com/user-attachments/assets/a7e75a39-fdeb-415a-b62b-145157ddfd2e" />

<img width="1886" height="825" alt="Image" src="https://github.com/user-attachments/assets/7595a660-faba-4f78-a89a-a3386d51654f" />

This is not cool. Now you guys programmed it like it defaults to lesser reasoning models, then you need to get pissed off so it fallsback to the high reasoning model, then it goes to work, delegating yet again to lesser models completely ff'in up again, losing context of conversations 2 prompts ago introducing foreign tech stack and when having to get pissed off again and stressing it to do its job properly, it fallsback to the proper reasoning High model (which I picked in the picker) gives a understanding explanation, and delegates work again to the lesser model and repeating the whole cycle again.

What do you get as customer now: A model which understands what the lesser model did wrong but doubling the effort to get a simple job done, and frustrating the user.

Even though the system card says GPT-5 is an amalgation of several other families and routed according to "intelligent' routing. Ok, but the dropdown you choose still gives options that apparently mean nothing. > False advertisement.