ableton-mcp-ai/docs/ANTHROPIC_COMPAT_PROVIDER_CHECK_2026-03-30.md

Anthropic-Compatible Provider Check 2026-03-30

Fecha de prueba: 2026-03-30

Se probaron endpoints reales con payload POST /v1/messages y prompt minimo: Respond with exactly OK and nothing else.

Resultado

Provider	Endpoint	Modelo	HTTP	Latencia aprox	Obediencia exacta
Z.ai	https://api.z.ai/api/anthropic/v1/messages	glm-5.1	200	~2899 ms	SI
DashScope	https://coding-intl.dashscope.aliyuncs.com/apps/anthropic/v1/messages	glm-5	200	~5002 ms	SI
DashScope	https://coding-intl.dashscope.aliyuncs.com/apps/anthropic/v1/messages	qwen3.5-plus	200	~6108 ms	SI
DashScope	https://coding-intl.dashscope.aliyuncs.com/apps/anthropic/v1/messages	MiniMax-M2.5	200	~5582 ms	SI
Fireworks	https://api.fireworks.ai/inference/v1/messages	accounts/fireworks/routers/kimi-k2p5-turbo	200	~1398 ms	NO

Lectura practica

• Z.ai / glm-5.1 fue el mejor equilibrio entre latencia y obediencia.
• DashScope funciona en modo Anthropic-compatible con los tres modelos probados.
• Fireworks / kimi-k2p5-turbo respondio rapido, pero no obedecio una instruccion minima simple. En vez de devolver solo OK, devolvio razonamiento extra.

Recomendacion actual para el proyecto

1. Usar Z.ai / glm-5.1 como provider principal para jueces.
2. Mantener DashScope / glm-5 como fallback serio si Z.ai empieza a devolver 429.
3. No usar Fireworks / kimi-k2p5-turbo como arbitro principal de palettes mientras siga mostrando peor obediencia al contrato de salida.

Implicacion para Kimi

Si vas a tocar zai_judges.py, primero asume este orden:

1. glm-5.1 @ Z.ai
2. glm-5 @ DashScope
3. qwen3.5-plus @ DashScope

No cambies el provider principal solo por latencia. Para este proyecto importa mas la obediencia del JSON y la disciplina del arbitro que ahorrar 1-3 segundos por llamado.