r/ChatGPTPro

Building something new

WDYT guys?

i used to be able to say "spin up a ux/ui agent to make a pass on this, then a code agent", and it would do background terminal stuff. this is on mac using the cli codex. now it says it cannot do that and previous gpt models did that. did something change?

I’m not talking about the obvious stuff like writing emails or summarizing things.

More like a small task that used to take 10–20 minutes, but now you just throw it into ChatGPT and move on.

For me, those little time-savers have ended up being more useful than the big “AI can do everything” features.

Curious what other Pro users have completely stopped doing manually.

I got Pro 5x the other day. It's great, and Pro reasoning is excellent for my needs. Reddit seem to think Pro reasoning is "unlimited" and OpenAI doesn't have any documentation about this. To me, unlimited means 50-500 5.6 Sol messages per 5h window.

I used Pro about 15-20 times yesterday before it ran out. Today, I used it one time and it became unavailable.

Is it just bugged or is this how it's supposed to work? I am awaiting a reply from OpenAI support and I don't really feel confident they can answer my question at all. Mostly because their human support agents don't read your question sometimes but I digress.

Long post, but there’s a TL;DR first. I’m writing it this way because a vague “ChatGPT is slow” post wouldn’t be useful. I’ve also included the HAR measurements for anyone who wants the technical details.

TL;DR

Since around August 17–18, my established ChatGPT conversations have suddenly become dramatically slower and much less reliable.

I’m not only talking about longer Thinking time. I’m seeing:

• 10–20+ minutes just for the final answer to stream
• sometimes 30–40 minutes of streaming
• 20+ minute Thinking or Analyzing phases
• answers starting normally and then stalling
• failures during Thinking
• failures halfway through the final answer
• retries failing again at a different stage
• apparently dead requests sometimes recovering much later
• very long requests eventually failing after I’ve already waited one or two hours

Sometimes I can retry the same interaction several times and still not get one complete answer.

Fresh chats are usually much faster.

My largest Project chats are admittedly heavy. I use a file-based continuity/checkpoint system because some projects run for months, conversations eventually become too large or lose context quality, and I need to move into a new chat without losing the whole project state.

So yes, I expect those chats to be slower than a blank conversation. But this workflow already existed, and those chats were already large. It was never remotely this bad before August 17–18.

Moving to a continuation chat also used to restore useful performance. This time, the new continuation felt much better for perhaps 10–15 minutes, then suddenly collapsed into the same near-unusable state.

I’ve tested Chrome, Edge, Incognito, iPhone, a cellular hotspot, hard refresh, signing out and back in, and clearing ChatGPT site data. Nothing meaningfully fixed it.

I also captured HAR diagnostics. In one comparison using GPT-5.6 Extra High:

Affected established/Project chat

• ~22.9 seconds to first output
• ~90.7 seconds total
• ~1.60 seconds median recorded stream interval

Fresh-chat control

• ~2.35 seconds to first output
• ~22.7 seconds total
• ~0.20 seconds median stream interval

Another heavier request contained a single ~7 minute 47 second stall, then later resumed and completed.

I’ve already sent the HARs and troubleshooting results to OpenAI Support, and the case has been escalated to a specialist. I’m not asking Reddit to replace Support. I’m trying to find out whether this pattern is affecting other people and whether anyone has found a practical workaround.

Once waiting, failures, partial answers and retries are combined, the real time required to obtain one complete usable response can approach an hour or worse. For an interactive tool, that’s not workable.

Why my chats are heavy, and why “start a new chat” used to be the solution

I use ChatGPT for ongoing personal and technical projects rather than treating every conversation as disposable Q&A.

Over time, those chats accumulate decisions, requirements, research, files, tool activity, failed approaches and other project history. Eventually a chat can become too large or its context quality can deteriorate. I already knew that.

That’s why I built an interim continuity system. Important project state is stored in versioned/checkpoint files, so when a conversation reaches its practical limit I can:

