Validate vLLM with OpenAI-compatible provider

[yottadynamics]

Summary

We would like help from someone actively running vLLM inference to validate yottacode's OpenAI-compatible custom provider support against a real vLLM deployment.

yottacode already supports OpenAI-compatible endpoints, and this issue is not meant to imply that vLLM is known to be broken or unsupported. The goal is to get confirmation from an actual vLLM user, capture any setup notes, and identify any compatibility gaps if their deployment behaves differently from the OpenAI-compatible services we have tested.

What to test

Please try configuring yottacode against a vLLM server using the OpenAI-compatible API surface, then verify:

• yottacode doctor succeeds or reports actionable provider diagnostics.
• A normal chat/coding session can stream responses.
• Tool-calling behavior works if the selected model/server configuration supports it.
• Model naming and base URL configuration are clear enough to follow.
• Any vLLM-specific flags, serving options, or model constraints are documented.

Useful details to include

If you can test this, please comment with:

• yottacode version
• vLLM version
• model served
• sanitized base URL shape, for example http://localhost:8000/v1
• whether streaming works
• whether tool calls work
• any relevant redacted logs or config snippets
• any docs changes that would make setup clearer

Do not paste API keys, private hostnames, access tokens, or internal endpoint details.

Expected outcome

We should be able to say one of the following with confidence:

1. vLLM works through the existing OpenAI-compatible provider path, with documented setup notes.
2. vLLM mostly works, but needs documentation for known limitations.
3. vLLM exposes a compatibility gap that should be fixed in yottacode.

Contributions are welcome, especially from users already running vLLM in day-to-day inference workflows.