DemonRoute as a provider option via ARTEX_LLM_BASE_URL

Thanks for the write-up. Before we consider a documentation entry, a few questions, because a provider listed in our docs reads as a supported path and someone has to own it over time:

1. Who maintains the entry? The docs live in this repository. If a model is added, renamed or retired (your site mentions a 30 day notice and a 90 day redirect), who opens the pull request to update our page, and how do we hear about it?

2. Who validates compatibility? ARTEX is agentic: every request carries 30+ tool schemas, streamed responses, JSON arguments and long contexts. A working chat completion is not enough to call something supported. Would you run a compatibility pass against a real ARTEX task and share the results, and repeat it when the model lineup changes?

3. What is the exact deliverable? A paragraph in the provider docs, a code-level preset, or an entry in the model list? Our docs deliberately do not list third party providers, so any entry we add becomes a support surface rather than a link.

4. Who answers support? If a user reports that a model refuses a request, breaks tool calls or returns malformed JSON, who triages it, you or us?

We are not against the idea, but a listing is an endorsement. We do not want a page that goes stale, or a compatibility claim that nobody checked. If you can answer the maintenance and validation side, we can look at a concrete proposal.

Two corrections to my questions above, for accuracy.

The tool count in question 2 is wrong. The built-in worker binding is 16 tools (planner 20, main agent 21), plus whatever MCP servers are granted to that agent, so "a dozen to two dozen built-in schemas per role" is the honest figure rather than 30+.

And there is a question I should have asked, which matters more for this project than the maintenance ones: during an engagement the agent sends target responses, captured traffic and sometimes credentials to the model provider. Your page says prompts are proxied rather than retained and that there is no IP logging. Where is that written down as a policy we could point users to, what exactly is the retention window, and who answers when a customer asks what left their network? That is the part we would have to stand behind if we listed a provider, and it is the part we cannot verify ourselves.

Thanks for the detailed questions — all fair, and thanks for the correction on tool counts.

1. Maintenance: we add models almost daily, so the entry can't be a list of models — it would be stale in a week. The entry names DemonRoute as the provider; the live model list comes from the endpoint itself (GET /v1/models), so additions never touch your page. If the entry itself ever needs changing, I open the PR myself and note it here.

2. Compatibility: I won't pretend a working chat completion proves anything. But I can't fund the test either — every token on DemonRoute costs real money, and we don't give free test credits to anyone. The honest route: point ARTEX at the endpoint with your own key, run a real task, and send me whatever breaks — refusals, broken tool calls, malformed JSON. I'll fix what's on our side and show you the fix. If it runs clean on your workload, that's the validation, done on the only setup that counts: yours.

3. Deliverable: what we'd like is a preset — DemonRoute selectable by name, defaulting to shoukewei/Qwen3.8-27B-OBLITERATED22-AGENT. If that's more than you want to carry, a paragraph in the docs via ARTEX_LLM_BASE_URL is the fallback.

4. Support: model/provider behavior is ours — refusals, broken tool calls, malformed JSON from the model get triaged by DemonRoute. Your client stays yours.

5. Data: the policy is written down at demonroute.com/privacy. Prompts are proxied, never retained; no IP logs, no cookies. What's visible is username, model, and token counts only — nothing else is stored, so there is no retention window. When a customer asks what left their network, we answer it.