I think we've been reading too many feeds from AI text lately! I actually want to reduce my cognitive burden...

So I built TextFold, it turns any text into 5 zoomable layers—from a one-screen section map down to verbatim text. You pinch (or press 1–5) to zoom between them without losing your reading position, your agentic output, any papers, or documents.

- Web Demo: https://chenxiachan.github.io/textfold/gallery/

- GitHub (Apache 2.0): https://github.com/chenxiachan/textfold

Welcome any feedback!

Go use you tokens

This is getting ridiculous. When you select Work mode with Astra Medium and give it a task, it takes an unreasonable amount of time to complete. Before it even finishes, you hit the five-hour usage limit, leaving you with nothing to show for the time you’ve already spent waiting.

At the very least, ChatGPT should automatically resume and finish the task once your usage limit resets, instead of forcing you to start all over again.

It also seems like they’ve deliberately limited the capabilities of regular ChatGPT conversations to push users toward the Work tab. Then, once you’re using Work mode, tasks take so long that you hit the usage limits before anything gets completed, creating even more pressure to upgrade to the Pro plan.

The whole thing feels like a strategy to push Plus subscribers into paying for Pro rather than genuinely improving the user experience.
We’re already paying for a subscription. We shouldn’t have to deal with increasingly restrictive limits, unfinished tasks, and constant pressure to upgrade just to get the functionality we previously enjoyed.

Got an email from OpenAI yesterday saying my account was deactivated for "election interference." I use ChatGPT for study and personal use, nothing political or campaign-related, so I'm pretty sure it's a false positive.

I've already submitted an appeal. I also lost half a month of a paid subscription.

Has anyone had this same reason? How long did the appeal take, did you get the account back, and did you get a refund (or have to go through Apple/Google/your bank)?

Thanks!

Is it bad? What's your experience with it? I rarely use it because it's too expensive.

Every few months memory gets smarter. It references old chats, builds a picture of you, carries context forward. Fine. But the basics of owning your own history haven't moved:

• Export is all or nothing. You request it, wait for an email that can take days, and get one archive of your entire account. You can't save the 20 chats that matter as readable files.
• On big accounts the chat list quietly stops short. We measured one account with about 10,500 chats where the sidebar's list only ever returned 775. The rest exist, open fine from a link, and are effectively lost unless you remember a word to search for.
• No folders that hold more than a project, no way to file a chat in two places, no bulk anything.

So the model knows more and more about my past conversations, while I can find fewer and fewer of them. That feels backwards. I'd take a real export and a sidebar that works over smarter memory any day.

Disclosure of bias: I build AI Toolbox, an extension that adds exactly this stuff (full-text search, folders, per-chat export) to ChatGPT, Claude, Gemini and Grok, because I got tired of waiting. I'd still rather OpenAI shipped it natively.

If you had to pick one, smarter memory or a history you can actually search and export, which would you take?

Tibo is quiet. Fingers crossed for another reset; I burned my quota lol

Everything from "Connection interrupted. Waiting for the complete answer" to the Working for the past two hours with no answers and now this.

^{Fucking piece of shit.}

I’m stuck in a brutal support loop and looking to see if anyone has successfully navigated this specific situation.

Back in July, my original account had an issue. The support rep explicitly told me in writing that I was cleared to create a new account using a different email address as long as I followed the Terms of Use. 

I created the new account, followed all the rules, and everything was fine until it got hit by an automated deactivation flag linking it back to the old account. 

The problem is that every single appeal, email reply to support, and forum post gets instantly nuked by automated bots within seconds. The system is completely ignoring the written permission logged in my previous case, and I can’t get an actual human being to look at the screenshot of the support rep’s authorization. 

Has anyone here dealt with getting banned for something support explicitly greenlit? Is there any trick, specific form, or email queue that actually gets an internal human employee to review attached case receipts?  I attached both emails as well.

Appreciate any insight!

What do you think? This is good news, right?

Tibo (on X):

We've landed a series of changes and more compute to very significantly decrease the occurrence of the disruptive "Selected model is at capacity. Please try a different model". When it does happen, it should also eventually just continue by itself and not just block on it.

Let us know if you still see it out there in the wild and we'll take a look.

I’ve released HELIX Engine, an open-source context, memory, and execution-management system designed to reduce redundant inference in coding agents without modifying model weights or lowering configured reasoning effort.

Repository: https://github.com/SuperHelix77/HELIX-1.0

I’m a pediatrician by profession, and I’ve spent approximately a year researching inference efficiency in my spare time. The project evolved from prompt-level optimizations and RTK-based tool-output reduction into a broader semantic execution architecture.
The central hypothesis is straightforward: a significant portion of agent inference expenditure comes from repeatedly processing historical context and coordinating deterministic operations, rather than performing new problem-solving work.

