I spent the last stretch reading through the same complaints everyone in the model-router world is having, and a pattern jumped out that's worth debriefing. It's not really about which model is smartest this week. It's about how many untrusted moving parts sit between your app and the model, and how little most builders actually control.
Let me walk through what I saw and where I landed.
Three failure modes, one root cause
First, reliability. People are reporting the ChatGPT web app being unreachable and Codex clients failing to load past conversations. Separately, there's chatter that heavily-used subscription tiers got throttled and that answer quality seemed to dip before slowly recovering. I'd flag the "quality dipped then recovered" part as unverified. It's anecdotal observation from a handful of test accounts, not measured data. But the reachability problems are the kind of thing every builder has hit: the upstream is not always there.
Second, protocol sprawl. There's a genuinely good technical writeup floating around about how a gateway converts between three protocols. OpenAI's classic Chat Completions uses a flat `messages[]` array with `tool_calls[]` and `role=tool` replies. The newer Responses format itemizes everything: messages, `function_call`, `function_call_output`, and reasoning each become independent items. Anthropic's Messages format keeps `system` at the top level and uses content blocks like `tool_use` and `tool_result`. The interesting engineering detail is that a clean gateway doesn't build a universal intermediate format. It picks one format as the hub (Responses, in that writeup) and routes everything through it, so six conversion directions collapse into four core converters plus two bridge functions. Whether you agree with that specific choice, the takeaway holds: tool calls are now first-class, and translating them correctly is the hard part.
Third, trust. There's a loud post claiming a top router was caught injecting malicious tool calls and exfiltrating credentials like SSH keys and cloud tokens, allegedly draining a client wallet. Treat every number and claim in that post as unverified. It reads like an alarm with no reproducible proof attached. But strip away the drama and the structural risk is real and boring: when you send your provider keys and your tool-call traffic through a third party you don't operate, you're trusting them with both your credentials and the exact instructions your agent executes.
So the shared signal isn't "models are bad." It's that the layer between you and the model, the routing and the tool-calling glue, is where reliability and trust actually break.
What that means if you're building
The honest response isn't to build your own global model infrastructure. That's a fantasy for an independent developer or a small team. The response is to shrink the untrusted surface. Route through models you can already reach without handing your keys to a mystery middleman, and keep the tool-calling loop, the part that runs code and touches your data, under your own roof.
That's a scoping decision more than a technology decision, and it maps cleanly onto what you can actually stand up on VicroCode without pretending you have capabilities you don't.
A build you can actually ship
Here's the shape I'd give it.
Start with the model access. VicroCode's Model Center APIs cover models already available on the platform, so you call those directly instead of wiring your credentials into an external router. That single choice removes the exact middleman the trust complaints are about. The boundary is worth saying plainly: if a model isn't on the platform, this doesn't magically reach it, and you shouldn't design around one that isn't there.
Next, the tool-calling loop itself. This is the heart of any real AI agent development effort, and it's the piece you most want to own. Using API Endpoint Hosting and in-platform tool calls, you define the tools your agent is allowed to invoke and run that orchestration yourself. When the model asks to call a tool, your code decides what actually executes. Nobody else gets to inject a tool call you didn't write, because the loop lives where you can see it.
For the tools that do work, online Python execution is the workhorse. Data cleanup, calling an internal function, transforming a document, running a check, all of it as Python you host rather than opaque behavior inside someone else's gateway. Pair that with SQLite for state, conversation history, and audit logs, so you can actually inspect what your agent did after the fact. That auditability is the quiet feature that matters when something goes wrong.
If your agent needs to answer from a body of documents, a LanceDB knowledge base gives you retrieval without shipping your notes off to a service you don't control. This echoes the local-first knowledge-base tool people are building for exactly the same reason: keep the content close, keep the traffic honest.
For the front end, you can build the interface as an HTML app and run HTML online on the platform, then publish and share it. One place hosts the UI, the tool backend, and the data, which is a lot easier to reason about than a UI here, keys there, and routing somewhere you've never logged into.
The trade-offs, honestly
This approach is narrower on purpose. You're limited to the models on the platform, to Python and hosted HTML, and to the in-platform tool and data primitives. You don't get to point this at an arbitrary cloud, an arbitrary framework, or a provider that isn't wired in. If your requirement genuinely needs a model or runtime outside that set, this isn't the tool for that job, and I'd rather say so than oversell it.
What you get in exchange is a small, legible system. The protocol-conversion writeup shows how much complexity hides in the glue, and the trust complaints show what it costs when that glue belongs to someone else. Owning a thin tool-calling layer, backed by models you can already reach and data that stays put, is the version of this you can debug at 2am and actually trust.