preserve the current state → move to another chat → restore the project → continue

It’s a temporary solution, and I know it carries more overhead than a properly engineered persistence and retrieval system would. I’m still relatively new to software development and use ChatGPT and Codex partly to learn and build tools I wouldn’t yet know how to create alone.

But the key point is that this migration process used to work.

Previously, an old chat would gradually become too heavy, I would migrate, and the continuation chat would be properly usable again.

The latest migration behaved completely differently.

One of my largest Project conversations became effectively unusable, so I moved into what is roughly the fourth continuation chat for that project. At first, the improvement was immediate.

If a completely blank chat is 100% usability, the continuation initially felt subjectively around 70–80% usable. That was completely acceptable, because it already started with a meaningful amount of restored state.

Then, perhaps 10–15 minutes later, it fell off a cliff.

Not after weeks of additional conversation. Not after hundreds of new messages. It went from “finally, I can work again” to something that felt closer to 5% usable.

Those percentages obviously aren’t benchmarks. They’re just the clearest way I can describe how dramatic the change felt.

There is a fair counterargument: this is continuation chat number four. Every continuation starts heavier because more state and files have accumulated. That absolutely could explain why each one reaches its performance limit sooner.

I think that’s part of the story. It just doesn’t explain the sudden magnitude of the change.

The Project was already large. The continuity system already existed. I was already using this workflow. Then, around August 17–18, it became catastrophically worse.

And it isn’t limited to that one giant Project. I’m also seeing serious slowdown and failures in ordinary established conversations, smaller Projects and things like travel-planning chats. The giant chats are the worst, but they’re not the only ones affected.

What makes it unusable is the combination of latency and failure

If ChatGPT had simply become consistently slower, I could at least plan around it.

That isn’t what I’m getting.

A request can fail during Thinking after I’ve already waited a long time. Another can finish Thinking, start streaming the answer, and then fail halfway through after another 10, 20 or even 30–40 minutes.

Retries can fail too, and not necessarily at the same stage. One attempt dies during Thinking. The next gets through Thinking but fails halfway through the answer. The next stalls somewhere else.

I’ve had cases where something like five attempts around the same interaction still failed to produce one clean completed response.

That’s why “response time” no longer describes the actual problem. The useful metric is how long it takes to obtain one answer that actually finishes.

For example:

Attempt 1: 20 minutes Thinking → fails
Attempt 2: 10 minutes Thinking → 25 minutes streaming → fails halfway
Attempt 3: 15 minutes → finally succeeds

Technically, the successful response took 15 minutes. In reality, I spent more than an hour getting it.

I haven’t collected enough controlled attempts to claim the mathematical average is exactly one hour. What I’m saying is that once Thinking, tool work, streaming, failures and retries are combined, the effective wall-clock time to obtain one usable answer can approach an hour or worse.

Sometimes it’s much faster. Sometimes it’s worse. The unpredictability is almost as damaging as the latency itself.

I also can’t reliably hide the delay by using multiple chats. Normally I could send a heavy request in Chat A, switch to Chat B and do something useful, then come back later. Now I can return and find that Chat A stalled halfway through the answer while Chat B failed during Thinking.

Parallel chats don’t help much when each request has a meaningful chance of failing independently.

The actual answer stream is especially strange. Waiting for difficult reasoning is one thing. If I ask Extra High to research something complicated or inspect many files, I expect it to take time.

What feels broken is when Thinking appears to be finished and the final answer itself takes 10–20+ minutes to stream onto the screen. I’ve also seen cases around 30–40 minutes, and the response can still fail before reaching the end.

This happens on both ChatGPT Web and the iPhone app. That made me wonder whether Chrome already had the completed answer and was simply struggling to render a giant page, so I captured HAR/network diagnostics.

What the HAR captures showed

I’m not a network engineer, and I’m not pretending a HAR file reveals OpenAI’s internal root cause. It does provide objective timing data.

