fix(agent-interface): default the router to a model it can bill

[drewstone]

Problem

TANGLE_ROUTER_DEFAULT_MODEL was zai/glm-4.7. That model is not in the Tangle router catalog — GET https://router.tangle.tools/v1/models carries 556 models, and the zai family it serves is glm-4.5, glm-4.5-air, glm-5, glm-5-turbo, glm-5.1, glm-5.2. There is no glm-4.7 (only cerebras/zai-glm-4.7, a different provider and id).

So a managed run that named no model asked the router for a model it does not carry.

Why this hangs instead of failing

The router answers a Tangle-funded call only when it both routes the model and holds a spend-authorizing price for it. A model that fails either test answers 503. A CLI reads 503 as transient and retries until its own timeout, so the run emits neither output nor an error for many minutes.

Change

zai/glm-5.2 — same provider family, the router routes it, and the router holds an operator-reviewed price for it. The constant now documents both properties a replacement must hold.

Verification

The id was checked against the live router catalog: glm-5.2 reports routeability.routeable = true, and it is one of the hand-curated provider price definitions in tangle-router.

Local tsc and vitest could not run in this checkout: TS2688: Cannot find type definition file for 'node' reproduces on a clean tree without this change, so it is a pre-existing environment issue here rather than a result of this edit. CI is the verification path.

[tangletools]

✅ Auto-approved drewstone PR — bdb489ed

This PR was opened by the trusted drewstone account.
The full PR reviewer audit still runs separately and will publish findings if it detects issues.

This approval is provisional. It rests on the audit running. If the audit cannot run — for example the CLI bridge rejects it — this approval is dismissed rather than left standing, so an unrun check never reads as a passing one.

_{tangletools · auto-approval · reason: drewstone_author · 2026-08-17T00:45:54Z}

[drewstone]

@tangletools review now

[tangletools]

✅ Auto-approved drewstone PR — bdb489ed

This PR was opened by the trusted drewstone account.
The full PR reviewer audit still runs separately and will publish findings if it detects issues.

This approval is provisional. It rests on the audit running. If the audit cannot run — for example the CLI bridge rejects it — this approval is dismissed rather than left standing, so an unrun check never reads as a passing one.

_{tangletools · auto-approval · reason: drewstone_author · 2026-08-17T00:57:31Z}

[drewstone]

Post-merge verification against the live router

Released as @tangle-network/agent-interface@1.0.1 (via #201, merge 87de308). The published tarball carries TANGLE_ROUTER_DEFAULT_MODEL = "zai/glm-5.2" with no residual glm-4.7.

The doc comment on the constant asks for both properties to be confirmed against the live router before the id changes. I ran that check with a funded key. Result: the pricing bug is fixed, and a separate live condition still blocks the default.

Model id	HTTP	Code
zai/glm-4.7 (old default)	503	provider_pricing_unavailable
zai/glm-5.2 (new default)	503	upstream_unavailable (mints a generationId)
zai/glm-5.3	503	upstream_unavailable
zai/glm-5.1	503	upstream_unavailable
deepseek/deepseek-chat (control)	200	ok

Two readings:

1. The diagnosis in this PR is confirmed. The old default fails the spend-authorizing price gate permanently. The new default clears both gates — it reaches an upstream attempt and mints a generationId, which the old id never did. That is a real fix.
2. The user-visible symptom is not gone today. zai/glm-5.2 returned 503 on 3 of 3 attempts over ~10s, as did glm-5.1 and glm-5.3, while deepseek/deepseek-chat returned 200. The whole zai GLM family upstream looks unavailable right now, so a managed run that names no model still gets a 503 a CLI reads as transient. The cause moved from a permanent pricing gap to an upstream capacity outage; the run still hangs.

Not a reason to hold the release — this strictly improves on a default that could never be billed. But if the GLM upstream stays down, the default is still effectively unservable, and deepseek/deepseek-chat is the only id I proved answers 200. Worth a follow-up if that persists.

Catalog note for whoever changes this id next: /v1/models lists glm-5.2 and zai-glm-5-2 but not the exact string zai/glm-5.2, so catalog membership is the wrong test. zai-glm-5-2 fails with provider_pricing_unavailable. Only a funded call distinguishes a routed-and-priced id from an unservable one.