The gateway: one server every app calls

Retries, fallbacks and keys set up in each app drift apart. The gateway holds them in one place, and apps call it like any OpenAI-compatible API.

model_list:
  - model_name: quick
    litellm_params:
      model: shop/small

litellm_settings:
  custom_provider_map:
    - {"provider": "shop", "custom_handler": shop_llm.shop}

general_settings:
  master_key: sk-gateway-1234

The config has the same three parts as the Python code. model_list is the Router's list. litellm_settings sets module settings, here the custom provider map pointing at shop in shop_llm.py. general_settings holds server settings, here a master key every request must present.

litellm --config config.yaml --port 4000 > gateway.log 2>&1 &
until curl -s localhost:4000/health/liveliness > /dev/null; do sleep 1; done
curl -s localhost:4000/chat/completions \
  -H "Authorization: Bearer sk-gateway-1234" \
  -H "Content-Type: application/json" \
  -d '{"model": "quick", "messages": [{"role": "user", "content": "My parcel has not arrived"}]}'
echo
kill %1

litellm --config config.yaml starts the gateway; its start-up banner and logs go to gateway.log to keep the output readable. The until loop waits for the health endpoint to answer before sending anything, because the server takes a few seconds to start.

The request is a plain OpenAI Chat Completions request to /chat/completions, and the answer is the same JSON shape, with model reported as the group the app asked for. The app never learns which provider stood behind quick.