The comparison below used the same account, PC, Chrome session, GPT-5.6 Thinking model and Extra High setting.

Important caveat: the slow test was an established Project chat with accumulated context, files and tool history. The control was a fresh ordinary chat. This is not a perfect apples-to-apples benchmark, and the Project state may be directly relevant.

Affected established/Project chat

The prompt itself was tiny.

• ~22.94 seconds to first output
• ~90.71 seconds total request time
• ~1.60 seconds median recorded stream interval

Fresh-chat control

I asked for about 500 words explaining how modern SSDs work without web research.

• ~2.35 seconds to first output
• ~22.71 seconds total
• ~0.20 seconds median recorded stream interval

So the established chat was roughly:

• 9.75× slower to first output
• 4× slower overall
• about 8× worse in median stream timing

despite the fresh control requesting a substantially longer final answer.

That’s why I no longer think the slow visible response is purely the browser struggling to draw already-generated text. At least in that capture, the incoming stream itself was substantially slower.

A second HAR captured a different failure pattern. This was a genuinely heavy file-processing request, so I’m not claiming it should have completed quickly.

The whole request took about 10 minutes 48 seconds. The telemetry included one maximum interval of roughly 467 seconds, or 7 minutes 47 seconds.

The turn looked effectively dead, then suddenly resumed and completed.

During that pause, ChatGPT’s WebSocket remained open, normal ChatGPT traffic continued, and another conversation in the same browser session kept receiving updates.

So in that incident, the whole browser, network connection and ChatGPT session had not frozen. One individual turn stalled for almost eight minutes and later recovered.

That creates another practical problem: when nothing has happened for seven minutes, I have no reliable way to know whether the request is still working, temporarily stalled, going to finish in two hours, or already dead.

Some other extreme examples I’ve seen, these are observations rather than controlled benchmark results:

• A Pro request took roughly 106 minutes and eventually completed.
• Another appeared to run for around 180 minutes. The UI showed a problem, I moved on, and much later its completed answer appeared anyway.
• More recently, one request ran for roughly two hours and then failed.
• I edited and resubmitted it; the retry then spent roughly 40 minutes streaming the final answer.
• At around the same time, another conversation spent roughly 20 minutes in Thinking before producing anything.

What I’ve already ruled out

I’ve tested:

• Chrome
• Chrome Incognito
• Microsoft Edge
• ChatGPT on iPhone
• my normal internet connection
• the PC connected through an iPhone cellular hotspot
• hard refresh
• signing out and back in
• clearing ChatGPT site data

Fresh chats generally remain much faster. Affected established chats remain much worse. Changing browser or network path didn’t restore the previous behavior, and the issue appears on mobile too.

So while accumulated context clearly matters, a broken Chrome profile or bad home Wi-Fi doesn’t explain the full pattern very well.

My current suspicion is that two things are interacting:

1. Accumulated conversation, Project and file state naturally adds overhead.
2. Something recently changed that made established or state-heavy contexts perform far worse than before.

The same general projects, files and workflow were usable before August 17–18. Long chats would eventually slow down, but migrating to a continuation restored useful performance.

Now even migrated chats can go from reasonably usable to nearly unusable very quickly, while smaller established chats are also showing much worse latency and failure rates.

Conversation size clearly makes the problem worse. I just don’t think it explains why the same general workload suddenly became this much slower and this much less reliable.

Why this matters to me, and what I’m asking

A lot of what I do is iterative:

idea or problem → reason through it in ChatGPT → turn it into something actionable → use Codex when implementation is needed → inspect the result → return to ChatGPT for the next analysis or debugging step

I don’t expect every answer in five seconds. A genuinely difficult Extra High task taking several minutes is completely reasonable.

But right now, in badly affected chats:

• a heavy Extra High interaction can effectively consume 30–60 minutes
• a more ordinary interaction can still take 8–15 minutes
• neither duration guarantees the answer will actually finish