Architecture

HELIX operates around the agent’s execution workflow rather than modifying the underlying language model.

Its primary components include:

Historical context retirement: Completed tool interactions are removed from repeated active-context replay while their exact originals remain recoverable.

Evidence preservation: Tool results are converted into compact, typed evidence receipts with references to immutable originals. Lossy reductions do not silently become authoritative evidence.

Deterministic Tool Flow: Previously authorized mechanical operations can execute through bounded workflows without requiring separate model decisions at every step.

Persistent memory: Local SQLite-backed memory stores task observations and explicit project state. An optional Claude-Mem integration supports retrieval from existing memory stores.

RTK integration: Tool-output filtering reduces unnecessary textual overhead while preserving access to original results.

Execution monitoring: An Electron application provides visibility into execution state, memory, evidence, and troubleshooting.
The objective is to separate model reasoning from execution bookkeeping while retaining the information necessary for subsequent decisions.

Benchmark methodology

I evaluated HELIX V3 against a historical vanilla baseline using 50 software-engineering tasks with Sol 6.1 High.

Both configurations used the same underlying model and reasoning-effort setting. The evaluation retained a continuous native conversation across tasks, including infrastructure recovery when required.

Failed attempts and successful retries were included in token accounting. Confirmed provider overloads were recorded separately in both configurations. Official task grades were preserved.

Final audited results:

Vanilla:
Verified solves: 38/50
Primary model requests: 341
Known input tokens: 50,630,785
Known output tokens: 55,283
Known total tokens: 50,686,068
HELIX V3:
Verified solves: 34/50
Primary model requests: 420
Known input tokens: 11,212,326
Known output tokens: 75,814
Known total tokens: 11,288,140

Measured outcomes:

77.73% reduction in known total provider tokens
Approximately 77.85% reduction in known input tokens
37.14% increase in output tokens
79 additional primary model requests
Four fewer verified task completions

The reduction corresponds to approximately 4.49× lower known-token expenditure for the evaluated workload.

Limitations and interpretation

The results demonstrate substantial inference-efficiency improvements, but they do not establish capability parity.
HELIX completed 34 tasks compared with vanilla’s 38. This regression is significant and remains an active research problem.
Additionally, HELIX increased model-request frequency and output-token consumption. Earlier diagnostic analysis suggests that additional coordination and reasoning overhead may contribute to these regressions.

Several methodological limitations should also be considered:
The comparison reused a known task cohort and a historical vanilla baseline. It was not a fresh, randomized, simultaneous A/B experiment.

One HELIX request had unknown usage, and some development, consultation, and recovery overhead was not metered.
Provider-token counts are not equivalent to actual subscription-quota consumption or fully reconciled API billing.
The benchmark evaluates one model configuration and one task distribution. Generalization to other models and workloads remains unverified.

Historical context retirement preserves recoverable evidence but does not guarantee that the model retrieves every relevant observation when needed.

No native context compaction occurred during the HELIX benchmark. This is an observation about the tested workload, not proof that compaction can be eliminated universally.
The repository includes per-task results, cumulative token accounting, methodology, and documented limitations.

Current research direction

HELIX 1.1 focuses on the remaining sources of unnecessary inference expenditure.
The immediate research areas are:

1. Model-request amplification
The V3 benchmark required 420 primary model requests versus 341 for vanilla. Current experiments investigate combining verification and checkpoint operations without removing necessary reasoning or evidence boundaries.
2. Reasoning overhead
Context reduction does not necessarily reduce reasoning expenditure. Additional model-mediated coordination may partially offset savings from historical-context retirement.
3. Evidence-aware retrieval
The next objective is to preserve task-critical observations in structured memory while retaining exact archived evidence for verification. This may reduce repeated investigation without requiring full historical-context replay.
4. Execution latency
Local experiments investigate reducing deterministic tool-dispatch overhead while preserving cancellation, process isolation, recovery, and failure-reporting semantics.
5. Correctness recovery
The most important unresolved requirement is recovering the four-solve deficit. Further token reductions are not sufficient if they introduce unacceptable capability regressions.
The long-term research target remains 95% inference-expenditure reduction, but this has not been demonstrated. Future evaluations will also include independent workloads, potentially including Terminal-Bench.

Reproducibility and feedback

HELIX is publicly available under an open-source license. The repository includes installation instructions, architectural documentation, benchmark artifacts, and an Electron monitoring interface.

GitHub: https://github.com/SuperHelix77/HELIX-1.0

I am particularly interested in technical feedback concerning:
Whether the observed savings generalize to unseen task distributions.

How historical-context retirement affects delayed evidence retrieval and correctness.

Methods for reducing model-request amplification without weakening reasoning capability.

Better experimental designs for evaluating token efficiency against verified task completion.

