I keep coming back to one design decision in NetPulse, the single-file Python tool someone open-sourced for checking VPS fleets. Not the SSH orchestration, not the eleven streaming unlocks. The part that stuck was how it refuses to lie. When it probes a model API gateway, a 401 counts as reachable because the request actually hit the gateway without a key. A 403 on the homepage it treats as anti-bot noise, not evidence of anything. Anything it can't resolve gets labeled `unknown`. The author said it plainly: they won't invent a "risk-control score" out of thin air.
That restraint is the thing worth copying. And it maps cleanly onto what you can actually host on VicroCode, as long as you're honest about what doesn't come along for the ride.
Why reachability questions are getting louder
Look at what builders around this evidence are dealing with. One person watched their weekly quota visibly drop after a reset and immediately started talking about splitting spend across other providers. A German B1 speaking-exam tool leans on a live model for the conversation and a different model for feedback. There's a whole thread arguing personal AI agents aren't a fake need, pointing at how ordinary users already lean on them. Underneath all of it is the same quiet question: can I reach this model endpoint right now, from where my thing runs, or not?
That question gets answered badly all the time. People curl a homepage, get a 403, and conclude the service is down. Or they get a 401 and panic, when a 401 is actually good news for reachability. The honest version of this check is boring and specific, which is exactly why it's useful.
What moves to VicroCode, and what doesn't
Here's the boundary first, because it matters. NetPulse's core trick is running probes over SSH on your own machines or your own VPS fleet, so your IP data never touches a third party. VicroCode doesn't give you SSH into an arbitrary fleet of boxes. You can't point a hosted probe at `root@vps-a` and `root@vps-b` and expect it to log in. The fleet-wide, run-it-on-your-own-hardware half of NetPulse stays on your laptop. Say that out loud to anyone who asks, so nobody expects remote host execution that isn't there.
What does move is the gateway-reachability probe itself. You can run Python online on the platform, which is all this probe really needs: make an outbound request to a model API endpoint, read the status code, and classify it with the same honest rules NetPulse used. 401 means the gateway answered, so call it reachable. 403 on a public page is weak signal, so don't dress it up. Timeouts, DNS failures, anything ambiguous: `unknown`. No invented confidence number. The logic is small. The discipline is the whole point.
The probe, as a hosted function
Structure it as a plain Python function that takes a gateway identifier and returns a three-state result plus the raw status code and a timestamp. Keep the classifier in one place so the rules are auditable:
def classify(status_code: int | None, context: str) -> str:
if status_code == 401:
return "reachable" # hit the gateway, just no key
if status_code == 403 and context == "homepage":
return "blocked" # likely anti-bot, treat as noise
if status_code is None:
return "unknown" # timeout / DNS / no answer
if 200 <= status_code < 500:
return "reachable"
return "unknown"That's deliberately not clever. A reviewer should be able to read it and agree or argue, which is more than you can say for a made-up score.
The ledger
Every run should land somewhere you can inspect later, because a single probe is a snapshot and the interesting part is drift over time. Write each result as a row to a SQLite table: timestamp, gateway, status code, verdict. Keeping it in SQLite means you can open the file in a SQLite editor and correct a bad row by hand when a data source turns out to be wrong, which is the same spirit as NetPulse telling people to file an issue when native-IP or AI-reachability results don't match reality. The ledger is editable on purpose. You will get something wrong, and you want to fix the record rather than regenerate a fiction.
CREATE TABLE IF NOT EXISTS probe_log (
id INTEGER PRIMARY KEY,
ts TEXT NOT NULL,
gateway TEXT NOT NULL,
status_code INTEGER,
verdict TEXT NOT NULL
);Making it a tool an agent can call
This is where it stops being a script and starts being useful to the agent crowd. Expose the probe as a hosted API endpoint with an in-platform tool call, so an agent can invoke it, read back the structured verdict, and assemble a plain-language comparison across several gateways. The agent doesn't guess reachability from vibes; it calls the tool, gets `reachable` / `blocked` / `unknown` per gateway, and writes something like "Gateway A answered, B is blocked at the edge, C didn't respond" without ever inventing a percentage. If you're doing AI agent development on the platform, this is a clean, narrow tool to hand it: one job, honest output, logged every time.
The payoff for the quota-watcher splitting spend across providers, or the B1 tool deciding which model path is actually up, is that the comparison the agent produces is grounded in status codes it can point to, not a score it dreamed up.
Where the honesty has to hold
Two cautions. First, outbound reachability from VicroCode tells you whether the platform can reach a gateway, not whether your laptop or your own VPS can. Those can differ, and the difference is exactly what NetPulse's on-your-own-hardware model preserved. Don't let the hosted probe imply more than it measured. Second, an exposed endpoint with a tool call is network-reachable by anything that finds it. If this probe sits behind a public endpoint, put access control in front of it; an open probe that writes to your ledger is an open invitation to pollute your data. I'd treat any claim about accuracy of the classifications as unverified until you've run it against gateways you can independently check.
The tool is small by design. What makes it worth building is the thing NetPulse got right first: when you don't know, you say `unknown`, and you never make up a number to fill the gap.