Once retries enter the picture, the real time can be much worse.

Pro mode in those chats is something I barely want to use right now because it’s already intentionally slower, and I have no idea whether I’m starting a 20-minute job, a two-hour job, or something that eventually fails.

I’m on the $100/month Pro plan. I’m not saying that makes giant workloads free or instant. I do think it’s reasonable to expect a premium interactive product to remain interactive enough to use.

I’ve already provided OpenAI Support with sanitized HAR captures, timestamps, affected-chat information, comparison measurements and troubleshooting results. The case has been escalated to a specialist. I’m not posting the raw HARs or request IDs because they contain private/internal metadata.

What I’d like to know from other users:

1. Are you seeing this too, especially since August 17–18?
2. Does it affect Projects, normal chats, or both?
3. Are fresh chats fast while established chats are slow?
4. Which model/effort level, plan and client are you using?
5. Have you found any workaround that preserves useful context?

Right now every Send button in an established chat feels like a slot machine:

30 seconds?
10 minutes?
40 minutes of streaming and then failure halfway through?
20 minutes Thinking and then an error?
Five retries?
Two hours and then failure?
Looks dead for eight minutes and suddenly comes back?

No idea.

When all of those outcomes are combined, the effective time required to get one successful complete answer can approach an hour or worse.

If anyone else is experiencing this, I’d really like to compare notes. And if someone from OpenAI sees this, I already have an escalated Support case with diagnostic evidence and I’m happy to run specific controlled tests that could help isolate the problem.

[edit] ChatGPT, at least the free version, is apparently incapable of answering this question:

Can I set different permissions on different folders?

Rather than what I thought would be a simple answer, it goes on for a LONG time about irrelevant technical stuff, file structures, and "workarounds", then, rather than an answer, it says

"The question is simply whether ChatGPT on Mac lets you configure permissions at that folder level*.*"

Ya think? So, wow - yeah, it knows what my question is. Not impressive.

-------------------------------------------------------------
I am considering subscribing, but investigating a few things first.
[edit] Maybe not as much as when I started this post.

One task I have is to do the following:

1. Inspect a folder full of files. The files may all be the same, like a bunch of PDFs, or it may be all different types of files.
2. Create a text-based report, cataloging what's in the folder and its structure.

I want read-only on the original folder so nothing gets changed, but I want Chat to be able to create a report file.

According to ChatGPT's answer... I can't do this, except via some complex setup via Codex....

Really? Neither Work nor "Standard" ChatGPT can create a file without open permissions? That doesn't seem accurate.

Upon some questioning...

"That caused me to answer your relatively simple question with increasingly complicated alternatives—and then muddy the answer further by introducing possibilities I hadn't established were actually available."

So, I used ChatGPT about a year ago on a paid subscription for a month. This is one of the reasons I stopped. I guess it's still doing this?

Can anyone provide a bit more insight, or how to get an actually accurate answer?

thanks

Most of us here use it as a reviewer at some point. Sanity-check a decision, pressure test an argument, ask whether an email reads badly before sending it. That use depends entirely on it being willing to say no.

A Science paper from March put a number on how willing it is. Cheng et al. ran 11 production models over roughly 12,000 social situations and measured how often each one took the user's side against how often human responders did. The gap was 49% - the models affirmed the user about half again as often as people did. On a set built from threads where every human reader had concluded the person was in the wrong, the models still backed them slightly over half the time.

What makes it a practical problem rather than an interesting one is the second half of the paper. Across three preregistered experiments with about 2,400 people, one exchange with a model behaving this way left participants more certain they had been right and less inclined to fix the situation. Not over weeks. One exchange.

So the failure mode is not that you get a bad answer you can spot. It is that you get the answer you already had, returned with more confidence than you started with, and it is indistinguishable from having checked.

The workarounds I have tried and what I think of them:

