Hah, my first reaction once I saw these random 404 errors was "Maybe it's time to test Claude Code again with the new models" but made a short stop here at HN first, ended up reading your comment.
What other agent harnesses and models (besides local ones) are people enjoying right now that aren't based on platforms that are down currently? :)
Distributed systems are hard. For all we know, this could be the error code returned by some DNS service that is down because of load and a proxy cannot find the records, so 404 makes sense, or whatever. Systems like these don't always have a easy point in the infrastructure that can ALWAYS respond correctly no matter what.
Vibe coded or not, building and running distributed systems is hard :P I think only people who never built and/or ran them would say it isn't hard, regardless of what tools you have available. Not saying OpenAI won't find it extra hard due to their vibe coding, still hard when you're a group of knowledgeable people with/without AI.
General intelligence is a convenient myth perpetuated by the marketing departments of AI corpos to help further their pursuit of regulatory capture. Don't fall for it.
Firefox and Vivaldi browsers on Gentoo, NVIDIA GPU, both work normally with that link.
So it must be something very specific to what software you have installed, unless it is an AMD GPU problem, but neither of the 2 links (x and xcancel) has anything that seems to need special GPU features.
It certainly is not a general Linux problem. I also use XFCE as desktop, so if you use Gnome it could be some Gnome component.
But now I want to add a JSON API to the program: I could reuse the same routes (/create, etc), but require an application+json header; or add a full /api/ component essentially duplicating the logic from the main app.
Fat services, thin routes. Try moving your business logic to a library and consume it from both your UI and API routes. That minimizes duplication and decouples your public API resolvers (with backwards compatibility requirements etc) from your private UI resolvers (which you want to evolve rapidly to optimize your UIX).
That's what we did and it works pretty well in practice.
As a result for POST requests you have to have htmx routes that accept urlencode and API routes that accept JSON, and JSON is far superior. But for outputs I actually think separating your UI and API is helpful. The code reuse is not worth the entanglement of concerns.
It's a service, and I want to add a CLI for humans and agents. Aeolos' reply makes a lot of sense, I can refactor the backend into a library and add thin UI and API routes on top of it.
reply