The engineer who knew your clusters just quit. Now the docs answer back.
Every cluster carries knowledge that lives in one person’s head — why that pod keeps restarting, which service talks to which, what “normal” looks like. Zeus ships an assistant that already knows, because it reads the same live infrastructure you do. Chat with it inside Zeus, or connect your own LLM to the same tools over MCP.
Ask the cluster instead of decoding it.
The hardest part of operating Kubernetes isn’t the commands — it’s the context. What’s actually running, what changed, what’s about to page you. That context normally lives in tribal knowledge and a Slack thread from four months ago. When the person who has it is out, everyone else is guessing at 2am.
The Zeus assistant is built into the console. Ask it a plain question — “why is checkout slow in eu?”, “what’s deployed to production right now?”, “which services can reach the database?” — and it answers by calling the same read APIs the UI uses, not by making things up. It’s grounded: it pulls live pod status, events, overlay health, and your docs before it replies, and it tells you when an answer comes from the community forum instead of official docs.
It can also act, carefully. Admins can let it restart a stuck service or scale replicas straight from the conversation — every action gated by role, nothing destructive, everything logged. And because it’s the same tool set behind an open MCP endpoint, you can point Claude, ChatGPT, or any MCP-capable client at your instance and give your own AI the exact same, permission-scoped view of your clusters.
From zero to running.
Add your model key
Under Settings → AI Assistant, pick a provider — Anthropic (default, claude-opus-4-7), OpenAI, Google, Grok, or Groq — and paste your API key. It’s encrypted server-side. Your keys, your model, your bill.
Ask in plain language
Open the Chat tab or the Ask-AI panel. Answers stream back with the steps visible — thinking, running a tool, writing — so you can see it check get_service_pods before it tells you what’s wrong.
Let it act, if you allow it
Give it the word and an admin can have it restart or scale a service from the conversation. Every call is role-checked and appended to an audit log with the token, user, tool, and result.
Connect your own agent over MCP
Mint a service token scoped mcp:read or mcp:write, point any MCP client at POST /mcp on your instance, and your LLM gets the same 17 tools — same permissions, same audit trail.
Built by people who run this in production.
No hand-waving. Here’s what’s actually under the hood: the kind of detail you’d expect from a platform you’re going to trust with production.
Questions you’d actually ask.
Can it break my cluster?
No. The only actions it can take are restarting a service (a rolling restart) and changing a replica count — both admin-gated and neither destructive. It can’t delete a cluster, drop a database, or edit secrets. Everything it reads is read-only, and every action is written to an audit log you can review.
Whose AI model is this — and who pays for it?
Yours. Zeus doesn’t ship a model; it connects to the provider you choose under Settings → AI Assistant and uses your API key. Anthropic’s claude-opus-4-7 is the default, but OpenAI, Google, Grok, and Groq work too. You control the model and the bill, and your key is stored encrypted.
Does my cluster data get sent to the model provider?
Only what’s needed to answer the question in front of it. When the assistant calls a tool, the result (say, pod status for one service) goes into the conversation the model sees — the same as any AI assistant. Self-host Zeus and the tool calls run entirely inside your network; the only thing that leaves is the prompt you send to your chosen provider.
What is the MCP endpoint for?
Model Context Protocol is the open standard for giving an LLM a set of tools. Zeus exposes its cluster tools over MCP so you’re not limited to the in-app chat — point Claude Desktop, an IDE agent, or your own automation at POST /mcp with a scoped token, and it gets the same permission-checked, audited access to your infrastructure.
How do I stop it from doing things I don’t want?
Two gates. In the app, write actions require the admin role — everyone else gets read-only. Over MCP, each service token carries a policy: mcp:read for lookups only, mcp:write to allow actions, and the cluster-mutating tools still require an admin identity on top. Scope the token to what a given agent should be trusted with.
Is it just a wrapper around kubectl?
No. It uses the same internal APIs the Zeus console uses, so it sees services, environments, deployments, the cross-cluster overlay, and add-on health as first-class things — not raw Kubernetes objects. That’s why it can answer “which services can reach the database” or “what changed in this environment,” questions kubectl can’t.
Keep exploring.
All features →The live pods, logs, and metrics it reads.
Explore →The roles that gate what it can do.
Explore →The toil it helps you get through.
Explore →Start running it today.
Spin up your first cluster free, or get a guided tour from our team.