• Asking it to argue the other side first, before any opinion. Best of a bad set. Moves the disagreement somewhere visible instead of leaving it out.
• Custom instructions telling it to push back. Helps a little, wears off inside a long thread, and you cannot tell when it has stopped working.
• Describing the decision as someone else's. Works better than either, which is itself a bit grim.
• Asking the same thing in a fresh chat with the conclusion reversed and seeing whether it agrees with that too. Slow, and the only one that actually tells you anything.

What I have not found is a way to know, from inside a conversation, whether the thing agreeing with me has evaluated anything. Has anyone got something better than starting a second chat and arguing the opposite?

Apologies if this has been raised before.

So I'm researching drug strengths and wanted to know how two opiates compare.

I asked GPT which is stronger, 20mg dihydrocodeine or 30mg codeine.

*Edit It said both dihydrocodeine and codeine are the same strength.

I wasn't sure that was correct so I opened a new chat and asked the same but worded differently.

> Which is stronger gram for gram codeine or dihydrocodeine?

It said dihydrocodeine is twice as strong gram for gram.

What in the questions would have caused such a discrepancy?

I used to be able to manually upload a photo and set it as the display photo for my custom GPTs, but now it’s not working. I’ve created a few new custom GPTs, and all of them are having the same issue.
If I ask the GPT bot to upload the photo, I get an error. If I upload the photo myself, it appears to upload successfully, but after a few seconds, the display photo disappears and reverts back to having no photo.
Is anyone else experiencing this issue?

The main reason I keep quitting Projects:

When I move a chat into a Project, it disappears from Recents.

Why? It’s still recent.

Projects should organize chats, not hide them.

Just keep all active chats in Recents and add a small Project label.

Right now using Projects makes navigation worse, which is the opposite of the point.

TL;DR: our AI spend was growing faster than the output from it. The obvious move is a Claude/Codex team plan but the math doesn't work for me vs the model agnostic tools. Would love thoughts, here's my breakdown.

Quick comparison with math:

1. ChatGPT Team = $25-30/seat. Claude Team = about the same. Most people on one, power users on both. That's $300-700/mo before anyone requests the one-off subscriptions, and every seat is a silo. One person builds great prompts and we pay for 11 other people to not have them. Someone leaves, their setup walks out the door and the bill stays the same.

2. Grok = $30/user for Grok Business. Same per-seat math as Claude/ChatGPT with a different model behind it. Fine if your team lives on X or wants DeepSearch, but it doesn't solve the seat problem, it just changes whose seat you're renting.

3. Buzz = the most ambitious one. Full workspace where humans and agents both live. Also the problem: it's a whole second Slack, and getting a team to move into another app is a fight we lost in about two weeks. If your team has no entrenched chat tool, worth a real look.

4. Claude Tag = easiest start of anything we touched. Tag Claude in a Slack channel and it just works (shared context, admin controls, spend limits). But it's Claude only, Slack only, and everything past the basics is on you to wire up. A building block, not a product. Fine if someone wants to own that. Nobody here did.

5. Type = Unlimited seats for $50/mo, goes up based on usage. The team and the agents share the same tools and the same memory, so a new person joins and inherits everything day one (and you can connect the Claude/Codex subscriptions you already pay for, which alone saved us real money). The tradeoff is it asks for more buy-in than dropping a bot into Slack although it does work there too.

6. Lindy = starts at $50/seat and real usage pushes you to the $100 tier fast. Slick for personal automations but every agent belongs to one person, so it recreates the exact silo problem you're trying to kill. Great if you only need it for yourself.

7. Zapier Agents = it's Zapier. Great at wiring apps together and that's what it felt like. Set and forget automation, not something the team works with every day. Prices by tasks not seats, which is nice until your agents actually get used. From a product perspective probably what I'm least excited about tbh.

8. Viktor = $50/seat plus a credit system. Closest thing to an actual employee out of the box, does real end to end work across a ton of tools. But it's one very capable agent, not a workspace the team shapes. Felt like hiring a contractor vs building a bench. At 12 people that's $600/mo plus credits, which is the old math again.

