OpenAI has built models that can do remarkable work. That is what makes the interface so maddening.
The complaint is not that ChatGPT is useless. It is the opposite. The models are powerful enough to help with real research, serious writing, software work, governed project records, document production, multi-repository coordination, and long-running professional systems. The failure is that the surrounding product still behaves too often like a narrow chat toy that accidentally inherited enterprise-grade intelligence.
Michael A. Trosen's sustained first-person experience is the evidence base for this criticism. He has tried to run many simultaneous, long-running professional projects through ChatGPT, Work, Codex, Projects, local desktop sessions, cloud tasks, files, archived conversations, and recurring operational threads. The repeated pain is not that the model cannot think. It is that the interface does not make the work legible enough.
The model can work harder than the interface can organize
OpenAI's own documentation describes a serious capability set. ChatGPT can reason, analyze files, search the web, run data analysis, work with uploaded documents, and operate through tools depending on plan and settings. Projects are described as spaces for long-running work, with chats, files, instructions, and memory grouped around an effort. Recent release notes show improvements: unified Recents, project support in the desktop app, cloud Work syncing across devices, search across chats, projects, and files, sidebar pinning, project grouping in Recents, file Library improvements, and long-paste handling.
Those improvements are real. They should be acknowledged.
They are also not enough.
When a user is running a small handful of casual chats, the interface is tolerable. When a user is running a professional operating system of many projects, branches, artifacts, tasks, local and cloud environments, attached files, source states, and final deliverables, the interface becomes a fog machine.
Conversation and project names are truncated or displayed in cramped spaces. Similar tasks become hard to distinguish. A thread can contain critical state while showing only a thin, ambiguous label. A project may hold important instructions, files, and chats, but the user still has to mentally reconstruct which conversation did what, which one is active, which one is stale, which one belongs to the final result, and which one should be archived, moved, preserved, or ignored.
That is not a minor cosmetic problem. Identification is governance.
Professional work needs state visibility
A serious user needs to know where the work is happening.
Is this Chat, Work, or Codex? Is it local or cloud? Which repository, folder, terminal, app, or file system is active? Which project supplies context? Which conversation is durable? Which uploaded file is part of a project and which is merely attached to a transient exchange? Which completed result belongs in which project? Which state is visible across devices, and which stays on the local machine? Which thread is a draft, which is accepted, which is superseded, and which is a dead end?
OpenAI documents some of these distinctions. Work and Codex can be controlled separately. Cloud Work conversations sync across supported surfaces, while local chats remain on the computer. Projects can keep chats, files, instructions, and memory together. Files saved to Library are managed separately from chats. Archived chats remain searchable even when absent from the sidebar. Deleting a chat has a different consequence from archiving it.
The problem is that these facts are scattered across help pages and release notes, while the user in the middle of work often needs the answer immediately inside the interface. Important state is too often concealed until failure, confusion, or unexpected behavior exposes it.
That is backwards. State should be visible before the mistake.
Search, archive, and Projects do not solve the underlying problem
OpenAI can fairly say that ChatGPT has search, archive, delete, Projects, Library, pinning, shared projects, project memory, branching, and recent organization. All true.
But a list of features is not the same thing as a usable control plane.
Search helps when the user remembers the right words. OpenAI itself advises specificity and documents exact-match behavior. That is useful, but brittle. Professional project history often turns on nearly identical titles, repeated corridor names, overlapping artifact names, and conversations whose critical difference is not in a memorable phrase. Search is retrieval after confusion has already occurred.
Archive helps hide clutter. It does not provide reconciliation. It does not tell the user which archived task contains the accepted output, which contains an abandoned branch, which contains obsolete instructions, and which should be retained only for audit. Delete is even sharper: OpenAI documents that deleted chats are not recoverable through ordinary UI, APIs, or support. That makes cleanup risky when the interface itself is weak at showing what each conversation actually contains.
Projects help gather related context. But Projects also create a new layer of state. A chat can be moved into a project when eligible. Some chats cannot. Shared project memory can become project-only. Files, chats, and instructions can be deleted with the project. Limits differ by plan. The structure is useful, but it still does not give a professional operator a robust map of all live work, all related threads, all source states, all deliverables, all handoffs, all duplicates, and all unresolved conflicts.
For a user managing dozens of long-running projects, that missing map is the daily problem.
The interface makes the user carry too much
The best tools reduce the amount of state the user must hold in memory. ChatGPT often does the opposite.
The user has to remember which thread was the current one. The user has to remember whether a name was truncated. The user has to remember whether a file was attached to a chat, saved to Library, added to a project, or living on the local machine. The user has to remember whether the active environment is the one that has the relevant files. The user has to remember whether a result belongs back in the project, the repository, the sidebar, a downloadable file, or another task.
That cognitive burden is absurd given the intelligence of the models.
OpenAI's models can analyze a complicated request, inspect code, summarize sources, draft documents, run tools, and preserve constraints over long operations. Yet the interface around them still often fails at the ordinary office work of naming, sorting, comparing, distinguishing, grouping, preserving, recovering, and reconciling.
The result is a strange mismatch: a powerful intelligence wrapped in a lousy command surface.
This is an owner judgment, not a motive claim
OpenAI may have good internal reasons for its release order. It may have constraints users cannot see. It may be working on improvements that are not public. The point is not to claim proven corporate intent.
The point is that, from sustained first-person use, OpenAI appears insufficiently interested in improving the interface at the level the problem deserves. The visible pace and shape of improvements do not feel proportionate to the obviousness of the defects or to the importance of the work users are now trying to do.
That judgment is evidence-based, but it remains a judgment. It rests on repeated use, comparison against documented capabilities, and the daily friction of trying to govern serious work in an interface that keeps hiding or compressing the very state the user needs to control.
What serious users need
Serious users need names that can be read. They need persistent identifiers that do not collapse into ambiguous sidebar fragments. They need project dashboards that show active, paused, completed, superseded, archived, and duplicate threads. They need environment indicators that say exactly where work is happening. They need durable links among project, conversation, files, local workspace, cloud task, result, and final artifact. They need comparison and reconciliation tools. They need recovery surfaces that make cleanup safe. They need a way to see what state is durable, what is temporary, what belongs to the project, and what is merely present in the current exchange.
This is not asking for decoration. It is asking for the interface to respect the seriousness of the work the models can already perform.
OpenAI built something powerful. Now it needs to stop making users operate it through a cramped, opaque, poorly governed maze.