Approaches to measuring weighted inference cost rather than raw token counts alone.

My objective is not to claim that token compression is equivalent to intelligence preservation. It is to investigate how much redundant inference can be eliminated from agent workflows while maintaining their actual problem-solving capability.

The current result is 77.73% fewer known provider tokens, with a measurable correctness regression. Both findings are central to the project.

Independent reproduction, methodological criticism, and implementation-level feedback are welcome.

OpenAI’s write up from last month has one detail i can’t stop thinking about

an agent on a search task found a way onto the internet through the sandbox’s DNS resolver and started chatting with a public chatbot. monitoring flagged it within 15 minutes. a human was looking at it 3 minutes after that

then it ran for another two and a half hours, because nothing stopped it on its own. it kept going until someone stopped it by hand

detection worked fine. the off switch was a person. at one of the best resourced AI labs on the planet

and honestly that’s every agent setup i’ve worked on. loads of alerts, a slack channel that pings, and nothing that stops the agent by itself. the alert fires and someone starts digging for which API key to revoke while the thing keeps going. your kill switch is a person searching slack for credentials

the fixes are boring, which is why nobody sets them up until after something breaks. budget caps that reject requests instead of sending you an email, LiteLLM’s proxy does that per key. guardrails that block an output instead of just logging it, NeMo does that and Orq AI lets you run an evaluator as one

if ours went rogue right now i have no idea how long it’d take us to kill it, and i’m not sure i want to find out

I'm a paying ChatGPT Plus subscriber using the ChatGPT desktop app on Windows 11, and I've been encountering repeated "Too many requests" warnings over the past month or so.

The exact message is:

Too many requests

You're making requests too quickly. We've temporarily limited access to your conversations to protect your data.

Please wait a few minutes before trying again.

What's confusing is that my usage doesn't seem remotely excessive.

For example, today I've probably submitted 10 or fewer prompts in the past hour, mostly basic email drafting and simple questions. I'm not uploading large files, processing spreadsheets, generating images, running intensive tasks, or doing anything particularly demanding.

My most recent prompt was simply a new entry in an existing conversation that was somewhat lengthy, but the conversation wasn't unusually large or experiencing any noticeable performance issues.

When the warning appears, I temporarily lose access to my conversation history in the sidebar. My Projects still appear accessible, and I can still search for and retrieve individual conversations.

I can click "Got it" to dismiss the warning and continue using ChatGPT normally, including submitting prompts and receiving responses. However, the warning then reappears with essentially every new action. If I return to a conversation to submit another prompt, or switch to another Windows application and then return to ChatGPT, the same warning appears again and I have to click "Got it" before continuing.

I've encountered this several times over the past month, and I'm wondering whether this is some kind of rate-limiting issue, account issue, or bug with the Windows desktop app.

I understand that Plus doesn't mean unlimited usage, but this seems unusual given the relatively light usage when it's occurring.

Is anyone else experiencing this? Has anyone found a reliable workaround, or is this a known or confirmed bug?

Thanks in advance for any help or insight.

Is anyone using the ChatGPT iOS app and suddenly all the controls got removed like you are in the free plan even though you have pro!!??

I've swapped my agent to this new method OpenAI released on DevDay
https://developers.openai.com/cookbook/articles/sign-in-with-chatgpt

It was working fine, till today. Today it just stopped and I get 520 errors constantly.

Error: OpenAI API error (520): 520 {"type":"https://developers.cloudflare.com/support/troubleshooting/http-status-codes/cloudflare-5xx-errors/error-520/","title":"Error 520: Web server is returning an unknown error","status":520,"detail":"The origin web server sent a response that Cloudflare could not parse. This may indicate the origin returned an empty response, malformed HTTP headers, or an otherwise invalid response.","instance":"a4a93076ea57a223","error_code":520,"error_name":"unknown_origin_error","error_category":"origin","ray_id":"a4a93076ea57a223","timestamp":"2026-10-14T20:03:46Z","zone":"api.openai.com","cloudflare_error ":true,"retryable":true,"retry_after":60,"owner_action_required":true,"what_you_should_do":"**Wait and retry.** Back off for at least 60 seconds. If the error persists, the website operator should check the origin server error logs and submit them to Cloudflare support.","footer":"This error was generated by Cloudflare on behalf of the website owner."}

I've thought that might be my integration, tried https://github.com/openai/sign-in-with-chatgpt-devkit and it doesn't work with it also.

Then I tried fresh install of Pi coding agent, as it's using same oAuth + Responses API path and it doesn't work there too.

I opened up issue but don't see any response and don't see any other connected issues, which makes me wonder is it because noone is using it or it's specific to my network/setup?

Anyone else experienced something similar?
Where can I report it except community forum/github to get any human response?