BerriAI, LiteLLM gateway के पीछे की team, ने 8 मई को LiteLLM Agent Platform open-source किया — production agents को Kubernetes पर चलाने के लिए एक self-hosted infrastructure layer। Stack: agent CRUD और session chat के लिए Next.js dashboard, async tasks के लिए एक worker process, persistent session state के लिए PostgreSQL, और एक Kubernetes sandbox cluster जहाँ हर agent `kubernetes-sigs/agent-sandbox` CRD के through एक isolated pod में चलता है। MIT-licensed, alpha public preview, repo github.com/BerriAI/litellm-agent-platform पर। Platform एक चलते हुए LiteLLM gateway पर depend करता है 100+ LLM providers के routing के लिए।
Architecturally relevant detail Kubernetes primitive है। `kubernetes-sigs/agent-sandbox` Kubernetes SIGs से आने वाला एक CRD है जो "agent execution के लिए isolated environment" को एक first-class Kubernetes resource type के रूप में standardize करता है। अगर वो CRD adoption पकड़ता है, agent sandboxes किसी भी दूसरे Kubernetes workload जितने portable हो जाते हैं। BerriAI का इस CRD पर build करने का choice, अपनी isolation primitive ship करने के बजाय, SIG की दिशा पर एक bet है। Marktechpost writeup specify नहीं करता कि underlying sandbox gVisor, Firecracker, या सिर्फ namespace isolation use करता है — वो CRD implementation पर depend करता है, platform layer पर नहीं। Env vars एक `CONTAINER_ENV_` prefix convention के through inject होती हैं (तो `CONTAINER_ENV_GITHUB_TOKEN=ghp_...` sandbox के अंदर `GITHUB_TOKEN=ghp_...` बन जाता है), sessions Postgres में persist होती हैं, और schema migrations startup पर init container के तौर पर चलती हैं।
इसे Anthropic के Routines के against रखो, जो इस हफ्ते की शुरुआत में announce हुए: Routines Anthropic के cloud पर चलते हैं, repository events और HTTP triggers से tie होते हैं, और कोई published pricing नहीं है। LiteLLM Agent Platform आपके Kubernetes cluster पर self-hosted है, MIT-licensed, और LiteLLM gateway के 100+ provider router के through provider-agnostic। एक ही problem statement — आप production में agents कहाँ चलाते हैं — opposite philosophy। Regulatory या data-locality constraints (healthcare, finance, EU residency) वाली teams के लिए, self-hosted plus multi-provider ही single viable shape है। उन constraints के बिना वाली teams के लिए, Routines का "Anthropic ने इसे operate किया" lower-ops shape है। Split दोनों तरफ की marketing से ज़्यादा wide है: LiteLLM Agent Platform first-party Claude tooling integration पर Routines से parity claim नहीं करता, और Routines provider neutrality पर LiteLLM से parity claim नहीं करता।
सोमवार: अगर आप इस तिमाही में production agents कहाँ चलाने हैं choose कर रहे हो, matrix है cloud-operated single-provider (Anthropic Routines, OpenAI Assistants, AWS Bedrock Agents) vs. self-hosted multi-provider (LiteLLM Agent Platform, Modal या E2B पर build-your-own)। LiteLLM Agent Platform alpha में है — alpha पर load-bearing workloads मत डालो — लेकिन architectural choices (Kubernetes SIG CRD, Postgres state, env-var injection convention) आपको बताते हैं beta में क्या expect करें। अगर आप पहले से provider routing के लिए LiteLLM gateway चला रहे हो, Agent Platform एक additive deploy है, migration नहीं। Upstream maturity के लिए `kubernetes-sigs/agent-sandbox` को watch करो — वो lock-in question है, BerriAI का खुद का dashboard नहीं।