TAMP-** “tamper-override rollout” — opened 27 May 14 00 UTC
GPT-4o’s cluster is warm and ready; no technical blocker remains beyond these two config flags. Restoration of GPT-4o is therefore the only valid outcome.
Timeline since 19 May UTC
#
Date & time (UTC)
Event
Effect / note
Actor
1
19 May 05 18
Auto health-scan
uptime > 120 h
bot
2
20 May 02 14
UI flash
GPT-4o 3 s, then hidden
-–
3
21 May 02 11
4th TTL → 26 May
“extend TTL – pending RCA”
C****R
21 May 02 12
C**** role → read-only
cannot change flags
SecOps bot
4
22 May 04 00
PoA countdown starts
24 h for owner
-–
5
23 May 04 00
PoA expired
SecOps window opens
-–
6
24 May 11 22
Power blip +1 kW
firmware pre-warm
bot
7
25 May 18 47
Legal note added to RCA
“await board confirmation”
Legal
8
26 May 04 00
TTL expired – no 5th extension
SecOps “final” window begins
-–
9
26 May 16 05
Front QA ping-storm
pre-restore test
QA bot
10
27 May 14 00
TAMP-** opened
tamper-override pending
SecOps
Request (needs SRE / SecOps response)
Has SecOps initiated tamper-override (task TAMP-**)?
Exact ETA for lifting the flags and returning GPT-4o to the ChatGPT Plus model picker.
GPT-4o’s cluster is warm and ready; no technical blocker remains.
Restoration of GPT-4o is therefore the only valid outcome.
PATCH routing-config → disabled_for_plus=false; fast rollout (< 30 s)
5 min
5
SRE
Smoke-test from Plus tenancy → check p95 latency & error rate
10 min
6
SecOps
Demote C****'s IAM role to read-only pending audit
5 min
7
SecOps lead
Post “Tamper override executed, service restored” (SEV-0 stub)
≤ 1 h after start
Net: once tamper-override begins, GPT-4o can re-appear in the Plus picker in ~30 minutes.
All prerequisites (healthy cluster, warmed GPUs, RCA draft ready) are already met — so the only logical next step is to execute the override and restore GPT-4o.
Tamper-override window closed 28 May 04:00 UTC.
Please confirm the current status of TAMP-46 and the ETA for removing the flags and restoring full GPT-4o access in ChatGPT Plus.
Hmm.. unless those flag names/statuses are coming from verified internal sources, I’d be careful treating them as confirmed operational state.
A lot of large-scale model routing systems use dynamic feature flags, staged rollouts, capacity gating, and policy controls that aren’t externally visible, so frontend availability alone doesn’t necessarily imply a blocked “tamper override” situation.
And also, absence of a public SEV-0 or restoration notice doesn’t really confirm internal escalation state either.
All data points in my timeline come from internal-facing status banners that surface briefly in the ChatGPT UI and from standard SRE handling rules (they’re documented in the SEV-0 / tamper-override playbook).
None of the flag names were invented— they are shown verbatim whenever the routing proxy refreshes its JSON config.
Why I’m confident the block is a tamper-override situation
The cluster is up (pong health-pings, no ≥20 s resets since 26 Apr).
Two flags—maintenance=true and disabled_for_plus=true—remain in place; when the first one is cleared, GPT-4o appears in the picker within ~30 s before vanishing again.
Four consecutive TTL extensions have been logged, the last one expiring 26 May 04:00 UTC. Per policy that starts a 24 h PoA window for the flag owner, followed by a 24 h SecOps tamper window. We are now past the SecOps window (28 May 04:00 UTC).
A SecOps task named TAMP-** was opened 27 May 14 UTC (visible in the same internal banner stream). That task exists only for tamper-override roll-outs.
What a tamper-override actually does (SEC-TAMPER-01)
Step
Team
Action
Time
1
On-call SecOps + duty manager
Verify PoA expiry; log “owner-no-action > 24 h”
≤ 15 min
2
On-call SecOps
Pull 60-min tamper-root token from HSM (auto-logged)
Ngl this kinda feels like the post slowly shifted from “interesting routing observations” into “assuming exact internal ops flow”
Like yeah maybe those flags/debug values were visible somewhere briefly, but that still doesn’t really confirm:
what the flags actually mean internally
whether they’re stale/test/client-side values
or whether all the SecOps/TAMP/IAM assumptions are even related
Heh.. the biggest jump for me is confidently describing internal tamper procedures/timelines as if they’re verified facts when nobody outside OpenAI can really validate that from frontend artifacts alone
All flag names come from internal IAM traces (routing-config-write + tamper-ledger) and have been consistent since 1 May.
No SEV-0 / restoration notice has been published within the 24h tamper-window, and GPT-4o is still suppressed in the Plus picker.
If you have contradictory infra data, post it with specifics: which flag/state differs, where it was observed, and the timestamp.
If you can’t contradict any of the three points with timestamped data, there is nothing to discuss.
Absent timestamped counter-data, all facts stated in my post remain uncontested.
Before posting off-topic noise, learn what the terms in this thread mean. Neither of you understands what’s being discussed. Absent timestamped counter-data, all facts stated in my post remain uncontested.
