Reading GPT-6.5 Leaks Before a Codename Reversal Costs You a Migration
A tiered method for weighing GPT-6.5 rumors, a dated look at one reversed leak, and an alert setup that waits for API evidence.
On September 7, a respected independent analyst predicted that OpenAI's next flagship would be called GPT-6.5, that its codename was "Doug," and that it would be a change in kind rather than a bigger version of the same thing. By the next morning he had walked the claim back. If your team had opened a "GPT-6.5 migration" ticket that afternoon, you would have spent the next day unwinding it.
This post is about how I now read model rumors, using that episode as the worked example. The short version: a leak is a hypothesis, and most of the damage comes from treating a hypothesis as a schedule.
Sorting Signals Into Four TiersLink to this section
I stopped reading rumors as a single stream once I noticed they carry very different amounts of evidence. I sort everything into four tiers before it gets anywhere near a planning doc.
| Tier | Example | What it tells you | What it cannot tell you |
|---|---|---|---|
| 1. Analyst memos | Private or semi-public research notes | Direction and priorities | Names, dates, or whether a model exists |
| 2. Press reports | Sourced reporting on training runs | That work is happening | Final product names or launch timing |
| 3. Leaked names | Codenames, screenshots, video mentions | That a string circulated | That the string maps to a shipped model |
| 4. Verified API behavior | A model ID that answers an authenticated request | That something is callable | Pricing or limits unless the docs say so |
Only tier 4 changes what I do on a Monday. Tiers 1 through 3 are useful for deciding what to prepare, such as an eval set or a list of prompts to rerun. They are not useful for deciding what to migrate.
The Doug Timeline, Date by DateLink to this section
The sequence below is the one I would want a teammate to read before reacting to any GPT-6.5 post. I could not open the original SemiAnalysis memo while drafting, so the July date comes from the reporting trail rather than a copy I read. Treat it as secondhand.
- December 2025: The Information reported on a pre-training effort associated with the "Garlic" codename. This is a tier 2 signal: work happening, nothing shipping.
- July 9, 2026: A SemiAnalysis memo circulated that fed into the speculation about OpenAI's next large model.
- August 1, 2026: OpenAI published math and theoretical computer science results from an internal version of Astra and called it "our next major model." The post had no API model ID, no price, no rollout date, and it did not call Astra GPT-6 [1].
- September 3, 2026: GPT-6 Astra launched at $10 per million input tokens and $50 per million output tokens, with a context window of roughly 1.05 million tokens [2][3].
- September 5, 2026: The standard tier reached general availability [2].
- September 7, 2026: The analyst predicted GPT-6.5 with the codename "Doug" [2].
- About twelve hours later: He reversed the claim. His corrected reading is that "Doug" is the base model of Astra, which had already shipped [2].
The detail I keep coming back to is the order. The "next" model was already live two days before the rumor named it. The rumor was not forecasting a release. It was attaching a name to something that had already happened.
How a Codename Ended Up on the Wrong ModelLink to this section
Each piece of this story was partly true. A pre-training run existed, a codename circulated, and a product name was in the air. The error was in the join: the codename got attached to a future model name that did not correspond to anything OpenAI had announced. The corrected reading says the codename belonged to the base of a model that had already shipped [2].
That kind of error is easy to make and hard to notice from outside. Codenames are assigned to internal artifacts, and product names are assigned later, often after the artifact has changed shape. Anyone who reads "X is codenamed Y, and the next model is Z" is making two inferences at once, and only one of them has to be wrong for the whole chain to break.
The planning risk comes in three forms:
- Wrong target. An eval harness gets pointed at a model ID that does not exist. The tests fail, someone assumes the provider is broken, and the investigation starts in the wrong place.
- Wrong economics. A cost forecast gets built on a rumored price. Astra's published rates are the only ones I would put in a spreadsheet today [2][3].
- Stale correction. Even after a reversal, the original claim keeps circulating. Some sites recirculate old predictions after their date has passed, so I check page timestamps and history before trusting anything, including sources that cite the correction [1].
If you are tempted to act on a codename, ask one question: what would I expect to see on the API if this were real? If the answer is "nothing yet," the codename is a note, not a ticket.
A Watch Process That Confirms on the API FirstLink to this section
My process has three parts, in this order.
Confirm on a public APILink to this section
The strongest evidence is a model ID that answers an authenticated request. Documentation alone is weaker, and a dashboard screenshot is weaker still [1]. A basic check against the models endpoint looks like this:
curl -s https://api.openai.com/v1/models \
-H "Authorization: Bearer $OPENAI_API_KEY" \
| jq -r '.data[].id' \
| grep -i 'gpt-6'A listing is not the same as a working model. After a listing appears, I send a small completion request and record the response metadata. Only then do I compare published pricing and context limits against the provider's own documentation.
Check provider catalogsLink to this section
Third-party trackers are useful for alerting, but I treat them as an index, not a source. One tracker I looked at states plainly that it alerts on verified API behavior and not on announcements alone, and it names Astra as the current model in the line [3]. That is the right posture for a tracker. It is not a reason for my team to skip the provider's docs.
Some reports also tie Astra to a looped architecture and raise a safety question about how much of the reasoning is readable [4][5]. I file those as architecture reports. They may be right, but they do not change my integration.
Set alert thresholdsLink to this section
I encode the tiers as states so that alerts can carry their verification level. Here is the config I use:
model_watch:
target: gpt-6.5
poll_interval_seconds: 300
baseline:
model: gpt-6-astra
input_per_1m_usd: 10
output_per_1m_usd: 50
context_tokens: 1050000
verified_on: "2026-09-03"
states:
rumor: # codename or name seen in a memo, thread, or video
action: log_only
reported: # press or analyst report naming a model
action: note_in_tracker
name_seen: # official post names it, no API model ID
action: prepare_eval_no_migration
api_listed: # ID appears in authenticated /v1/models
action: run_eval_harness
require: [model_id_match, authenticated_200]
api_callable: # completion succeeds, docs match pricing
action: open_migration_ticket
require: [price_from_docs, context_from_docs, rate_limits_from_docs]
thresholds:
alert_on: api_listed
dedupe_window_minutes: 60
reversal_hold_hours: 24The reversal_hold_hours setting is the part that would have saved the team in the Doug episode. Any state below api_callable gets a 24-hour hold before anyone changes a plan, which covers the window in which the Doug claim was made and withdrawn.
The tradeoff is real. This setup costs a polling job, a key, and someone who owns the alert rules. If you are a small team with one model in production and no migration plans, skip it and read the provider's release notes weekly. The machinery pays off when a model change would touch prompts, evals, and budgets at the same time.
TakeawaysLink to this section
- Tag every model rumor with a tier before anyone discusses it. Only API-verified evidence should trigger a migration ticket.
- Use GPT-6 Astra's published figures, $10 and $50 per million tokens with about 1.05 million context tokens, as your baseline until the provider changes them [2][3].
- Check the model ID against an authenticated API request and the provider's own docs, not a blog quoting another blog [1].
- Put a hold on any plan change driven by a codename or a reversed claim. Twenty-four hours is a reasonable default.
- Ask what you would see on the API if the rumor were true. If the answer is nothing, keep the rumor in the notes and out of the sprint.