can a whole team share one vLLM server for an AI coding agent

Yes. Run vLLM on a shared GPU host and let every Atlas laptop point at the same base URL. vLLM serves an OpenAI-compatible API on port 8000 and handles concurrent requests.

what model should I serve with vLLM for coding

Qwen/Qwen3-Coder-30B-A3B-Instruct is a coding model sized for a shared GPU host. Serve it with vllm serve Qwen/Qwen3-Coder-30B-A3B-Instruct --host 0.0.0.0 --port 8000.

Using Atlas with vLLM in 2026

Atlas runs against vLLM by pointing at the OpenAI-compatible API vLLM serves on port 8000, so a GPU box on your network can back Atlas for the whole team. Serve a model with vllm serve Qwen/Qwen3-Coder-30B-A3B-Instruct --host 0.0.0.0 --port 8000, then add the endpoint in atlas.json as a provider with baseURL http://localhost:8000/v1 and the matching apiKey. vLLM has no authentication by default, so enable it with --api-key or the VLLM_API_KEY env var before you expose the port.

vLLM as the shared inference backend for a team of Atlas users

vLLM serves an OpenAI-compatible API on port 8000, so a GPU box on your network can back Atlas for the whole team. vLLM is the inference backend and Atlas remains the MCP client, which means one server serves many laptops without touching any laptop's tool configuration.

The multi-user shape is what separates vLLM from a single-laptop runtime. vLLM is built for throughput and concurrent requests, so a single GPU host can serve many simultaneous Atlas agent loops rather than one developer's session. Run vLLM on a shared GPU host and let every Atlas laptop point at the same base URL. Each developer keeps their own MCP servers, their own repository, and their own approvals; only the tokens come from the shared box.

Serving a model with vllm serve on port 8000

Serve a model with vllm serve Qwen/Qwen3-Coder-30B-A3B-Instruct --host 0.0.0.0 --port 8000, which exposes the OpenAI API at http://localhost:8000/v1. The --host 0.0.0.0 flag is what makes the endpoint reachable from other machines rather than only from the GPU box itself.

The model argument is a Hugging Face repository identifier, and Qwen/Qwen3-Coder-30B-A3B-Instruct is a coding model sized for a shared GPU host. Binding to 0.0.0.0 rather than localhost is deliberate: a team server that only answers itself is not a team server. Port 8000 is vLLM's default for the OpenAI-compatible API, and once the process is up, http://localhost:8000/v1 on the box and the box's network address elsewhere both resolve to the same endpoint.

vLLM has no authentication by default, so turn it on

vLLM has no authentication by default, so enable it with --api-key or the VLLM_API_KEY env var before you expose the port. Serving on --host 0.0.0.0 without a key means anyone who can route to port 8000 can run inference on your GPU, for free, without asking.

Order of operations matters here. Add the key first, then open the host binding, not the other way around, because an unauthenticated server on a routable interface is exposed for exactly as long as it takes you to notice. --api-key sets it on the command line, and VLLM_API_KEY sets it through the environment, which is the better fit for a systemd unit or a container. Whichever you choose, the same value goes into the apiKey field on the Atlas side.

Configuring the vLLM provider in atlas.json

Add the vLLM endpoint in atlas.json as a provider with baseURL http://localhost:8000/v1 and the matching apiKey. Unlike a local runtime that ignores the key, vLLM actually checks it once you have enabled authentication, so the apiKey field must carry the real value you configured.

On the GPU host itself, baseURL is http://localhost:8000/v1. On a teammate's laptop it becomes the host's address on your network with the same port and /v1 path. The apiKey must equal whatever you passed to --api-key or set in VLLM_API_KEY, and a mismatch returns an authentication error rather than a connection error, which is a useful distinction when you are debugging why one laptop works and another does not.

Sizing the context window with --max-model-len

Size the window with --max-model-len so Atlas's long agent loops are not truncated mid-plan. An agent that reads files, runs commands, and accumulates tool output consumes far more context than a chat turn, so a vLLM server on port 8000 configured for short prompts will cut the plan off partway through.

Truncation in the middle of an agent loop does not fail loudly. The model simply loses the earlier half of what it was doing and produces something confidently wrong, which reads as a capability problem rather than a configuration one. Set --max-model-len deliberately, sized against how long your Atlas sessions actually run, and remember the tradeoff: a longer window costs GPU memory per concurrent request, which matters precisely because the box is shared.

MCP stays on the Atlas side, because vLLM has no MCP server

There is no official vLLM MCP server. vLLM is the inference backend and Atlas stays the MCP client, so every tool your team relies on is configured per laptop in Atlas rather than centrally on the GPU host serving port 8000.