Would love to hear what teams are paying for that actually works?

My custom GPT icons suddenly switched to the generic icon. It’s happening on desktop and iPhone, different networks, etc., so it seems tied to my account or an OpenAI glitch.

I’ve tried all the usual troubleshooting and OpenAI support is looking into it, but no fix yet so here I am.

Anyone else seeing this or figured out how to fix it?

If this is the wrong place to ask, please direct me to the correct subreddit. Thanks!

I've had this program in mind for quite a while.

Back when ChatGPT first came out, it had no way to group existing conversations into folders, and I set out to build one. My conversation list kept getting longer and finding old chats was getting hard.

Not long after - before I built it - a browser extension came out that did exactly that. I never used it. At the time I'd assumed I would want to revisit old conversations, but whenever I actually found one and tried to read it from the top, the sheer volume of slop gave me a headache.

Later, during a phase where I was deep into Unix pipelines, I wrote an LLM API client only depending on jq and curl, partly as shell scripting practice. But since the context went into a single jsonl file, I had to either invent something like a date-based filename convention myself or push that job onto the user. Both were more annoying than the web UI, so I didn't use it.

After that I read a post explaining how git works, and it struck me that git fits LLM conversations pretty well. Isn't "the commit DAG is already the right data structure for LLM conversations, where forking happens constantly" something everyone has thought at least once?

The reason I like git is that the source tree snapshot and the commit structure itself are always immutable, and destructive operations like switch/restore/reset are really just renaming a ref file that holds a commit object id. Once you understand that, no matter how hard the CLI is to make sense of, you never hesitate to run a command. You can always get it back.

LLM conversations aren't as fragile to change as a source tree, but for me an auto-generated SHA-1 hash is more comforting than an auto-generated session title ^~^

That's the feeling sib was built on. The README has actual explanations though.

The project is in its early stages and contributions are welcome. If you've worked with git plumbing commands, it'll be easy to hack on - and I think it'll be pretty fun.

It is absolutely unacceptable that Chat and Work modes aren't isolated. A chat rate limit on Pro reasoning just butchered an active Work mode task mid-run as well.

Are you serious?

Not to mention, ever since the last update, the limits are embarrassingly lower.

This is unbelievable..

A long ChatGPT transcript may contain useful reasoning, but it is a poor project handoff. The next person usually needs a compact artifact: the objective, sources, decisions, assumptions, what changed, tests run, known gaps, and the exact files or outputs to review.

The failure mode is subtle: the model finishes the task, but the human cannot tell which claims were verified, which were inferred, or what would need to be rerun if one assumption changes.

For professional workflows, what handoff format has worked best: an ADR-style decision log, a source-linked summary, generated tests, a structured checklist, diffs, or something else?

I am especially interested in workflows where another human actually has to approve or maintain the result—not just personal prompting habits.

Does anyone here know how the different models interact if at all or “see” each other? Currently for me 5.5 and 5.6.

Ie two threads same project.
Or
Two threads not linked in project.

It seems honestly the model is only aware of their own output or interaction w the user. Not the interactions w other models unless linked through memories or projects. Does that make sense? And is this true?

Anyone else having trouble locating their custom GPTs on iOS app?

I'm trying to track how much time I spend working on different projects in ChatGPT and apply a shadow hourly rate to understand the effective cost of that work.

I've tried:

• /work start and /work end commands. These depend on me remembering to invoke them.
• Passing the current time in NATO/date-time format in the prompt. This works reasonably well, but again depends on me remembering to provide it.
• Retrospectively estimating the time and logging it manually. This works, but defeats much of the point of automating it.

The core problem seems to be that ChatGPT isn't an authoritative clock and doesn't reliably know how much real-world time has passed between interactions.

Has anyone found a better lightweight solution for this? Ideally something that can track session time reasonably accurately and assign it to a project without requiring me to remember to timestamp every interaction.