If you read enough developer forums right now, the same picture keeps surfacing: nobody is using a single model anymore. One person has Claude writing code and ChatGPT reviewing it, passing notes through a shared workspace doc. Someone else built an open "agent room" so a model on one machine can boss around models on another. A third built a multi-model gateway just so they could switch between DeepSeek, GLM, Kimi, Claude, and GPT without juggling a drawer full of API keys.
Strip away the specifics and it's one signal: the interesting work has moved from *calling a model* to *coordinating several of them*. And the coordination is where everything gets ugly.
The friction is in the glue, not the models
The most honest post in the batch was from someone whose setup was working, technically. Claude wrote, ChatGPT reviewed, and the two talked through a workspace document. The complaint wasn't that it failed. It was that the reviewer kept dragging in defensive-programming suggestions nobody asked for, turning a clean review into an endless "maybe you should also handle this" spiral. One reply nailed the fix: tell the reviewer to flag only clear violations, skip the "optimization suggestions," and it quiets down. Another warned that stacking several AIs around one table mostly produces a committee meeting where nothing gets decided.
That's the real lesson. The models are capable. What's missing is a thin layer that enforces *roles* — who drafts, who critiques, what counts as a finding worth surfacing — and keeps a record you can actually read later. People are building this by hand, inside chat windows, copy-pasting between tabs. The agent-room author basically admitted the motivation was being sick of manually relaying messages between Claude and GPT.
There's a second, quieter friction worth naming: moving data between tools. One builder described fighting a 25MB-per-file upload cap, retrying 50MB files in chunks that kept dropping mid-transfer, then handing over a download link the assistant couldn't actually reach. When your workflow depends on shuttling files and context between separate services, every handoff is a place to break.
What you can actually build for this
Here's the useful reframe: a model review loop is not an AI problem. It's a small application problem. You need somewhere to run orchestration logic, somewhere to store the conversation, somewhere to show it, and a way to call models through one consistent interface. That maps cleanly onto a short list of pieces you can assemble and host in one place.
The orchestration itself is a Python job. You write the control flow — draft, hand to reviewer with a tightly scoped instruction, collect only structured findings, decide whether to loop again — and you can run Python online without standing up your own server. That's where you encode the "only flag clear violations" rule the forum thread was begging for, rather than hoping a prompt holds.
Model calls go through Model Center APIs, with one important boundary: that covers models already available through the platform, not an arbitrary bring-your-own gateway speaking every vendor's format. So if your current setup leans on a specific external provider or on the OpenAI/Anthropic format-compatibility tricks that gateway builders describe, check which models are actually on the platform before you design around a particular one. That's a real constraint, not a footnote — design to what's available rather than assuming a swap is free.
The transcript of the loop — every draft, every finding, every accept/reject decision with its stated reason — belongs in a SQLite database. This is the part people skip and regret. The forum workflow used a workspace doc precisely because they wanted a durable record of *why* the reviewer's note was rejected. A small table (run id, role, message, verdict, rationale) gives you that, plus the ability to go back and see where a bad decision crept in.
For the interface, a plain HTML app is enough: a column for the draft, a column for the review, a visible decision log. You can run HTML online and host it alongside the Python backend, so the UI and the orchestration live together instead of being stitched across services. If you want other tools or scripts to trigger a run, expose it through API Endpoint Hosting and in-platform tool calls rather than wiring up a separate webhook layer.
One more thing the file-transfer complaint should teach you: keep the artifacts inside the system. If the draft, the review notes, and any attachments live in the platform's own file management, you avoid the "upload to a third place, hand over a link, model can't reach it" trap entirely. Fewer handoffs, fewer silent failures.
A build order that stays honest
If I were doing this fresh, I'd go narrow first:
- Start with a single pass, not a loop. Draft once, review once, write both to SQLite. Prove the record is useful before you add iteration.
- Scope the reviewer hard. Give it a fixed list of what counts as a finding. Reject-with-reason is a required field, not optional.
- Add the web view second. Reading the log in a table is what tells you whether the loop converges or just churns.
- Only then consider multiple reviewers. The committee warning is real — more models rarely means better decisions, it usually means noisier ones.
Two caveats I won't paper over. First, any real quality claim about these loops is unverified — the forum posts are anecdotes from people mid-build, not measured outcomes, and your own results will depend entirely on the models you can reach and how tightly you scope the roles. Second, this pattern earns its keep on *small, well-defined* review passes. The moment you're tempted to throw five agents into one room and let them sort it out, you've rebuilt the committee everyone complained about.
The demand is obvious and it's showing up everywhere at once: people want to run more than one model against a problem, keep the exchange disciplined, and hold onto the record. The hand-rolled versions work but leak at every seam. Putting the Python, the storage, the UI, and the model calls in one hosted place is less about clever AI and more about closing those seams.