Do not go looking for a way to attach GitHub or a filesystem server to vLLM; the responsibility does not live there. vLLM's contract ends at the OpenAI-compatible API, and Atlas owns the agent loop, the tool calls, and the approvals. In practice this is convenient: a developer can change their MCP servers freely without any coordination with whoever operates the shared GPU host, and the host operator never becomes a bottleneck for tooling changes.

Setup

01Serve a model with vllm serve Qwen/Qwen3-Coder-30B-A3B-Instruct --host 0.0.0.0 --port 8000, which exposes the OpenAI API at http://localhost:8000/v1
02vLLM has no authentication by default, so enable it with --api-key or the VLLM_API_KEY env var before you expose the port.
03Add the endpoint in atlas.json as a provider with baseURL http://localhost:8000/v1 and the matching apiKey.
04Size the window with --max-model-len so Atlas's long agent loops are not truncated mid-plan.
05Keep your MCP servers in Atlas: there is no official vLLM MCP server, since vLLM is the inference backend and Atlas stays the MCP client.
06Run vLLM on a shared GPU host and let every Atlas laptop point at the same base URL.

Frequently asked questions

how do I use Atlas with vLLM: Serve a model with vllm serve Qwen/Qwen3-Coder-30B-A3B-Instruct --host 0.0.0.0 --port 8000, then add the endpoint in atlas.json as a provider with baseURL http://localhost:8000/v1 and the matching apiKey.
does vLLM require an API key: Not by default, which is the problem. vLLM has no authentication by default, so enable it with --api-key or the VLLM_API_KEY env var before you expose the port.
is there a vLLM MCP server: No. There is no official vLLM MCP server. vLLM is the inference backend and Atlas stays the MCP client, so your tools remain configured in Atlas.
can a whole team share one vLLM server for an AI coding agent: Yes. Run vLLM on a shared GPU host and let every Atlas laptop point at the same base URL. vLLM serves an OpenAI-compatible API on port 8000 and handles concurrent requests.
why does my agent plan get cut off with vLLM: The context window is likely too small. Size the window with --max-model-len so Atlas's long agent loops are not truncated mid-plan.
what port does vLLM use with Atlas: Port 8000. vllm serve --host 0.0.0.0 --port 8000 exposes the OpenAI API at http://localhost:8000/v1, which is the baseURL you set in atlas.json.
what model should I serve with vLLM for coding: Qwen/Qwen3-Coder-30B-A3B-Instruct is a coding model sized for a shared GPU host. Serve it with vllm serve Qwen/Qwen3-Coder-30B-A3B-Instruct --host 0.0.0.0 --port 8000.

Try Atlas in your terminal

The terminal-native AI coding agent. Free core, single binary.

Install Atlas

Related guides

Atlas for Astro: Islands, Content Collections, and Zero JS by Default in 2026

Atlas is a terminal-native AI coding agent for Astro in 2026. It reads astro.config.mjs, src/pages, and content collection schemas, drops needless client:load directives, and runs astro check.

Atlas for Kotlin in 2026

In 2026, Atlas empowers Kotlin developers with terminal-native AI coding. It integrates with Gradle and coroutines, offering secure, privacy-focused code assistance with local embeddings and granular control.

Atlas with Command A: Cohere's 256K Context Flagship in 2026

Command A gives Atlas a 256,000 token read window at $2.5 per Mtok input and $10 per Mtok output, with an 8,000 token output cap that shapes how you refactor.

Atlas with Qwen3.5 397B-A17B: The Qwen3.5 Flagship in 2026

Qwen3.5 397B-A17B is Alibaba's Qwen3.5 flagship: 397B total, 17B active, 256K tokens (262,144) of context, $0.60 per Mtok input and $3.60 per Mtok output, running in Atlas.

Atlas with Kimi K2 0711: The Original Trillion-Parameter Preview in 2026

Run Atlas on Kimi K2 0711 in 2026. Moonshot's original K2 preview costs $0.60 per Mtok input, $2.50 per Mtok output, with a 128K tokens (131,072) context.

Atlas with Mistral 7B: Cost, Context, and Real Limits in 2026

Running Atlas on Mistral 7B in 2026: an 8,000 token window at $0.25 / 1M input tokens. Great for smoke-testing a provider block, wrong for agentic coding.

Atlas with Command R7B in 2026: Cohere's Cheapest Model, Used Correctly

Command R7B costs $0.0375 per Mtok input, about 1/66th of Command A, and still carries a 128,000 token context. Here is how to slot it into Atlas without wrecking your code.

Self-Review Your Working Diff Before Committing with Atlas (2026 Workflow)

How to self-review your working diff before committing with Atlas in 2026: bash produces the diff, read checks each file, grep finds leftovers, session revert undoes bad edits.

Browse this resource hub