O LiteLLM lançou duas versões com cinco minutos de diferença no início de 23 de agosto: v1.99.0-rc.1, uma prévia, às 00:23 UTC, e v1.98.0, a estável, às 00:28 UTC. As notas da versão estável listam uma correção de autenticação. O commit que desfez essa correção está na mesma história.

O que a correção abordava

O PR #36837 tem o título “fix(auth): stop the team fallback from widening model access”. O LiteLLM determina a quais modelos um chamador pode chegar em parte com base no registro de equipe desse chamador. Quando a busca pela equipe falha, o código recorria a campos carregados no próprio token — e, nesse caminho de fallback, uma lista vazia de team_models é interpretada como permissão para todos os modelos, e não para nenhum. A correção transformou a ausência de equipe em uma recusa explícita.

Por que ela foi revertida

A Admin UI assina sua chave de sessão com um ID de equipe sentinela, litellm-dashboard, que intencionalmente não tem linha no banco de dados. A correção interpretou essa linha ausente como condição de recusa, então toda solicitação do painel retornava 404 e todos os administradores ficaram bloqueados. O PR #36982 a reverteu em 14 de agosto, restaurando o fallback derivado do token.

A distorção: uma entrada de changelog não é um estado implantado

Ler as notas da v1.98.0 faz parecer que a brecha do fallback de equipe foi fechada. Ler o histórico de commits mostra que a correção chegou, quebrou o painel e foi revertida nove dias antes de essa versão ser publicada. Ambos os fatos são públicos; apenas um deles está no changelog. Esse é o risco geral de tratar notas de versão como um registro de segurança — elas documentam o que foi mesclado, não o que sobreviveu.

A reversão é franca sobre o que ela custa

Ela não se apresenta como uma correção. A descrição afirma que restaura o fallback derivado do token para reparar a regressão ao mesmo tempo em que reconhece que isso reabre a falha de segurança ligada à ampliação do acesso a modelos, e que é necessária uma reimplementação mais cuidadosa. É uma observação incomumente clara para deixar em uma reversão, e é justamente a parte que não aparece na página da versão.

O que os operadores devem verificar por conta própria

Não é possível estabelecer pelas notas públicas da versão se uma reimplementação corrigida está presente na release candidate v1.99.0, e isso não é afirmado aqui. Quem depende de restrições de modelo por equipe deve testar o comportamento na própria implantação — especificamente, o que uma chave com uma equipe não resolvível e uma lista vazia de modelos de fato pode chamar — em vez de inferir isso de uma linha de changelog.