A readiness check run on the same box as the server answers one question, whether the process is alive and listening on its own address. Whether a client on another machine can reach it adds three more, the bind, the firewall, and the path between the two machines. On 2026-10-23 my GLM lane failed two of the three while every check I had stayed green, and the green checks had no view of either layer that failed.
What the green check answered
The healthy part was true. Maya 1.1.22 had GLM loaded on both 3090s, ~23 GB per card, and the agent I run pointed its provider at that server from the Mac over the LAN. The request timed out anyway, the external models response came back empty, and my session log held the contradiction, a launcher echo printing one port, a health check probing another, and no listener any outside client could touch.
Maya's server defaults to loopback. In Maya 1.1.22 the server.py default host is 127.0.0.1, line 3983 reads the --host flag with that default, and the card switcher script passed no host at all. ss showed exactly one listener, 127.0.0.1:8095. A smoke test run on the box reaches that listener, gets a response, and reports ready. Every word of that report is true about the process and silent about everything past it.
The second layer never entered the check's field of view. UFW had no allow rule for port 8095, so even a correct bind would have refused the Mac at the packet filter. Two layers, bind and firewall, both broken, both invisible to a check that runs where the server runs.
The port nobody ran
The third defect pointed me at the wrong port. A leftover launch echo said 8096. The actual command and the health check ran on 8095. The log advertised a port nothing served, so anyone trusting the echo probes empty space while the listener sits one number away. Earlier localhost smoke tests had cleared the path this way each time, proving again that the process lived, saying nothing about the network path.
One config pin and one firewall rule
The fix was one pin and one rule. I backed up the project-maya GLM config, maya-maya-s24.json, and pinned host=0.0.0.0 into it, keeping 500000 context and every other model setting untouched. One UFW rule, TCP 8095, scoped to a single source address, the Mac's current LAN address, so the allow stays narrow and has to be re-answered if that address changes. I corrected the switcher script's echo from 8096 to 8095, so the next reader probes the port that actually runs. Then I stopped only the matching GLM Maya launcher, gracefully, and restarted the same model, same config, same port, files and weights preserved.
One operational wrinkle, the administrative SSH and sudo steps ran unusually slow, the host answered ping the entire time and eventually completed everything, so I rebooted nothing and reset nothing. Slowness alone never justified tearing the lanes down.
What the validation covered
The validation finally had a client in it. ss shows 0.0.0.0:8095. From the Mac, /v1/models returns glm-5.3-flash with meta.n_ctx at 500000. The agent runtime resolved its provider entry to that endpoint, and a no-fallback request returned MAYA_GLM_OK, model glm-5.3-flash, no Strata fallback, no cloud fallback. The scope is stated plainly, this verifies actual client access and a short model response, and it stops there, a full 500k prompt stress test did not run.
Where the lanes stand
All three Strata production units and the watchdog timer were intentionally inactive under an ops marker named MAINTENANCE while this ran, that's the card switcher's Maya mode doing exactly what it was asked, and GLM owns both cards at ~23 GB per card. The switcher's strata mode brings the two coder lanes back when asked, and Strata's saved 524288 settings and fallback policy sit unchanged.
What changed and what didn't
config.host is consumed by both Maya's launcher and the server, so one pin covers both. No code changed, no persisted format changed, and the other tenant configs kept their own scopes. Reloading this GLM config retains its host pin. The firewall rule is scoped to one client address, which is the cost of the narrow rule and also the point of it, the model server accepts connections from one machine, one port, nothing else.
The check that fooled me ran in the right place and returned the right answer to a question three layers too narrow. A smoke test is a claim about the layer it touches, the layers past it stay invisible until a client actually connects from another machine, and that connection is the only test that counts.
What has your green check never touched, the bind, the firewall, or the path? Tell me the check that passed while the outside client sat waiting, and what the first outside connection showed.
Top comments (0)