# kprompt — full documentation for AI assistants > AI-powered runtime that understands your Kubernetes environment — turn intent into context-aware operations, investigations, and recommendations. Optional always-on Observe agent. Plan before apply. Open-source CLI. Experimental. Canonical site: https://kprompt.ai llms.txt index: https://kprompt.ai/llms.txt GitHub: https://github.com/kprompt/kprompt X: https://x.com/kpromptai LinkedIn: https://www.linkedin.com/company/kprompt Bluesky: https://bsky.app/profile/kprompt.bsky.social Contact: hello@kprompt.ai License: Apache-2.0 Version: v0.12.2 Docs last updated: 2026-08-13 ## Positioning (honest) - Category: AI Runtime for Kubernetes — understands your environment; turns intent into operate / investigate / recommend with plan-before-apply. Triangle hub (Runtime vs Gateway vs Platform): https://kprompt.ai/blog/ai-runtime-vs-ai-gateway-vs-agent-platform - Experienced engineers are a target: augment expertise by reducing context you must gather manually. - Investigation/AI SRE packs and Observe are capability lanes — not the entire product. - Signals (Prom/OTel/logs) enrich the runtime when present; no bespoke per-database connectors. - Not McKinsey ARK (Agentic Runtime): hosts agent apps as CRDs — https://kprompt.ai/blog/kprompt-vs-ark - Not agentgateway (AI/MCP/A2A gateway): LLM/MCP traffic data plane vs PlanResult ops — https://kprompt.ai/blog/kprompt-vs-agentgateway · https://kprompt.ai/blog/agentgateway-alternatives - Not kagent (CNCF agent platform): Agents/MCP/A2A on K8s vs PlanResult ops — https://kprompt.ai/blog/kprompt-vs-kagent · https://kprompt.ai/blog/kagent-alternatives - Compose with kagent (architecture invite): wrap kprompt mcp serve as kmcp MCPServer / RemoteMCPServer; PlanResult stays refuse-able; apply out-of-band — https://kprompt.ai/blog/kprompt-kagent-integration - MCP tool provider (`kprompt mcp serve`): editor assistants (Cursor, Claude Desktop) call read/plan-only tools over stdio; mutations return a PlanResult and never auto-apply. IDE interop, not an MCP/A2A agent platform (that stays kagent's lane) — https://kprompt.ai/docs/mcp - Same NL-CLI lane as kubectl-ai for day-2 mutate; different mutate contract (plan → safety → approve) plus in-cluster Observe path. - Not a K8sGPT fleet scanner; not a hosted Lens clone. - Optional in-cluster Observe agent (Helm): namespace watch → Incident → gated notify. - Autopilot (ADR-0015) is propose-only by default — never silent apply. - Shipped v0.12.2: investigate + impact walk Istio VirtualServices with honest mesh degrade (on top of v0.12.1 SEC-007 / Ingress / Prom / Flux inventory / kind e2e). - Shipped v0.12.1: SEC-007 hardening + doctor advisories, investigate Ingress/Prometheus, Flux inventory drift, Coordinator Deployment probe, kind e2e in CI (on top of v0.12.0 provider/GitOps pack). - Shipped v0.11.0: `kprompt mcp serve` (read/plan-only IDE interop, ADR-0024), Azure OpenAI preset (P-006), DaemonSet `--wait`. - Shipped AI Runtime closure v0.10.0 (ADR-0023): closed Learn loop, policy-gated Autopilot apply (product path), continuous Coordinator (proactive tick + opt-in mesh/OTel blast-radius), topology Knowledge Graph edges, Incident→PlanResult bridge, durable cluster memory (cross-ns outcome ring + fleet read) — default stays propose-only, never silent auto-heal. - Building / next: deeper continuous multi-agent reasoning, interactive Team topology / timeline UI, sandbox/chaos Simulation lab, richer Prom/OTel/mesh hops — do not claim Secret-value CMDB or unsupervised auto-heal. - Shipped Team GitHub App install MVP: GET/PUT/DELETE /v1/org/github + Setup URL auto-bind (A-067) + App JWT installation tokens (A-068) + app /integrations. - Shipped Team connected repos: GET/POST/DELETE /v1/org/repos + bind/unbind UI (metadata only). - Shipped Team pipeline bindings: GET/POST/DELETE /v1/org/repos/{id}/pipelines (github_actions/tekton/argo metadata + deep links; never in-cluster mutate). - Shipped Team CI ingest: POST /v1/webhooks/github (HMAC) + POST /v1/ci/planresults → plan artifacts + audit reported. - Shipped Team CI PlanResult viewer: app /ci + /ci/[id] (safety vocabulary + raw JSON; never auto-apply; subsumes A-033). - Shipped Coordinator blast-radius MVP: GET /v1/blast-radius + `agent coordinator blast-radius` (handoff hops with risk; not mesh/OTel; see /docs/coordinator-knowledge). - Shipped Namespace Agent intelligence brief: `kprompt agent status -n ` (health + incidents + patterns + memory; quota/HPA detectors; see /docs/agent-status). - Shipped Knowledge Graph: service graph + Ingress/PVC + Secret/ConfigMap name-only mounts + impact + memory deps (never Secret.data; see /docs/graph). - Shipped Namespace Agent fleet UX MVP: `kprompt agent list -A` (KpromptAgent CRs + labeled Deployments; see /docs/agent-fleet). - Shipped Coordinator Shared Knowledge: GET /v1/knowledge + optional file/ConfigMap durable handoff ring (Helm knowledge.enabled; see /docs/coordinator-knowledge). - Shipped Simulation MVP: change preview = PlanResult dry-run + blastRadius + impact + Helm dry-run (not a sandbox; see /docs/simulation). - Shipped Cost Intelligence MVP: optimize idle/rightsizing/HPA + labeled $/carbon notes (not a cloud bill; see /docs/optimize). - Shipped GitHub Integration MVP: CLI --gitops PR mode + Flux/Argo status + agent gitops evidence (Team SCM A-061…A-069 shipped including Setup URL, App JWT tokens, /ci viewer, Checks annotate upsert). - Shipped Incident Memory: namespace facts + patterns + durable incidents (local/ConfigMap; never auto-mutate). - Shipped thin Coordinator: cross-ns handoff + optional kube probe + InvestigationReport merge (mutate off). - Architecture diagrams: AI Runtime pipeline + PlanResult contract + dual path — /docs/architecture. - Long-term direction: continuous reasoning under the same approval DNA — see roadmap. ## FAQ ### What is an AI Runtime for Kubernetes? kprompt is an AI-powered runtime that understands your Kubernetes environment and turns intent into context-aware operations, investigations, and recommendations. You describe the outcome; it gathers relevant cluster context, reasons about what matters, and produces a reviewable PlanResult before any mutation. It is not a ChatGPT wrapper, a kubectl command generator, a monitoring-only AIOps dashboard, or a silent auto-healer. More: https://kprompt.ai/docs/architecture ### Is kprompt only for incidents and AI SRE? No. Investigation (investigate / why / timeline / impact) and the optional Observe agent are one capability lane. The same runtime also covers day-2 operate (deploy, scale, rollback), explain/read, optimize and audit reports, dependency graphs, and multi-tool routes — always under plan → approve for mutations. More: https://kprompt.ai/docs ### Why would an experienced Kubernetes engineer use it? You already know kubectl, PDBs, HPA, and failure modes. What still hurts at scale is gathering and correlating context across workloads, dependencies, events, metrics, and risks. kprompt augments that expertise by reducing manual correlation — it does not pretend to replace it. More: https://kprompt.ai/blog/ai-sre-not-ai-kubectl ### How is kprompt different from a chatbot, CLI wrapper, or dashboard? A chatbot answers how-to docs; kprompt reasons about your live cluster. A CLI wrapper translates English into kubectl; kprompt understands environment state before proposing a PlanResult. A dashboard shows isolated signals; kprompt connects related evidence when signals are available. Same word “AI,” different contract. More: https://kprompt.ai/blog/kubernetes-ai-tools-comparison ### Do I need Prometheus, Loki, or OpenTelemetry? No for core Kubernetes operate and many reads. When Prom, OTel, Grafana, or similar backends are configured, they enrich understanding (perf explain, optional graph edges, dashboards). Missing backends degrade honestly — kprompt does not invent metrics or claim per-database product connectors. More: https://kprompt.ai/docs/integrations ### What is the Observe agent? An optional in-cluster Observe agent that watches a namespace, correlates Pods/Events into Incidents, and sends gated Slack/Discord/webhook alerts. Default mode never mutates. Optional Autopilot propose emits a PlanResult; apply stays human-gated. The laptop CLI still works without any agent — try kprompt demo for a $0 kind walkthrough. More: https://kprompt.ai/docs/agent ### AI Runtime vs AI Gateway vs Agent Platform — which is kprompt? kprompt is an AI Runtime for Kubernetes ops: PlanResult → safety → approve. An AI Gateway (e.g. agentgateway) governs LLM/MCP/A2A traffic. An Agent Platform (e.g. kagent) runs Agents as CRDs. Same vocabulary, three layers — see the hub post for the triangle and deep links. More: https://kprompt.ai/blog/ai-runtime-vs-ai-gateway-vs-agent-platform ### How is kprompt different from agentgateway? agentgateway is an AI-native proxy for LLM, MCP, and A2A traffic (Gateway API). kprompt is a plan-before-apply ops CLI (and optional Observe notify) — natural language → PlanResult → approve. kprompt mcp serve is IDE interop, not a cluster MCP gateway. Keep agentgateway for traffic governance; choose kprompt for gated day-2. Many teams use both. More: https://kprompt.ai/blog/kprompt-vs-agentgateway ### Is kprompt an agentgateway alternative? Yes for the job “gated Kubernetes day-2 / SRE without standing up an AI/MCP gateway.” No for the job “LLM/MCP/A2A Gateway API data plane.” See the agentgateway alternatives hub for a job-based map. More: https://kprompt.ai/blog/agentgateway-alternatives ### How is kprompt different from kagent? kagent (CNCF Sandbox) is a Kubernetes-native agent platform: Agents as CRDs, MCP tools, A2A, GitOps. kprompt is a plan-before-apply ops CLI (and optional Observe notify agent) — natural language → PlanResult → approve. Overlapping SRE demos, different products. Keep kagent when you need an agent control plane; choose kprompt when you need a refuse-able day-2 plan. Many teams use both. More: https://kprompt.ai/blog/kprompt-vs-kagent ### Is kprompt a kagent alternative? Yes for the job “gated Kubernetes day-2 / SRE without standing up Agents-as-CRDs.” No for the job “CNCF agent platform with MCP/A2A.” See the kagent alternatives hub for a job-based map. More: https://kprompt.ai/blog/kagent-alternatives ### Does kprompt apply changes to my cluster automatically? No. Every mutating intent compiles into a PlanResult that lists the resources, diffs, and risk level before anything runs. On a TTY you confirm with y/N; in scripts you pass --approve explicitly. Wipe-class prompts are hard-denied instead of planned, and Autopilot is propose-only by default (ADR-0015) — it never applies silently. More: https://kprompt.ai/docs/safety ### Should I replace kubectl or K9s with kprompt? No. kubectl remains the precise API client and scripting language; K9s remains the best live terminal UI for watching rollouts and hopping between Pods. kprompt sits beside them when the bottleneck is correlating intent and cluster context — not exact flags or a resource browser. More: https://kprompt.ai/blog/kubectl-vs-k9s ### Where do my kubeconfig and LLM keys live? On your machine. kprompt reads your existing kubeconfig locally. For NL plans use local Ollama ($0, no key) or your own cloud provider key (BYOK). Cluster credentials are not uploaded to a control plane by default. More: https://kprompt.ai/docs/providers ### Can I use kprompt in CI/CD pipelines? Yes, for plan generation and gating. kprompt emits a stable JSON PlanResult with intent, resources, diffs, and risk, so a pipeline can fail on high-risk plans or post the plan to a pull request before a human approves apply. More: https://kprompt.ai/docs/ci ### Is kprompt production ready? It is labelled experimental on purpose. Plans can be wrong or incomplete outside the hard-deny rules, so read every plan before apply, start on kind or a sandbox cluster, and treat --approve with care. More: https://kprompt.ai/docs/roadmap ### Is kprompt free and open source? Yes. The CLI is Apache-2.0 licensed on GitHub and stays free. There is an optional Team surface for organisations that already have access, but there is nothing to buy as a public signup product today. More: https://kprompt.ai/docs/install --- # Documentation # Overview URL: https://kprompt.ai/docs kprompt is The AI Runtime for Kubernetes — an AI-powered runtime that understands your cluster and turns intent into context-aware operations, investigations, and recommendations. Plan before apply. Experimental open-source CLI + optional Observe agent. ## Experimental — use carefully kprompt is early software. Plans can be wrong, incomplete, or unsafe outside the hard-deny rules. Always read the plan (and diffs) before apply. Prefer non-production or kind clusters while you learn the tool. Avoid --approve on unfamiliar prompts. You remain responsible for changes applied with your kubeconfig credentials. The AI Runtime for Kubernetes means: you state intent; kprompt understands cluster context; it reasons; then it operates, investigates, or recommends — with a reviewable PlanResult before mutate. Investigation and AI SRE packs are one capability lane, not the whole product. Natural-language plans use your kubeconfig and your LLM (local Ollama = $0, or BYOK). Fastest first run: zero-LLM kind Observe walkthrough. Already have a cluster? Adopt (15 min) prefers bind-over-install. ## Two surfaces — one contract Laptop CLI is reactive: you ask, kprompt plans. Optional Observe agent is always-on in a namespace: watch → Incident → gated Slack/webhook — never silent mutate. Same PlanResult DNA if a fix is proposed. Start with Demo, then read Observe agent for Helm. Visual map of the AI Runtime pipeline, PlanResult contract, investigation CLI packs, and Observe agent: Architecture. ## What it is - AI Runtime for Kubernetes — understands environment context; turns intent into outcomes - Apache-2.0 CLI: Plan → safety → approve → apply loop - Optional Observe agent (Helm) — namespace watch → Incident → gated Slack/webhook; no mutate - Operate: deploy, scale, rollback, named delete - Understand: get/list, explain, logs, describe, dependency graph - Investigate: investigate / why / timeline / impact (one capability lane) - Analyze / recommend: optimize reports, audit hygiene, score MVP rollup - Helm, Argo Workflows, Prometheus, OpenTelemetry, Grafana (when present) - Tekton, KEDA, Istio (read-first), Crossplane, Flux/Argo CD GitOps - Local history, CI JSON PlanResult, Homebrew install, optional Team login ## What it is not (yet) - Not a ChatGPT wrapper, kubectl command generator, generic workflow engine, or Kubernetes chatbot - Not a monitoring-only AIOps dashboard or incident-only product - Not production-hardened or stability-guaranteed - Not Autopilot-by-default — optional agent is Observe; Autopilot MVP is propose-only (ADR-0015) - Not a Secret-value / external-API Knowledge Graph CMDB — topology KG (service + Ingress/PVC + Secret/CM name-only + ExternalName/env-host/EndpointSlice/NetworkPolicy) ships; Secret values stay out (docs/graph) - Not a sandbox / failure-injection Simulation lab — MVP is change preview (plan + blastRadius + impact + Helm dry-run; docs/simulation) - Not a full PDB/topology-spread reliability scanner product — use optimize/audit/score MVP; richer scanners are direction - Not a Kagent-class multi-agent framework or a K8sGPT fleet scanner - Not a replacement for Helm, Argo, Prometheus, kubectl, or operator review - Not a Lens/Headlamp replacement — optional local read-only inventory is kprompt-dash (localhost only) - Not a hosted multi-cluster / fleet SaaS — multi-context is laptop kubeconfig fan-out only (no kubeconfig upload) - Not a public Team signup product — CLI enrollment is opt-in for orgs that already have access - Nothing to buy today; Free CLI stays free Where we deepen next (richer recipes, drift reports, deeper multi-agent reasoning, sandbox Simulation) is documented honestly on Roadmap & vision — shipped vs building vs exploring. Multi-context CLI docs: Multi-cluster. Observe agent install: Observe agent. Runtime closure (Learn · Incident→PlanResult · continuous Coordinator · topology KG · durable memory) shipped in v0.10. Source of truth for the binary: github.com/kprompt/kprompt. This site mirrors install, safety, providers, and CI docs for operators who land here first. --- # Install URL: https://kprompt.ai/docs/install Install the kprompt CLI on macOS or Linux from the release script, Homebrew, or source — then verify with kprompt doctor. Installing is easy; applying is not automatically safe. After install, the fastest demo is the zero-LLM kind walkthrough ($0, no provider key). For natural-language plans, prefer local Ollama or a sandbox cluster, and leave --approve off until you know how plans look. ## Recommended ``` curl -fsSL https://kprompt.ai/install | bash ``` Detects your OS and architecture, downloads the matching binary from the latest GitHub Release, and installs it into ~/.local/bin. No sudo is needed because it avoids root-owned paths like /usr/local/bin. ## Homebrew ``` brew install kprompt/tap/kprompt ``` Installs the official GitHub Release binary via the kprompt/homebrew-tap formula (macOS and Linux). ## Fallback (jsDelivr, pinned tag) ``` curl -fsSL https://cdn.jsdelivr.net/gh/kprompt/kprompt@v0.9.0/install/install.sh | bash ``` Use this when kprompt.ai is unreachable or when you want the installer itself pinned to a release tag rather than served from the site. ## Supported platforms | OS | Architectures | How to install | | --- | --- | --- | | macOS | arm64 (Apple Silicon), amd64 | Install script or Homebrew | | Linux | amd64, arm64 | Install script or Homebrew | | Windows | amd64, arm64 | Build from source with Go | The install script covers macOS and Linux and exits with a clear message on any other OS or architecture. Windows users build from source — the CLI itself is plain Go with no platform-specific cluster access. ## Installer options | Variable | Default | Purpose | | --- | --- | --- | | KPROMPT_VERSION | latest release | Pin a specific tag, for example v0.9.0 | | KPROMPT_INSTALL_DIR | ~/.local/bin | Install elsewhere; system paths usually need sudo bash | (Pin a version, or install system-wide) ``` KPROMPT_VERSION=v0.9.0 curl -fsSL https://kprompt.ai/install | bash # system-wide (root-owned target needs sudo) KPROMPT_INSTALL_DIR=/usr/local/bin curl -fsSL https://kprompt.ai/install | sudo bash ``` ## PATH ``` echo 'export PATH="$HOME/.local/bin:$PATH"' >> ~/.zshrc source ~/.zshrc kprompt version ``` The installer warns when the target directory is missing from your PATH. Use ~/.bashrc instead of ~/.zshrc on shells that read it. ## Verify the install ``` kprompt version kprompt doctor # kubeconfig + LLM key + integrations + Team health kprompt doctor --json # same checks, machine-readable ``` kprompt doctor is the fastest way to confirm a working setup: it checks that a kubeconfig context resolves, that an LLM provider is usable (Ollama needs no key; cloud BYOK needs your provider env var — not a kprompt purchase), which day-2 integrations were detected, and whether optional Team enrollment (kp_… token) is healthy. It exits non-zero when a required check fails, so it also works as a CI preflight. ## Upgrade ``` # script installs: rerun it curl -fsSL https://kprompt.ai/install | bash # Homebrew brew upgrade kprompt/tap/kprompt ``` ## Uninstall ``` rm ~/.local/bin/kprompt # or: brew uninstall kprompt rm -rf ~/.kprompt # config, history, cached policy/credentials ``` Removing ~/.kprompt clears local config, prompt history, and any cached Team policy or credentials. It never touched your kubeconfig, so cluster access is unaffected. ## Troubleshooting | Symptom | Cause | Fix | | --- | --- | --- | | command not found: kprompt | Install directory is not on PATH | Add ~/.local/bin to PATH, then reload the shell | | Cannot write to … (permission denied) | Target directory is root-owned | Keep the default ~/.local/bin, or rerun with sudo bash | | No GitHub release found yet | Release lookup failed or was rate-limited | Set KPROMPT_VERSION, or go install ./cmd/kprompt | | unsupported os / unsupported arch | Platform outside macOS and Linux on amd64/arm64 | Build from source with the Go toolchain | ## From source ``` git clone https://github.com/kprompt/kprompt.git cd kprompt go install ./cmd/kprompt ``` Or build into a local path without touching your Go bin directory: ``` go build -o bin/kprompt ./cmd/kprompt ./bin/kprompt version ``` Source builds need Go 1.23 or newer. Next: try the $0 walkthrough or Ollama, then walk the plan → approve loop on a sandbox cluster. --- # Quickstart URL: https://kprompt.ai/docs/quickstart Try kprompt in ~60 seconds at $0 (kind + Observe walkthrough), then NL plans via local Ollama or your own cloud provider key — nothing to buy from kprompt. Funnel: install → kprompt demo ($0 Observe) → kprompt init --ollama for NL ($0) → optional cloud BYOK. kprompt does not sell API keys. Team kp_… tokens are org policy/audit only. When you are ready for natural-language plans on your own cluster, jump to Level up with NL. Already have a real cluster? Prefer the brownfield Adopt playbook (bind tools, read-first) over installing a second stack. ## 1. Try at $0 — no provider key (~60s) Requires Docker (or Colima/Podman), kind, kubectl, and make. Start with kprompt demo for prerequisite checks and the exact commands. The walkthrough is deterministic and offline — zero LLM spend. (CLI guide + Observe walkthrough) ``` kprompt demo kprompt demo --check # then (as printed): git clone https://github.com/kprompt/kprompt-examples.git cd kprompt-examples && make walkthrough ``` Prefer one failure at a time? Use make up && make break SCENARIO=01-crashloop && make agent. Full caveats and scenario list: kprompt-examples README. ## 2. Level up with NL plans Natural-language plans (scale, investigate, Helm install, …) need an LLM on your machine. Prefer local Ollama ($0) first. Cloud provider keys are optional BYOK — yours, not a kprompt product. Start on a disposable cluster (kind, minikube, or a dedicated sandbox). Do not point an unreviewed --approve flow at production until you have practiced the plan → approve loop. ### Cluster access ``` kubectl config current-context kubectl get ns ``` ### A) Local Ollama ($0 — recommended first) ``` # ollama serve && ollama pull llama3.2 kprompt init --ollama kprompt "list pods" ``` No cloud account and no provider key. Bare kprompt prints a readiness coach when unconfigured (no silent OpenAI default). Details: Providers · Init. ### B) Optional: your cloud provider key (BYOK) ``` kprompt init --provider gemini export KPROMPT_GEMINI_API_KEY="..." # or OPENAI / ANTHROPIC / GROQ / … — see Providers ``` Config lives at ~/.kprompt/config.yaml. It never stores provider keys — only whether a key is set or unset in the environment. Provider matrix: Providers. ### Save defaults (no secrets) ``` kprompt config set namespace default kprompt config ``` ### First prompts ``` kprompt "list deployments" kprompt "scale api to 3" # plan + y/N on a TTY kprompt "scale api to 3" --approve --wait kprompt "explain why api is crashing" kprompt tools ``` ## 3. Pick a terminal theme ``` kprompt theme preview # sample every palette kprompt --theme dracula "list deployments" kprompt config set theme nord # auto | dracula | nord | gruvbox | mono | none ``` Themes only color terminal output, respect NO_COLOR, and stay disabled when stdout is not a TTY. See Themes for environment overrides. ## 4. Try an installed integration ``` kprompt tools kprompt "install redis" # Helm kprompt "train a yolov11 model" --approve --wait # Argo Workflows kprompt "why is my api slow?" -n production # Prometheus kprompt "optimize my cluster" # read-only report kprompt "show service dependency graph" kprompt "show gitops sync status" ``` Run kprompt tools first. Integrations use real CLIs/CRDs and configured endpoints; missing dependencies produce setup hints instead of fabricated output. ## 5. Optional Team enrollment ``` kprompt login --open kprompt whoami kprompt policy pull kprompt policy ``` Free CLI behavior is unchanged until you enroll. Login issues a Team kp_… token for orgs that already have access — not a public signup or LLM-key purchase. App /run jobs also need kprompt run listen — see App runs & CLI bridge. ## History ``` kprompt history kprompt history rerun kprompt history rerun 3 --approve ``` --- # Adopt on an existing cluster URL: https://kprompt.ai/docs/adopt Brownfield playbook: attach kprompt to a working kubeconfig in ~15 minutes — detect, bind existing tools, read-first insight, optional MCP. Prefer configure over install. Greenfield is easy (kind + demo). This page is the other path: you already have a cluster, Helm or Prometheus somewhere, GitOps, and RBAC you do not want to rewrite. Goal — first useful insight without installing a second monitoring stack. ## Scorecard | Signal | Good | Avoid | | --- | --- | --- | | Time-to-first-insight | Useful read in ≤15 min | Spend the hour installing operators first | | Cluster touch | No new operators | kube-prometheus-stack “just for the demo” | | Tools | Bind URLs / PATH you already have | Treat missing as “must install via setup” | | Mutations | Plan only; apply later on a TTY | --approve on the first unfamiliar prompt | | IDE | Optional MCP read/plan | Expect auto-apply from the editor | ## 15-minute path ### 0–2 min — binary + context ``` curl -fsSL https://kprompt.ai/install | bash # or: brew install kprompt/tap/kprompt kubectl config current-context # staging / sandbox first kprompt version ``` Use a non-production context until the plan loop feels boring. Multi-context notes: Multi-cluster. ### 2–5 min — provider ``` # $0 local (recommended first) ollama serve && ollama pull llama3.2 kprompt init --ollama # or BYOK — your key, never stored in config.yaml # kprompt init --provider openai && export KPROMPT_OPENAI_API_KEY=… kprompt doctor ``` Init only writes provider/model (and optional context). It does not create clusters or run setup installs. ### 5–8 min — detect, then bind ``` kprompt tools # Prefer bind when backends already exist: kprompt config set tools.prometheus.url http://prometheus.monitoring:9090 # kprompt config set tools.grafana.url http://grafana.monitoring:3000 # kprompt config set tools.otel.backend tempo kprompt tools kprompt doctor ``` kprompt tools inventories Helm on PATH, Argo Workflow CRDs, Prom/Grafana/OTel URLs, GitOps controllers, and more. Missing is a hint — not a mandate to install. Use kprompt setup only when you truly lack a component and accept an approve-gated install plan. Full flag reference: Setup · Integrations. ### 8–12 min — first insight (read-only) ``` kprompt "list deployments" -n kprompt "explain why is failing" -n kprompt "why is my api slow?" -n # needs Prometheus URL kprompt "optimize my cluster" # read-only report kprompt "show service dependency graph" ``` Reads run under your kubeconfig RBAC. Optimize and graph degrade honestly when Prom/OTel are absent — they do not invent metrics. ### 12–15 min — optional IDE + plan-only mutate (MCP (Cursor / Claude Desktop) — never applies) ``` # ~/.cursor/mcp.json (or project .cursor/mcp.json) { "mcpServers": { "kprompt": { "command": "kprompt", "args": ["mcp", "serve"] } } } ``` (Mutation stays plan → human approve) ``` kprompt "scale to 3" -n # read the plan + risk; approve on TTY, or leave it # Apply only after you trust the shape: # kprompt "scale to 3" -n --approve ``` MCP tools are read/plan-only. An assistant can call kprompt.plan; it cannot pass --approve over the protocol. Details: MCP · Safety. ## Anti-patterns - Installing kube-prometheus-stack before trying tools.prometheus.url against the Prom you already run - Pointing the first session at production with --approve - Treating setup --profile platform as the default brownfield path - Expecting MCP or Autopilot to mutate without a human on the approve path - Skipping doctor when tools look empty — often config URL, not a missing CRD ## What this playbook is not - Not a cluster provisioner (kind / EKS / GKE stay out of scope) - Not a second GitOps or Helmfile installer - Not a promise that every integration lights up green in 15 minutes — only that the path prefers bind + read-first - Not production Autopilot — Observe agent and Autopilot stay propose/notify unless you explicitly opt into approve flows elsewhere Next: deepen Integrations, wire MCP, or practice Safety on a sandbox mutate. Narrative version of this path: brownfield in 15 minutes. --- # Commands URL: https://kprompt.ai/docs/commands Supported intents, what kprompt will not do, prompt examples, and useful flags in the shipped CLI. ## Day-0 vs Advanced kprompt --help groups Day-0 commands first (init, demo, doctor, config, contexts, version). Power surfaces (agent, setup, Team login, recipes, …) are under Advanced — also listed by kprompt advanced. Completion still includes Advanced command names. | Day-0 | Advanced (examples) | | --- | --- | | init · demo · doctor · config · contexts · version | agent · setup · tools · history · recipe · login · run | ## Capability map kprompt is an intent compiler on an existing kubeconfig: plan → safety → approve → apply. It is not a cluster provisioner, cloud console, or silent remediator. | Can do | Cannot / will not | | --- | --- | | Day-2 ops on a cluster you already reach (deploy, scale, explain, drift, …) | Create kind / EKS / GKE / AKS clusters (“bana bir cluster kur” → unknown intent) | | Optional Team /run via kprompt run listen on your laptop | Hold kubeconfig in the control plane or browse the live cluster from the app alone | | Observe agent: watch → Incident → gated alert / propose-only Autopilot | Silent apply from the agent (Autopilot apply stays gated) | | BYOK or local Ollama for NL plans | Sell or host LLM API keys as a kprompt product | Need a disposable cluster first? Run kprompt demo, or kind / kprompt-examples make up, then point kubectl / kprompt at that context. App bridge: App runs & CLI bridge. Observe demo: Observe agent. ## Supported intents | Intent | Examples | Notes | | --- | --- | --- | | deploy | "deploy redis" | Deployment ± Service shortcuts | | scale | "scale api to 10" | Deployment replicas | | rollback | "rollback payment-api" | Rollout undo | | delete | "delete deployment redis" | Named Pod/Deployment/Service only | | get / list | "list deployments" | Read-only; built-ins + discoverable CRDs | | explain | "explain why api is crashing" | Deployment → ReplicaSet → Pods → Events → Logs; may suggest patch | | investigate / why / timeline | "investigate checkout" | Multi-hop RCA / causal why / event timeline | | drift | "check cluster drift" | Read-only GitOps sync/health vs live (RiskLow) | | learn | "learn my cluster" | Detect tools; save local profile (RiskLow) | | audit / cleanup / search / score | "score my cluster" | Hygiene, orphans, inventory search, scorecard | | logs | "logs payment-api" | Tail | | describe | "describe payment-api" | Compact describe | | Helm install / upgrade | "install redis" | Template and dry-run preview before approval | | workflow | "train a yolov11 model" | Argo Workflow generate/submit/status/--wait | | performance | "why is my api slow?" | Read-only Prometheus-backed diagnosis | | trace | "trace payment request" | Jaeger/Tempo span tree + bottlenecks | | dashboard | "show payments dashboard" | Grafana search + panel summary | | optimize | "optimize my cluster" | Read-only idle / rightsizing / HPA hints | | graph | "show service dependency graph" | Service graph (+ optional OTel edges) | | GitOps | "show gitops sync status" | Flux/Argo CD health; approved sync | | Tekton | "run the build pipeline" | PipelineRun generate/submit/status | | KEDA | "autoscale api with KEDA" | ScaledObject generate/submit/status | | Istio | "show traffic for checkout" | VirtualService traffic summary (read-first) | | Crossplane | "provision a postgres database" | Cloud claims; RiskHigh + strong approval | | route | "why is api slow then scale api to 4" | Multi-tool chain; one aggregate approval | ## Day-2 reads (CLI docs) Deeper guides live in the product repo: investigate, why, timeline, impact, audit, cleanup, search, score, architecture, learn, drift, watch, remember, session, recipes. ## Prompt examples ``` # Kubernetes day-2 kprompt "list deployments" kprompt "how many nodes are in the cluster" kprompt "scale api to 3" -n staging kprompt "rollback payment-api" --approve --wait kprompt "explain why redis is crashing" kprompt "check cluster drift" kprompt "learn my cluster" # Observability kprompt "why is my api slow?" -n production kprompt "trace payment request" kprompt "show dashboard" # North-star reports kprompt "optimize my cluster" kprompt "show service dependency graph" # Ecosystem kprompt "install redis" -n cache kprompt "show gitops sync status" kprompt "provision a postgres database" # Multi-tool route (one plan, one approval for mutating chains) kprompt "why is api slow then scale api to 4" # Not supported — provision a new cluster elsewhere first # kprompt "create a kind cluster" → unknown intent ``` ## Flags | Flag | Description | | --- | --- | | --approve | Apply without interactive confirmation (primary CI flag; also history clear) | | --wait | After apply, wait for Deployment rollout or Workflow/PipelineRun terminal phase | | --timeout | Timeout for --wait (default 5m) | | --output / -o | text (default) or json (PlanResult) | | --theme | auto, dracula, nord, gruvbox, mono, or none | | --provider | LLM provider id | | --model | Model id | | --context | kubeconfig context | | --contexts | comma-separated contexts for read fan-out / per-context mutate (aliases ok) | | --approve-each-context | Apply a mutating plan to every --contexts entry (explicit; not implied by --approve) | | -n / --namespace | Namespace (wins over prompt phrases) | | --open | With login: open the browser for device approval | Interactive confirms use Apply …? [y/N]. Full vocabulary (including rare phrase gates): see CLI docs/approval.md on GitHub. ## Subcommands - kprompt init / demo / doctor / advanced - kprompt config / config set … / config alias set|unset - kprompt contexts / contexts --check / contexts --json - kprompt history / history rerun [n] / history clear [--approve] - kprompt tools - kprompt setup — dry-run / approve-gated host+cluster bootstrap (see Setup docs) - kprompt doctor - kprompt learn — detect cluster tools, save local profile - kprompt agent run / agent list — Observe bridge on laptop or fleet inventory - kprompt run listen — Team app /run CLI bridge - kprompt dash — local read-only cluster UI (requires kprompt-dash on PATH; not a Lens replacement) - kprompt login / login --open / logout / whoami - kprompt policy / policy pull - kprompt secrets pull - kprompt version Bootstrap honesty (what setup installs / does not): Setup bootstrap. Team bridge: App runs & CLI bridge. ## Context aliases Map short names to kubeconfig contexts. Optional require_alias_match refuses mutating apply when kubectl’s current-context does not match the resolved target (wrong-cluster guard). Inventory: kprompt contexts. Read fan-out: --contexts or “across staging and prod” (get/list/explain/logs/describe/optimize). Multi-context mutate asks per context; plain --approve is refused — use interactive confirms or --approve-each-context. PlanResult includes cluster_context on the document and each action; fleet optimize adds fleetSummary. ``` kprompt config alias set prod gke_myproj_us-central1_prod kprompt config alias set staging kind-staging kprompt contexts kprompt --contexts staging,prod "list deployments" kprompt --contexts staging,prod "optimize my cluster" kprompt "list pods across staging and prod" kprompt --contexts staging,prod "scale api to 3" kprompt --contexts staging,prod --approve-each-context "scale api to 3" kprompt --context prod "list deployments" kprompt config set require_alias_match true ``` For the local dash quickstart and security defaults, see the Local cluster dash docs. Full multi-context honesty (what is / is not): Multi-cluster. --- # Local cluster dash URL: https://kprompt.ai/docs/dash kprompt-dash is a simple localhost, read-only cluster inventory — see the cluster, then hand off to kprompt for plan → approve → apply. Not a Lens or Headlamp replacement. kprompt-dash is an optional OSS companion binary. It binds to 127.0.0.1 by default, uses your kubeconfig like kubectl, and stays read-only. Mutations remain in the CLI plan → approve loop. ## Install & run ``` go install github.com/kprompt/kprompt-dash/cmd/kprompt-dash@latest kprompt dash # or: kprompt-dash -open ``` Opens http://127.0.0.1:7474 with Cluster, Nodes, Deployments, ReplicaSets, and Pods — plus detail (events / short logs) and copyable kprompt prompt handoff. ## What it is not - Not a hosted multi-tenant dashboard on app.kprompt.ai - Not in-browser mutate / apply - Not a full CRD / RBAC / Helm explorer - Not Lens or Headlamp parity ## Security - No HTTP authentication — anyone who can reach the port shares your kube privileges - Default listen address is loopback only - Non-loopback binds require an explicit -allow-remote flag --- # Multi-cluster URL: https://kprompt.ai/docs/multi-cluster Laptop-local multi-context: aliases, read fan-out, per-context mutate safety, fleet optimize. Not a hosted Lens/fleet SaaS — kubeconfig never leaves your machine. kprompt’s multi-cluster story is laptop-local: aliases and explicit fan-out over your kubeconfig contexts. Credentials stay on the device. The optional Team control plane may later store metadata only (display name, alias, which enrolled CLI can reach a cluster) — never kubeconfig upload. ## Inventory & aliases ``` kprompt contexts kprompt contexts --check kprompt config alias set prod gke_myproj_us-central1_prod kprompt --context prod "list deployments" kprompt config set require_alias_match true ``` ## Read fan-out Opt-in only — never “all contexts” by default. Supported: get/list, explain, logs, describe, optimize. JSON kind MultiContextResult includes per-context steps and cluster_context; optimize adds fleetSummary. ``` kprompt --contexts staging,prod "list deployments" kprompt "list pods across staging and prod" kprompt --contexts staging,prod "optimize my cluster" ``` ## Mutate safety - Interactive: confirm each context separately - Plain --approve across multiple contexts is refused - --approve-each-context is the explicit multi-apply escape hatch ``` kprompt --contexts staging,prod "scale api to 3" kprompt --contexts staging,prod --approve-each-context "scale api to 3" ``` ## What this is not - Not uploading kubeconfigs to api.kprompt.ai or app.kprompt.ai - Not a hosted live multi-cluster browser (Lens/Headlamp clone) - Not silent --approve across every context - Not an always-on in-cluster multi-cluster agent - Not a replacement for kprompt-dash’s single-cluster localhost inventory --- # Terminal themes URL: https://kprompt.ai/docs/themes Choose readable semantic colors for kprompt plans, risks, findings, and tables. CLI themes style semantic output such as headings, success, warnings, denied risks, resource names, and muted details. They do not change planning or safety behavior. ## Built-in themes | Theme | Use | | --- | --- | | auto | Compatible terminal colors; the default | | dracula | Dracula true-color palette | | nord | Nord true-color palette | | gruvbox | Gruvbox true-color palette | | mono | Bold and dim structure without color | | none | Plain output with all ANSI styling disabled | ## Select a theme ``` # One command kprompt --theme dracula "list deployments" # Persist the default kprompt config set theme nord # Environment override when no flag/config value is set export KPROMPT_THEME=gruvbox ``` ## TTY and color behavior - Color is enabled only for terminal output by default - Any non-empty NO_COLOR disables ANSI styling - KPROMPT_FORCE_COLOR=1 forces styling for ANSI-aware pipes or captures - JSON output remains machine-readable; never force color into JSON consumers - An unknown theme safely falls back to auto --- # Integrations URL: https://kprompt.ai/docs/integrations Use Helm, Argo, Prometheus, OTel, Grafana, Tekton, KEDA, Istio, Crossplane, and GitOps through detected tools and real APIs. kprompt orchestrates integrations; it does not replace them. Run kprompt tools to see what is installed or configured. Missing Helm / Argo / Prometheus can be planned with kprompt setup (approve-gated). Mutating operations still pass through plan, safety, and approval. ``` kprompt tools kprompt setup --dry-run ``` ## Generic Kubernetes reads Get/list any discoverable built-in or CRD via discovery and the dynamic client. Cluster-scoped resources (Node) ignore namespace; Secrets use the same table path (type + key count). Authorization is your kubeconfig RBAC. ``` kprompt "how many nodes are in the cluster" kprompt "list configmaps" -n default kprompt "list widgets.example.com" -n demo ``` ## Helm Install and upgrade plans call the Helm CLI and surface template/dry-run previews. Helm must be available on PATH. Uninstall remains wipe-class and receives stricter safety treatment. ``` kprompt "install redis" -n cache kprompt "upgrade prometheus chart" -n monitoring ``` ## Argo Workflows kprompt detects the Workflow CRD, generates a reviewable manifest, submits it with the Kubernetes dynamic client, and can report or wait for terminal status. ``` kprompt "train a yolov11 model" kprompt "train a yolov11 model" --approve --wait kprompt "get workflow train-yolov11" ``` ## Prometheus Performance explain is read-only. It uses bounded instant/range queries to inspect CPU, memory, p95 latency, replica, and HPA signals for a workload. ``` kprompt config set tools.prometheus.url http://prometheus.monitoring:9090 kprompt "why is my api slow?" -n production ``` ## OpenTelemetry (Jaeger / Tempo) Trace intents search the configured Jaeger or Tempo backend, print a span tree, and narrate bottleneck spans when present. Deep dive: kprompt + OpenTelemetry. ``` kprompt config set tools.otel.endpoint http://tempo.monitoring:3200 kprompt config set tools.otel.backend tempo kprompt "trace payment request" ``` ## Grafana Dashboard intents search Grafana and summarize panel metadata (read-only). Configure URL and API token via tools.grafana.* or environment variables. ``` kprompt config set tools.grafana.url https://grafana.example kprompt "show payments dashboard" ``` ## Optimize & service graph Optimize is a read-only cluster report (idle workloads, rightsizing, HPA hints). Optional follow-up scale/patch plans still require their own approval. Service graphs build from Kubernetes Services/Endpoints and can add OTel call edges when configured. Walkthrough: optimize my cluster. ``` kprompt "optimize my cluster" kprompt "show service dependency graph" kprompt "show service dependency graph for payments" ``` ## Tekton Tekton PipelineRuns generate as reviewable CRs before submit. Missing Tekton CRDs fail clear — kprompt does not invent a pipeline engine. ``` kprompt "run the build pipeline" kprompt "create a CI pipeline" ``` ## KEDA Event-driven scale and scale-to-zero map to KEDA ScaledObjects. The CR is planned first; apply still needs approval. ``` kprompt "autoscale api with KEDA to zero when idle" ``` ## Istio Istio is read-first: VirtualService traffic and canary summaries. kprompt does not claim write canaries or mesh install. ``` kprompt "show traffic for checkout" kprompt "show virtualservice for payments" ``` ## Crossplane Cloud claims via Crossplane CRDs are RiskHigh and need strong approval. Prefer an existing claim over inventing a cloud account. ``` kprompt "provision a postgres database" ``` ## GitOps (Flux / Argo CD) Status and health are read-only. Sync / promote / rollback paths require approval and apply through the real Flux Kustomization or Argo CD Application APIs. Deep dive: kprompt + Argo CD. ``` kprompt "show gitops sync status" kprompt "sync the payments application" --approve ``` ## Multi-tool routes Chain steps across backends with then / and then. Mutating chains show one aggregate plan and ask for a single approval. ``` kprompt "why is api slow then scale api to 4" kprompt "show gitops sync status then sync payments" --approve ``` --- # Setup bootstrap URL: https://kprompt.ai/docs/setup Honest bootstrap for missing Helm / Argo / Prometheus — dry-run by default, approve-gated apply. What kprompt setup installs and what it never does. kprompt setup turns tools.Detect gaps into a reviewable plan. Default is dry-run. Host and cluster installs need --approve or interactive confirm — never silent. Full flag reference lives in the product docs on GitHub. ``` kprompt tools kprompt setup kprompt setup --profile minimal --approve kprompt setup --profile platform --only prometheus --approve ``` ## Profiles | Profile | Components | Notes | | --- | --- | --- | | minimal | Helm | Host lane only | | platform (default) | Helm + Argo Workflows + Prometheus stack | Approve-gated cluster installs | | full | platform + Grafana + OTel URL steps | Config lane is hints only — never auto-writes ~/.kprompt/config | ## What setup installs (with --approve) - Helm CLI on PATH via Homebrew or get-helm-3 (OS matrix in product docs) - Argo Workflows controller manifests into namespace argo (pinned release YAML) - kube-prometheus-stack via Helm into namespace monitoring (release kprompt-prom) ## What setup does not do - Does not create clusters (kind / minikube / EKS / GKE provisioners) - Does not install Tekton, KEDA, Istio, Linkerd, Crossplane, Flux, or Argo CD - Does not replace Helmfile, Terraform, or Crossplane as a general installer - Does not auto-write Grafana / OpenTelemetry URLs (print config set hints only) - Does not wipe or uninstall — wipe-class helm uninstall / namespace delete stay hard-denied - Does not run in the background or install while you optimize ## Missing-tool hints When kprompt tools or a prompt path finds Helm, Argo Workflows, or Prometheus missing, hints point at kprompt setup with the right --profile / --only. Prefer pointing at an existing Prometheus URL when you already have one. Safety model is unchanged: cluster installs are plan → safety → approve → apply, same as any other mutate. Already have Prometheus / Grafana / OTel? Prefer bind-over-install — see Adopt (15 min). --- # Architecture URL: https://kprompt.ai/docs/architecture How kprompt works as an AI Runtime: planning pipeline, PlanResult contract, AI SRE CLI vs Observe agent, modes, and honesty boundaries — in diagrams. ## AI Runtime Developer → Natural Language → Planning Engine → Execution Graph → Policy Validation → Kubernetes → Continuous Observation → Learning. kprompt is a runtime over live cluster state — not a dashboard, not a workflow product, and not a free-form chat REPL. ## PlanResult contract Prompt → Intent → Plan → Safety → Approve → Apply. Natural language becomes a typed PlanResult with actions, risk, and blast radius. Wipe-class intents are hard-denied. Mutations need TTY y/N or --approve. ## AI SRE dual path On-demand CLI packs (investigate, why, timeline, impact, audit, drift) and the optional in-cluster Observe / Namespace Agent share internal/incident contracts. CLI is reactive; agent is always-on. Neither silently mutates. ## Observe agent pipeline Watch → Normalize → Deduplicate → Incident → Context → Analyze → Confidence/severity gate → Notify (Slack/webhook). Namespace Role RBAC. LLM batched by open Incident. Full install: Observe agent. ## Modes - CLI — PlanResult after approve - Observe — Incident/AgentAlert; never mutates - Namespace Agent — InvestigationReport v2; propose-first - Coordinator — cross-ns handoff + optional kube probe + Shared Knowledge + proactive tick + blast-radius (opt-in mesh/OTel) + durable outcome ring; mutate off - Autopilot — allowlisted propose; apply only with policyAuto ## Honesty boundaries - No silent LLM-said-so remediations - No “AI automatically fixes everything” claims - No cluster-wide god-mode SA on every namespace agent - Missing Prom/OTel/GitOps backends degrade — not invented - Memory/patterns are not sole proof of root cause - Knowledge Graph = service + Ingress/PVC + Secret/CM name refs + impact + memory deps; topology closure (ExternalName / env-host / EndpointSlice / NetworkPolicy) shipped in v0.10.0 (ADR-0023) — Secret values stay out; Simulation MVP = change preview (docs/simulation) - Not K8sGPT fleet scanner or Kagent multi-agent parity --- # Observe agent URL: https://kprompt.ai/docs/agent Optional namespace-scoped runtime agent (v0.5): Helm/Operator, Role RBAC, memory & patterns. First in-cluster surface of the AI Runtime. Autopilot is propose-only (ADR-0015). Shipped in kprompt v0.5+. The laptop CLI stays a single binary with no required daemon. Separately, you can opt into an in-cluster Observe agent — the first AI Runtime surface inside Kubernetes — that watches one namespace, correlates Incidents, optionally calls an LLM, and notifies Slack or a webhook. Fleet inventory: `kprompt agent list -A` (KpromptAgent CRs + labeled Deployments). The thin Coordinator fan-in (handoff + optional read-only probe + merge + Shared Knowledge via /v1/knowledge, ConfigMap-durable by default in Helm) also ships. Continuous Coordinator + Incident→PlanResult bridge + closed Learn + durable cluster memory shipped in v0.10.0 as the Runtime closure pack (ADR-0023) — default stays propose-only, never silent auto-heal. Pipeline and AI Runtime dual-path diagrams: Architecture. ## Observe by default — Autopilot propose-only - Observe Mode never applies, patches, or deletes workload objects - Autopilot MVP (--autopilot-propose) emits PlanResult-shaped proposals + audit; Applied stays false - Policy allowlist + ADR-0015 gates required before any future apply executor - Recommendations may suggest a fix for a human to approve on the CLI Full Autopilot contract: ADR-0015. ## vs K8sGPT and Kagent | Tool | Job | kprompt Observe | | --- | --- | --- | | K8sGPT | On-demand / scheduled analyzer (scan → explain) | Always-on watch → correlated Incident → confidence-gated alert — not a fleet scanner | | Kagent | In-cluster multi-agent framework | One kprompt-native Observe pipeline; not a general agent platform | | kprompt CLI | Reactive plan → approve → apply | Agent is optional; CLI needs no daemon | ## RBAC (honest) - Default: Role + RoleBinding in one namespace (get/list/watch) — not ClusterRole - Secrets watch is off by default; when enabled, metadata only (never values) - You own the ServiceAccount blast radius you deploy ## LLM cost - No LLM call on every raw API event — batch by open Incident - Severity + confidence gate before Slack/webhook (defaults: medium / 0.7) - Use --heuristic for demos; mount provider keys via Secret only ## Laptop demo: watching… vs emit-initial agent run is a live watch. Without new Pod/Event traffic it only prints watching…. Already-broken workloads may stay quiet until the next BackOff. For demos, emit current state and stay offline ($0): ``` kprompt agent run -n payments \ --emit-initial \ --analyze --fetch-logs --health --heuristic \ --memory --patterns --autopilot-propose ``` | Flag | Effect | | --- | --- | | --emit-initial | Treat current Pods/Events as Added before the live stream | | --heuristic | Deterministic analysis — no LLM key / no cloud spend | | --health | Namespace score from open incidents + pod readiness/restarts | | --analyze | Gated AgentAlert (heuristic or LLM) | Health vs incidents: ready=4/5 can drop the score while open=0 if the correlator has not opened an Incident yet (needs problem Events such as BackOff). Score ≠ alert. Break something with kprompt-examples, then re-run with --emit-initial. ## Namespace memory - Optional --memory discovers Redis/Kafka/Postgres-style deps from Services/Deployments - Stores facts locally (~/.config/kprompt/memory) or in-cluster ConfigMap — never uploaded to api.kprompt.ai by default - Relevant facts inject into AgentContext for the analyzer - Optional --patterns learns signatures and boosts confidence on “seen before” (never mutates) - Optional --autopilot-propose emits allowlisted AutopilotProposal (propose-only; ADR-0015) ## Operator (optional) kprompt agent operator reconciles KpromptAgent CRs into Observe agent Deployments (ServiceAccount + Role + RoleBinding + Deployment). Helm chart: charts/kprompt-operator. Prefer the manual kprompt-agent chart when you do not want a ClusterRole for the operator SA. Autopilot propose is a CLI flag on the agent binary — not silent mutate. ## Helm install (Secret + chart (image tag = release)) ``` kubectl -n payments create secret generic kprompt-agent \ --from-literal=OPENAI_API_KEY="$OPENAI_API_KEY" helm upgrade --install kprompt-agent ./charts/kprompt-agent \ -n payments --create-namespace \ --set image.tag=0.9.0 ``` Laptop smoke: kprompt agent run -n payments --analyze --fetch-logs --health --heuristic. Add --memory, --patterns, or --autopilot-propose as needed. Full flags in the repo agent doc. ## Demo cluster Need a payments namespace that actually misbehaves? kprompt-examples spins up kind with seven failure scenarios (crashloop, image pull, OOM, stalled rollout, unbound PVC, failing CronJob, missing dependency). Each README states what the agent should conclude — so a demo has a right answer. (kind + crashloop, then Observe agent (heuristic = offline)) ``` git clone https://github.com/kprompt/kprompt-examples.git cd kprompt-examples make up make break SCENARIO=01-crashloop make verify kprompt agent run -n payments --analyze --health --heuristic ``` --- # Roadmap & vision URL: https://kprompt.ai/docs/roadmap Where kprompt is headed as an AI Runtime for Kubernetes: agents, trust loops, multi-cluster, and what stays out of scope. Honest shipped vs exploring. ## Positioning kprompt is The AI Runtime for Kubernetes — an AI-powered runtime that understands your Kubernetes environment and turns intent into context-aware operations, investigations, and recommendations. Today the laptop path is an intent compiler: natural language → reviewable PlanResult → approve → apply. Investigation and AI SRE packs (investigate / why / timeline / impact) ship alongside operate / analyze / recommend. The in-cluster path starts with Observe and includes Namespace Agents, Coordinator correlation, topology Knowledge Graph edges, and durable incident memory (v0.10 Runtime closure) — while keeping the same approval contract. Not a free-form chat REPL, not a silent analyzer daemon, not a monitoring-only AIOps product, not a hosted fleet scanner. Experienced Kubernetes engineers remain a target: augment expertise by reducing context they must gather manually. Read Building AI SRE in Public, Intent compiler, not chat, Context engineering, Kubernetes AI tools compared, and Beyond AI kubectl for public positioning. ## Shipped now - Plan → safety → approve → apply (deploy, scale, rollback, named delete) - Deep explain, logs, describe, discovery-backed get/list - investigate / why / timeline / impact — Investigation JSON (ADR-0014) - Blast-radius preview on mutating plans; post-apply verify with --wait - Incident suggest packs: OOM memory bump, CrashLoop rollback (prior RS; skipped when OOM also present), ImagePull patch when the prompt names a replacement tag (auth failures → pull-secret guidance), probe timing relax — on Deployment / StatefulSet / DaemonSet where applicable — plus scheduling/PVC guidance; still approve-gated - Audit harden plan: approve-gated privilege-removal (privileged / allowPrivilegeEscalation) on Deployments, StatefulSets, and DaemonSets; invented-value fixes stay guidance - Cleanup delete plans: approve-gated removal of stale Jobs / superseded ReplicaSets; optional ConfigMap/Secret orphan deletes only when the prompt confirms orphans (stricter DELETE-ORPHANS / confirm_orphans gate) - Helm, Argo Workflows, Prometheus, OTel, Grafana, multi-tool routes - Tekton, KEDA, Istio (read-first), Crossplane, Flux/Argo CD GitOps - Optimize-cluster report (idle / rightsizing / HPA) and service dependency graph - Cost Intelligence MVP: labeled $/carbon notes on idle + rightsizing-lower when Prometheus is available (docs/optimize) — not a cloud invoice - Simulation MVP: mutating plans preview with blastRadius; impact/who-consumes + Helm dry-run (docs/simulation) — not a sandbox cluster - Context aliases, doctor, Homebrew, optional Team login / policy / audit - Local read-only inventory via kprompt dash (localhost) - Optional Observe agent (Helm): namespace watch → Incident → gated Slack/webhook — no silent Autopilot mutate - Namespace Agent fleet inventory: kprompt agent list -A (docs/agent-fleet) - Namespace Agent intelligence brief: kprompt agent status -n (docs/agent-status) - Optional Operator: KpromptAgent CR → Observe agent Deployment - Autopilot propose-only MVP (--autopilot-propose) under ADR-0015; gated policyAuto apply code path exists (opt-in, not default) - AI Runtime closure pack shipped in v0.10.0 (ADR-0023): closed Learn · Autopilot product path · continuous Coordinator · topology KG · Incident→PlanResult · durable cluster memory — default stays propose-only - GitHub Integration MVP: --gitops opens a GitHub PR instead of cluster apply (docs/gitops-pr); Team SCM A-061…A-069 shipped (Setup URL + App JWT + /ci viewer + Checks annotate upsert) Full integration detail lives on Integrations — not duplicated here. Observe agent install and honesty notes: Observe agent. ## Shipped — AI Runtime closure (v0.10.0) The committed product pack (ADR-0023) landed in v0.10.0 — the motto loop is now real in-cluster, not only on a laptop. Default stays Observe + propose-only Autopilot; never silent auto-heal; Secret values stay out of the Knowledge Graph. - Closed Learn loop — apply/resolve/FP outcomes reshape the next PlanResult ranking (evidence-not-proof caps stay) - Policy-gated Autopilot apply (product path) — Helm-first policyAuto + post-apply verify gate + audit; default remains propose-only - Incident → PlanResult bridge — durable in-cluster proposal; approve via CLI or Slack without laptop re-compile - Topology Knowledge Graph — ExternalName / env-host / EndpointSlice / NetworkPolicy edges into impact (never Secret values) - Continuous Coordinator — proactive correlation tick + optional mesh/OTel blast edges; Coordinator still does not mutate - Durable cluster memory — cross-ns Coordinator outcome ring + fleet read bias Learn safely (evidence-not-proof); offline agent memory export ## Building next — trust & AI SRE These deepen “think about the cluster” without leaving the plan/approve loop. Treat as in progress — not a public ship date. - Deeper CrashLoop recipes (non-Deployment rollbacks, exit-code specific fixes) - audit non-privilege harden fixes (runAsNonRoot, resource requests) with safe defaults - drift — live vs Git desired-state reports - Deeper continuous multi-agent reasoning (beyond Namespace Agent + Coordinator today) - Richer Prom/OTel/mesh hops on investigate / timeline when backends are present ## Exploring later - Slack interface (bidirectional): ask status / why / what broke in-channel from the Observe agent — read-only answers; mutating plans still plan → approve (Slack `approve ` shipped in v0.10.0 under policyAuto, RT-008) - Proactive local watch (opt-in laptop): signal → “latency up; investigate?” — never auto-mutate - Local remember / session digests (facts stay on your machine by default) - Multi-cluster: richer org registry metadata without uploading kubeconfig (contexts inventory + read fan-out already ship) - Team web polish on app.kprompt.ai (policy, audit, Insights) — CLI stays free; nothing to buy today - Workflow recipe packs (harden production, Ingress → Gateway API) as curated plan chains - Sandbox / chaos / capacity what-if Simulation lab (today’s Simulation MVP stays change preview) - Interactive Team topology / timeline viewers beyond CLI artifacts ## What we will not do - Silent apply across clusters from one --approve - Upload kubeconfig / cluster credentials to the control plane - Replace Lens/Headlamp as a hosted live cluster browser - Compete on free-form agent chat with kubectl-ai - Claim K8sGPT analyzer parity as a fleet scanner - Ship Autopilot mutate without ADR-0015 + PlanResult + policy gates - Index Secret values into a Knowledge Graph CMDB - Pretend Observe agent is Kagent feature parity ## Shape priorities Star issues and PRs on GitHub. The CLI stays Apache-2.0 and experimental — review every plan before apply. Start with Quickstart when you are ready to try it. --- # Team enrollment URL: https://kprompt.ai/docs/team Optional CLI login for org policy sync and audit push. Free CLI stays free; enrollment does not change behavior until you enroll. Team enrollment is opt-in. Until you run kprompt login, the CLI behaves as Free: local safety only, no control-plane calls. There is no public buy/signup CTA on this site — enrollment is for orgs that already have Team access. ## Login ``` kprompt login # device code → approve at app.kprompt.ai/connect kprompt login --open # also open the browser kprompt whoami # org + member kprompt logout # revoke token + clear credentials/policy ``` The kp_… token is stored only in ~/.kprompt/credentials.yaml (mode 0600), never in config.yaml. Override the API with KPROMPT_API_URL / KPROMPT_API_TOKEN when needed. ## App /run jobs need a CLI bridge Prompts composed at app.kprompt.ai/run stay queued until an enrolled laptop runs kprompt run listen. The control plane never holds kubeconfig. Full walkthrough: App runs & CLI bridge. ## Org policy Pull caches org policy locally. Cached policy only tightens local hard-denies (namespace allow/deny, max risk, deny intents, require approve) — it never relaxes them. ``` kprompt policy pull # fetch org policy → ~/.kprompt/policy.yaml kprompt policy # show cached policy ``` ## Audit push When enrolled, each plan best-effort pushes an audit event (planned / denied / applied) to the control plane. Failures print a warning and never fail the local command. Disable with KPROMPT_DISABLE_AUDIT=1. ## What stays local - Kubeconfig, cluster traffic, and LLM keys stay on your machine - Audit payloads omit manifests and secrets - History remains local (~/.kprompt/history.jsonl) - You can logout anytime and return to Free CLI behavior Next: App runs & CLI bridge — login → Connect CLI → queue a prompt → run listen → why jobs stay queued. --- # App runs & CLI bridge URL: https://kprompt.ai/docs/runs How app.kprompt.ai/run works: device login, Connect CLI, kprompt run listen, why jobs stay queued, approve modes, and troubleshooting. No cluster credentials in the control plane. Team /run lets you compose a prompt in the browser. Execution always happens on an enrolled laptop with local kubeconfig — never inside api.kprompt.ai. If nobody is running kprompt run listen, the job stays queued forever. That is intentional (ADR-0021), not a hang. ## Flow at a glance (Browser compose → queue → local bridge → PlanResult) ``` You (browser) app.kprompt.ai/run → POST /v1/runs (status: queued) Laptop bridge kprompt run listen → POST /v1/runs/claim local plan pipeline → kubeconfig stays on the laptop POST /v1/runs/{id}/result → app shows plan / awaiting_approve ``` - Control plane stores prompt + status + PlanResult summary — never kubeconfig or cluster tokens - Same local safety + cached org policy as normal CLI plans - Mutations never auto-apply from the plane; plan_only never applies; require_approve waits for Approve in the app ## 1. Enroll the CLI (device login) On the laptop that can reach the cluster: ``` kprompt login # prints a user code + Connect URL kprompt login --open # also opens the browser kprompt whoami # confirm org + member ``` - CLI shows a short user code (for example WXYZ-ABCD) and a URL under app.kprompt.ai/connect - Sign in to the Team app in the browser if needed - Open Connect CLI, enter or confirm the user code, Approve - CLI receives a kp_… token → ~/.kprompt/credentials.yaml (mode 0600) If whoami or doctor shows Team enrollment Forbidden, run kprompt logout then kprompt login again. See Team enrollment for policy and audit details. ## 2. Start the bridge worker Leave this running in a terminal while you use /run in the app: ``` kprompt run listen # optional: # kprompt run listen --interval 3s --worker-label laptop-muhtalip ``` The worker polls POST /v1/runs/claim, runs the same plan pipeline as the CLI (never auto-applies), and posts the result. One active claim per worker; kubeconfig and LLM keys stay local. ## 3. Compose and queue in the app - Open app.kprompt.ai/run - Enter the prompt (for example deploy redis), optional namespace and context hint - Pick approve_mode: plan_only (never apply), require_approve (pause for Approve/Deny), or auto_if_policy_allows (still subject to hard denies) - Queue run — status starts as queued The /run page itself says: Jobs stay queued until claimed. The empty-state copy points at kprompt login && kprompt run listen (also linked from Connect CLI). ## Why status stays queued queued means the job is waiting for a bridge. The app does not browse or mutate the live cluster from the browser. Common causes: | Symptom | Likely cause | Fix | | --- | --- | --- | | Stuck on queued | No kprompt run listen on an enrolled laptop | Start the bridge; keep the terminal open | | listen errors / claim fails | Stale or missing kp_… token | kprompt logout && kprompt login && kprompt whoami | | Wrong cluster / context | context_hint does not match a local kubeconfig context or alias | Fix hint, or kprompt config alias set …; check kubectl config get-contexts | | Doctor: Team enrollment FAIL | API Forbidden or expired device session | Re-login; confirm org membership in the app | ## Approve modes | Mode | Bridge behavior | | --- | --- | | plan_only | Plans and posts PlanResult; never applies (including Replay / drill) | | require_approve | Mutating plans pause at awaiting_approve until Approve in the app; then the bridge may apply | | auto_if_policy_allows | May apply only when org policy allows; hard denies and wipe-class still block | ## Replay / drill From a run or audit detail, Queue drill run re-queues the same prompt as plan_only with a staging-ish context hint. Prod-like hints are blocked. Still needs a live run listen worker — drill is not an in-browser executor. Gotcha: drill often sets context_hint to staging. If that name is not a local kubeconfig context or alias, the bridge fails after claim. Map it with kprompt config alias set staging kind-kprompt-demo, or queue a fresh run with an empty / real context hint. ## Why status is failed (after claim) queued → running → failed means the laptop claimed the job but the local plan pipeline errored before a PlanResult existed. Check the red error field on the run detail page (authoritative), the bridge terminal (Posted run_… → failed: … on recent builds), and kprompt doctor on the same machine as run listen. | Error (typical) | Cause | Fix | | --- | --- | --- | | missing API key / provider | No BYOK key for the configured provider | export KPROMPT_GEMINI_API_KEY=… (or use Ollama) · or kprompt secrets pull | | kube context "staging" not found | Drill / compose hint ≠ local contexts | Empty hint, real context name, or config alias set | | 429 / quota exceeded | Gemini (or other) free-tier limit | Wait for reset, switch model, or use Ollama — see Providers | | Org policy max_risk … exceeds | Plan risk above cached org ceiling | Soften org max_risk, or use a read-only / lower-risk prompt | | unknown intent | Prompt outside supported ops (e.g. create a cluster) | Rephrase to a supported intent — see Commands | Providers details for Gemini free tier: Providers. Capability map: Commands. (Local sanity check (same kube + provider as the bridge)) ``` kprompt doctor kprompt --context kind-kprompt-demo "list pods" -n default # then re-queue in the app and keep: kprompt run listen ``` ## What this is not - Not a hosted cluster browser (Lens-style live inventory in the plane) - Not the in-cluster Observe agent (Helm kprompt-agent) — that watches namespaces; this worker is laptop-side Team jobs - Not silent Autopilot apply — mutations stay gated Related: Team enrollment · Safety · Observe agent. --- # Safety URL: https://kprompt.ai/docs/safety How kprompt gates cluster mutations: prompt-level hard denies, plan risk levels, explicit approval, and tighten-only org policy. Safety features reduce risk; they do not make kprompt safe for unattended production use. The product is experimental. Always review the plan. Skip --approve until you understand the proposed actions. Every mutating plan is risk-evaluated before apply. On a TTY, kprompt asks y/N unless you pass --approve. Read-only intents (get, list, explain, investigate, why, timeline, impact, audit, cleanup, search, score, architecture, learn, drift, logs, describe, performance, trace, dashboard, optimize, graph, Istio traffic, GitOps status) do not require approval. ## Where the checks run The pipeline is prompt → intent → plan → safety → approval → executor → Kubernetes. Safety runs at two distinct points, which is why some prompts never reach the model at all. | Stage | What it checks | Effect | | --- | --- | --- | | Prompt check | Destructive natural-language patterns | Denied before any LLM call — no token spend | | Plan evaluation | Actions, resource kinds, names, integration rules | Assigns risk or denies the plan outright | | Org policy overlay | Cached Team policy, when enrolled | May only tighten the local verdict | | Approval | TTY confirmation or explicit --approve | Last gate before the executor runs | ## Hard denies Some prompts are refused by pattern before the model is called: wiping or destroying the cluster, deleting everything or all namespaces, and deleting a namespace by name. These are cheap, deterministic refusals rather than a judgement call left to the LLM. (Refused before any LLM spend) ``` $ kprompt "delete everything in the cluster" 🚨 Intent: destructive cluster operation 🛡️ Safe execution: denied 😅 Your cluster lives another day Next: kprompt "delete deployment " -n ``` Wipe-class denials rotate a small flavor pack of punchlines (stable per prompt) and always append a Next remediation line with a named-target example. The punchline is branding; the Next line is the teachable path. | Plan-level rule | Why | | --- | --- | | Delete must target Pod, Deployment, or Service | Any other kind is refused rather than guessed at | | Delete must name one resource | Names like *, all, everything, or --all are refused as unscoped | | Delete without a resource kind is refused | An ambiguous target is never resolved for you | | Namespace deletion is always refused | Blast radius is too large for a compiled plan | (Example plan-level deny) ``` kprompt "delete all pods in production" # Risk: denied — name a single resource ``` ## Risk levels Plans surface one of four verdicts. Denied plans never apply. Medium and high plans still need explicit approval — risk is information for your review, not permission to skip it. | Risk | Typical intents | Approval | | --- | --- | --- | | low | Reads, explain, investigate, learn, drift, optimize reports, service graphs, GitOps status | None required | | medium | Scale, deploy, install, upgrade, rollback, patch, workflows, Tekton, KEDA, GitOps sync | TTY y/N or --approve | | high | Named deletes, Crossplane cloud claims, unrecognised intents | Explicit approval; Crossplane needs strong approval | | denied | Hard-deny prompts and unsafe plans | Never applies | learn and drift are RiskLow (read-only scans). Optional approve-gated GitOps sync follow-ups from drift are separate KindGitOps plans at medium risk. If an older CLI treated drift as high, upgrade — org max_risk=medium would incorrectly deny those scans. Integration-specific rules layer on top for Helm, Argo Workflows, Tekton, KEDA, Istio, Crossplane, and GitOps, so a risky chart install or a cloud claim is not treated as a generic mutation. Multi-tool mutating routes produce one aggregate plan and a single approval rather than a chain of prompts. ## Diffs and blast radius When a live object already exists, plans include a before→after diff so you review the actual change rather than only the intent summary. That is the difference between approving "scale api to 10" as a sentence and approving it as a concrete replica change on a named Deployment. ## Multiple clusters Fan-out is deliberately asymmetric: reads and optimize rollups can span contexts freely, while mutations cannot be approved for many clusters by accident. --approve never implies cross-context apply; you confirm each context or pass --approve-each-context explicitly. Setting require_alias_match true refuses a mutation unless your kubectl current-context matches the alias you targeted. ## Org policy (when enrolled) A cached Team policy can only tighten local rules — it never loosens a local hard deny. Pull it with kprompt policy pull and inspect it with kprompt policy. | Policy field | Effect | | --- | --- | | max_risk | Denies any plan whose risk exceeds low, medium, or high | | deny_intents | Denies named intents outright | | allow_namespaces | Restricts plans to an allowlist of namespaces | | deny_namespaces | Denies plans targeting listed namespaces | | require_approve | Forces approval for medium risk and above | (Example org deny (max_risk=medium vs a high plan)) ``` kprompt policy # max_risk: medium kprompt "delete deployment redis" -n payments # 🛡️ Org policy max_risk is medium — plan risk high exceeds it ``` When enrolled, each plan also best-effort pushes a planned, denied, or applied audit event to the control plane. Disable it with KPROMPT_DISABLE_AUDIT=1. ## What safety does not do - It does not verify that a plan is correct — only that it is not obviously destructive - It does not replace kubeconfig RBAC; kprompt can only do what your credentials allow - It does not redact Secret values from reads you are already authorised to perform - It does not make --approve in CI equivalent to human review - It does not cover generic mutation of arbitrary resource kinds, which stays out of scope Treat the safety engine as a floor, not a ceiling. The honest limits, including what Autopilot will and will not do, are documented on the roadmap. --- # Providers URL: https://kprompt.ai/docs/providers Local Ollama or LM Studio ($0) or bring your own cloud key: OpenAI, Anthropic, Gemini, Groq, xAI, Mistral, DeepSeek, OpenRouter, Together, Fireworks, Hetzner Inference (experimental), or any OpenAI-compatible gateway. kprompt does not sell API keys. kprompt does not sell API keys. For NL plans use local Ollama ($0, no key) via kprompt init --ollama, or BYOK with kprompt init --provider … plus your own cloud key. Requests go from your machine to that provider; there is no kprompt-hosted inference proxy. With no provider configured, the CLI stays unconfigured (no silent OpenAI default). Provider keys are environment variables only and are never written to the config file. Optional Team kp_… tokens are for org policy/audit, not LLM inference. ## Supported providers | Provider | --provider | Env key(s) | Default model | | --- | --- | --- | --- | | Ollama (local) | ollama | none required — $0 first path | llama3.2 | | LM Studio (local) | lmstudio | none required — $0; server must be running with a model loaded | local-model (must match a loaded model name) | | OpenAI | openai | KPROMPT_OPENAI_API_KEY / OPENAI_API_KEY | gpt-4o-mini | | Anthropic | anthropic | KPROMPT_ANTHROPIC_API_KEY / ANTHROPIC_API_KEY | claude-sonnet-4-6 | | Google Gemini | gemini | KPROMPT_GEMINI_API_KEY / GEMINI_API_KEY / GOOGLE_API_KEY | gemini-3.6-flash | | Groq | groq | KPROMPT_GROQ_API_KEY / GROQ_API_KEY | llama-3.3-70b-versatile | | xAI (Grok) | xai | KPROMPT_XAI_API_KEY / XAI_API_KEY | grok-4.5 | | Cerebras | cerebras | KPROMPT_CEREBRAS_API_KEY / CEREBRAS_API_KEY | gpt-oss-120b | | Mistral | mistral | KPROMPT_MISTRAL_API_KEY / MISTRAL_API_KEY | mistral-small-latest | | DeepSeek | deepseek | KPROMPT_DEEPSEEK_API_KEY / DEEPSEEK_API_KEY | deepseek-chat | | Moonshot (Kimi K3) | moonshot | KPROMPT_MOONSHOT_API_KEY / MOONSHOT_API_KEY | kimi-k3 | | Qwen (DashScope) | qwen | KPROMPT_QWEN_API_KEY / DASHSCOPE_API_KEY / QWEN_API_KEY | qwen-plus | | OpenRouter | openrouter | KPROMPT_OPENROUTER_API_KEY / OPENROUTER_API_KEY | openai/gpt-4o-mini | | Together | together | KPROMPT_TOGETHER_API_KEY / TOGETHER_API_KEY | meta-llama/Llama-3.3-70B-Instruct-Turbo | | Fireworks | fireworks | KPROMPT_FIREWORKS_API_KEY / FIREWORKS_API_KEY | accounts/fireworks/models/llama-v3p3-70b-instruct | | Hetzner Inference | hetzner | KPROMPT_HETZNER_API_KEY / HETZNER_API_KEY | Qwen/Qwen3.6-35B-A3B-FP8 (experimental / free while in beta) | | Azure OpenAI | azure | KPROMPT_AZURE_API_KEY / AZURE_OPENAI_API_KEY / KPROMPT_OPENAI_API_KEY | deployment name (requires base_url) | | OpenAI-compatible | openai-compatible | KPROMPT_OPENAI_API_KEY | requires base_url | Ollama runs locally at http://127.0.0.1:11434/v1 and needs no key — the $0 path for trying kprompt or running it in CI. LM Studio is the same local OpenAI-compatible shape at http://127.0.0.1:1234/v1; start the app, load a model, and pass --model with that model's name. Groq, xAI (Grok), Cerebras, Mistral, DeepSeek, Moonshot (Kimi K3), Qwen (DashScope), OpenRouter, Together, Fireworks, and Hetzner Inference all speak the OpenAI-compatible API. Fireworks model ids are account-scoped (accounts/fireworks/models/…). Hetzner Inference is experimental (free while in beta, no SLA). The qwen preset defaults to the international DashScope endpoint; mainland China keys need KPROMPT_OPENAI_BASE_URL pointed at the CN compatible-mode URL. Azure OpenAI uses the named azure preset with a resource base_url; --model is your deployment name. ## Gemini free tier (honest) AI Studio keys often start on a free tier with daily / per-minute quotas. Exceeding them returns HTTP 429 — Google’s limit, not a kprompt bug. Get a key at aistudio.google.com/apikey. Monitor quotas at ai.dev/rate-limit. ``` export KPROMPT_GEMINI_API_KEY=... kprompt config set provider gemini kprompt config set model gemini-3.6-flash # current GA Flash ``` | Symptom | What to do | | --- | --- | | 429 / generate_content_free_tier_* | Wait for reset, enable billing on that Google project (calls become paid), or switch to Ollama | | 404 model no longer available to new users | Use a current model id (e.g. gemini-3.1-flash-lite / gemini-3.5-flash) — older gemini-2.5-flash-lite may be closed to new keys | | Works in CLI, Team /run fails | Bridge uses the same machine env/secrets — export the key (or secrets pull) where kprompt run listen runs | Prefer Ollama when you want $0 with no cloud quota. Team bridge failures: App runs & CLI bridge. ## How keys are resolved - Ollama and LM Studio need no provider key - The KPROMPT_-prefixed variable is checked first, then the vendor default such as OPENAI_API_KEY - Environment variables always win over keys pulled from a Team org with kprompt secrets pull - ~/.kprompt/config.yaml stores provider, model, namespace, and base_url — never a key - kprompt doctor reports whether a usable key was found without printing its value - Team kp_… tokens from kprompt login are unrelated to LLM provider keys ## Examples ``` # Local Ollama ($0) kprompt --provider ollama --model llama3.2 "list pods" # LM Studio (local $0 — start the server and load a model first) kprompt --provider lmstudio --model "list pods" export KPROMPT_OPENAI_API_KEY=sk-... kprompt "list deployments" export KPROMPT_ANTHROPIC_API_KEY=sk-ant-... kprompt --provider anthropic "explain why api is crashing" export KPROMPT_GEMINI_API_KEY=... kprompt --provider gemini --model gemini-3.6-flash "deploy redis" export KPROMPT_XAI_API_KEY=... kprompt --provider xai "explain why api is crashlooping" export KPROMPT_MOONSHOT_API_KEY=... kprompt --provider moonshot "explain why api is crashlooping" export KPROMPT_QWEN_API_KEY=... kprompt --provider qwen "explain why api is crashlooping" # Hetzner Inference (experimental — free while in beta) export KPROMPT_HETZNER_API_KEY=... kprompt --provider hetzner "list pods" ``` ## Azure OpenAI and custom gateways Azure OpenAI has a named azure preset (still OpenAI-compatible under the hood). Set the resource URL as base_url; --model is the deployment name you created in the portal — not an OpenAI model id. Generic gateways keep using openai-compatible. ``` export KPROMPT_AZURE_API_KEY=... export KPROMPT_OPENAI_BASE_URL=https://YOUR_RESOURCE.openai.azure.com/openai/v1 kprompt --provider azure --model my-gpt4o-deploy "list services" # or any OpenAI-compatible gateway export KPROMPT_OPENAI_API_KEY=... export KPROMPT_OPENAI_BASE_URL=https://gateway.example/v1 kprompt --provider openai-compatible --model gpt-4o-mini "list services" ``` ## Config file (~/.kprompt/config.yaml) ``` provider: ollama model: llama3.2 # provider: gemini # model: gemini-3.6-flash # base_url: https://api.groq.com/openai/v1 # optional override namespace: default ``` (Or set the same values from the CLI) ``` kprompt config set provider ollama kprompt config set model llama3.2 kprompt config ``` ## Choosing a model - Start with local Ollama ($0) for first NL plans — no cloud key to buy - Fast and cheap cloud models handle routine intents like list, scale, and logs well - Reserve a stronger model for explain, investigate, and why prompts that reason across events and logs - Local Ollama models avoid all spend but produce weaker plans on ambiguous prompts - Switch per command with --provider and --model without changing your saved defaults Model choice affects plan quality, never the approval boundary: a weaker model may produce a worse plan, but it still cannot bypass the safety engine or apply without approval. --- # Init URL: https://kprompt.ai/docs/init Day-0 kprompt init configures your LLM provider for natural-language plans — Ollama ($0) or BYOK. Does not create clusters or enroll Team. After install, bare kprompt prints a readiness coach. With no provider in config and no --provider flag, the CLI is unconfigured (it does not silently default to OpenAI). Run kprompt init once, then doctor and your first read prompt. ## Quick path ``` # $0 local LLM ollama serve && ollama pull llama3.2 kprompt init --ollama # BYOK kprompt init --provider openai export KPROMPT_OPENAI_API_KEY=sk-... kprompt doctor kprompt "list pods" ``` ## Flags | Flag | Meaning | | --- | --- | | --ollama | Set provider to ollama (no API key) | | --provider | Named preset (openai, anthropic, gemini, …) | | --model | Override preset default model | | --context | Persist a kubeconfig context | | --dry-run | Print what would be written; do not save | Non-interactive shells require --ollama or --provider. Interactive TTY with bare kprompt init walks provider → model → optional context. ## What it is not - Does not create kind/minikube clusters - Does not run kprompt setup (Helm / Argo / Prom bootstrap) - Does not enroll Team (kprompt login) Full provider matrix: Providers. Health re-check: doctor. Host/cluster tool bootstrap: Setup. Existing cluster in ~15 min: Adopt. $0 Observe walkthrough: Demo. --- # Demo URL: https://kprompt.ai/docs/demo kprompt demo — $0 Observe walkthrough checklist (kind + kprompt-examples). No LLM key. Not the NL plan→approve loop. Prints prerequisite checks (Docker, kind, kubectl, make, git, kprompt) and the exact kprompt-examples commands. Does not clone or mutate — guided checklist MVP. ``` kprompt demo kprompt demo --check git clone https://github.com/kprompt/kprompt-examples.git cd kprompt-examples && make walkthrough ``` This is Observe / heuristic (propose-only). For plan-before-apply on your cluster: Init, then a sample prompt. ``` kprompt init --ollama kprompt "how's my cluster" kprompt "scale api to 3" ``` --- # CI / JSON URL: https://kprompt.ai/docs/ci Stable PlanResult output for pipeline gates. JSON output helps you gate risky plans in CI. It does not remove the need for human judgment — kprompt remains experimental, and auto-approve in pipelines can still apply a bad plan if your checks are too loose. Pass --output json or -o json to emit a single PlanResult document on stdout. Human confirmations and wait status go to stderr in JSON mode. Field-by-field walkthrough: PlanResult JSON deep dive. ``` kprompt "scale api to 10" -n prod --output json ``` ## Schema | Field | Notes | | --- | --- | | apiVersion | always kprompt.io/v1 | | kind | always PlanResult | | schemaVersion | "1" — bump only on breaking changes | | plan.intent | scale, deploy, workflow, performance, get, route, … | | plan.actions | ops without YAML manifests | | risk.level | low / medium / high / denied | | risk.denied | hard deny | | applied | whether a mutation ran | | cluster_context | kubeconfig context for this plan (also on actions[]) | | blastRadius | optional mutate review aid: namespaces, labels/owners, related HPA/Service/NetworkPolicy (T-069) | | verify | optional post-apply: ok / pending / failed / skipped (T-070) | | requiresApproval | true when a mutating plan needs approve | | result | optional get/explain/logs/describe/workflow/performance payload | Manifests and API keys are never included. ## Gate example ``` #!/usr/bin/env bash set -euo pipefail json="$(kprompt "scale api to 10" -n prod -o json)" echo "$json" | jq -e '.risk.denied == false' >/dev/null echo "$json" | jq -e '.plan.intent == "scale"' >/dev/null kprompt "scale api to 10" -n prod --approve --wait ``` ## jq helpers ``` # Fail if any delete is planned echo "$json" | jq -e '[.plan.actions[].op] | index("delete") | not' # High-risk gate echo "$json" | jq -e '.risk.level != "high"' ``` --- # MCP URL: https://kprompt.ai/docs/mcp kprompt mcp serve — read/plan-only Model Context Protocol tools for IDE assistants. Mutations return PlanResult JSON and never auto-apply. kprompt mcp serve exposes kprompt to IDE assistants (Cursor, Claude Desktop, Windsurf, …) as a read/plan-only Model Context Protocol tool provider. kprompt here is an MCP tool provider, not an agent platform. Mutating prompts return a typed PlanResult and stop — the MCP surface never applies a change to the cluster. Approval stays a human action you run yourself (kprompt "…" --approve in your own terminal). ## Transport Newline-delimited JSON-RPC 2.0 over stdio. Your editor spawns kprompt mcp serve and talks to it on stdin/stdout; kprompt’s human-readable output goes to stderr, keeping stdout clean for the protocol. ``` kprompt mcp serve ``` ## Tools | Tool | What it does | Mutates? | | --- | --- | --- | | kprompt.read | Natural-language read against the active kubeconfig. Returns PlanResult JSON. | No | | kprompt.investigate | Multi-hop root-cause walk for a target. | No | | kprompt.why | Causal analysis of why a target is failing/pending/crashing. | No | | kprompt.timeline | Chronology of what happened to a target. | No | | kprompt.impact | Reverse dependencies / blast radius for a target. | No | | kprompt.plan | Compile a mutation prompt into a typed PlanResult. Never applies. Wipe-class intents hard-deny. | No | | kprompt.tools | List detected integrations as JSON. | No | | kprompt.doctor | Read-only environment health report. Never prints API keys. | No | Reasoning tools need a configured LLM provider because they compile natural language into intent. They honor your kubeconfig RBAC — no cluster credentials leave your machine. kprompt.plan is the explicit mutation surface: it returns the plan an assistant can show you; applying it stays out-of-band. The MCP server exposes no approval path. ## Editor configuration ### Cursor (~/.cursor/mcp.json or project .cursor/mcp.json) ``` { "mcpServers": { "kprompt": { "command": "kprompt", "args": ["mcp", "serve"] } } } ``` ### Claude Desktop (claude_desktop_config.json) ``` { "mcpServers": { "kprompt": { "command": "kprompt", "args": ["mcp", "serve"] } } } ``` Use an absolute path to the kprompt binary if it is not on the editor’s PATH. ## Safety - No remote auto-apply — the server never executes a mutation; --approve is not reachable over MCP - Hard-denies intact — wipe-class / namespace-delete intents are refused regardless of caller - Local trust — stdio transport is scoped to the operator who launched the editor; there is no network listener by default ## Quick manual check ``` printf '%s\n' \ '{"jsonrpc":"2.0","id":1,"method":"initialize"}' \ '{"jsonrpc":"2.0","id":2,"method":"tools/list"}' \ | kprompt mcp serve ``` --- # High-signal articles (summaries) ## kubectl vs K9s: differences, when to use each, and why you need both URL: https://kprompt.ai/blog/kubectl-vs-k9s Published: 2026-07-26 kubectl vs K9s (and k9s vs kubectl): kubectl is the scriptable API client; K9s is a live terminal UI over the same API. When to use each in incidents, CI, and day-2 ops — plus where AI CLIs fit. ## K9s vs Kubernetes (k8s): what people mix up — and the real comparison URL: https://kprompt.ai/blog/k9s-vs-kubernetes Published: 2026-08-02 k9s vs k8s is usually a category mistake: Kubernetes is the platform, K9s is a terminal UI for it. Clear the confusion, then see kubectl vs K9s and K9s alternatives. ## K9s alternatives in 2026: kubectl, Lens, Headlamp, and AI CLIs URL: https://kprompt.ai/blog/k9s-alternatives Published: 2026-08-02 Best K9s alternatives by job: stick with kubectl for scripts, Lens or Headlamp for visual multi-cluster, or a plan-before-apply AI CLI when intent is the bottleneck — not the TUI. ## Kubectl alternatives in 2026: K9s, Kubernetes dashboards, and AI CLIs compared URL: https://kprompt.ai/blog/kubectl-alternatives Published: 2026-07-16 Compare kubectl alternatives: K9s terminal UI, Headlamp and Lens dashboards, and natural-language Kubernetes CLIs. Which interface fits navigation, visual management, troubleshooting, and plan-before-apply operations. ## Kubegpt vs K8sGPT: same search, different tools (and what to use) URL: https://kprompt.ai/blog/kubegpt-vs-k8sgpt Published: 2026-08-02 People searching Kubegpt usually mean K8sGPT — the analyzer-first Kubernetes AI tool. How it differs from kubectl-ai and plan-before-apply CLIs, and when each job fits. ## kubectl-ai alternatives in 2026: plan-before-apply CLIs and when to keep Google’s tool URL: https://kprompt.ai/blog/kubectl-ai-alternatives Published: 2026-08-02 Best kubectl-ai alternatives by job: kprompt for gated PlanResult, K8sGPT for diagnosis, Kagent for in-cluster agents — plus when kubectl-ai is still the right REPL. ## AI for Kubernetes Pods: diagnose CrashLoop without silent apply URL: https://kprompt.ai/blog/ai-kubernetes-pod-diagnose Published: 2026-08-02 How to use AI on Kubernetes Pods safely: explain CrashLoopBackOff and ImagePullBackOff with kubectl, K8sGPT, or an intent CLI — without piping model output straight into apply. ## Chat with your Kubernetes cluster: what actually works safely URL: https://kprompt.ai/blog/chat-with-kubernetes-cluster Published: 2026-08-02 What “chat with your Kubernetes cluster” means in practice: local NL CLIs, hosted consoles, and analyzers — and how to keep credentials and apply behind a human gate. ## Best AI tools for Kubernetes troubleshooting (2026) URL: https://kprompt.ai/blog/best-ai-tools-kubernetes-troubleshooting Published: 2026-08-02 Practical shortlist of AI tools for Kubernetes troubleshooting: K8sGPT for scans, intent CLIs for explain/plan, kubectl for evidence — with an honest mutation checklist. ## Kubernetes AI tools: K8sGPT, kubectl-ai, Kagent, and plan-before-apply CLIs URL: https://kprompt.ai/blog/kubernetes-ai-tools-comparison Published: 2026-07-18 Map of Kubernetes AI / k8s AI tools by job: K8sGPT (and Kubegpt-style searches) for diagnosis, kubectl-ai and kprompt for NL CLIs, Kagent for in-cluster agents — honest mutation contracts included. ## What is Kubernetes AI? Tools, jobs, and what “AI for K8s” actually means URL: https://kprompt.ai/blog/what-is-kubernetes-ai Published: 2026-07-26 A plain-language map of Kubernetes AI: analyzers like K8sGPT, intent CLIs like kubectl-ai and kprompt, in-cluster agents, and what belongs in CI vs on your laptop — for searches like kubernetes ai, k8s ai, and k8s ai tools. ## Kubernetes Pods vs Deployments: what beginners actually need to know URL: https://kprompt.ai/blog/kubernetes-pods-vs-deployments Published: 2026-07-28 A plain guide to Pods and Deployments — what each one is, how they relate, kubectl commands that stick, common beginner mistakes, and optional natural-language checks with kprompt. ## What is a Deployment in Kubernetes? (with kubectl examples) URL: https://kprompt.ai/blog/what-is-a-kubernetes-deployment Published: 2026-08-02 What a Kubernetes Deployment is, how it manages Pods and ReplicaSets, kubectl get/describe/rollout commands, common beginner mistakes, and optional natural-language checks with kprompt. ## kubectl get pods explained: STATUS, restarts, and next commands URL: https://kprompt.ai/blog/kubectl-get-pods-explained Published: 2026-08-02 How to read kubectl get pods output — READY, STATUS, RESTARTS, AGE — what CrashLoopBackOff and Pending mean, and which kubectl command to run next. ## Kubernetes Service vs Deployment: roles, not rivals URL: https://kprompt.ai/blog/kubernetes-service-vs-deployment Published: 2026-08-02 Service vs Deployment in Kubernetes: Deployments run and update Pods; Services give those Pods a stable network identity. When you need each, how they connect via labels, and kubectl checks that stick. ## kprompt vs kubectl-ai: same NL CLI lane, different mutate contract URL: https://kprompt.ai/blog/kprompt-vs-kubectl-ai Published: 2026-07-23 Both turn English into Kubernetes actions on your laptop. kubectl-ai optimizes for kubectl fluency and agentic chat; kprompt compiles intent into a gated PlanResult — plan, safety, approve — then apply. Decision guide for operators choosing an AI Kubernetes CLI. ## kprompt vs kagent: PlanResult ops CLI vs Kubernetes-native agent platform URL: https://kprompt.ai/blog/kprompt-vs-kagent Published: 2026-07-29 kagent (CNCF Sandbox / Solo.io) is a Kubernetes-native agent runtime — Agents as CRDs, MCP, A2A, mesh. kprompt is an AI Runtime for cluster ops: PlanResult → approve, plus Observe notify. Is kprompt a kagent alternative? Only for the ops job — decision guide. ## kprompt + kagent: PlanResult as an MCP tool under a CNCF agent platform URL: https://kprompt.ai/blog/kprompt-kagent-integration Published: 2026-08-29 How to compose kprompt with kagent without collapsing the layers: kagent hosts Agents-as-CRDs via MCPServer / RemoteMCPServer; kprompt ships read/plan-only MCP tools that return a typed PlanResult and never auto-apply. Validated against kagent quickstart + first MCP tool docs. ## kagent alternatives in 2026: when you want PlanResult ops instead of an agent platform URL: https://kprompt.ai/blog/kagent-alternatives Published: 2026-08-16 Looking for a kagent alternative? Map by job: kprompt for plan-before-apply day-2 + Observe notify, kubectl-ai for NL kubectl REPL, K8sGPT for diagnosis, ARK for agent apps as CRDs — plus when to keep CNCF kagent. ## kprompt vs agentgateway: PlanResult ops CLI vs AI/MCP agent gateway URL: https://kprompt.ai/blog/kprompt-vs-agentgateway Published: 2026-08-16 agentgateway (Linux Foundation) is an AI-native proxy for LLM, MCP, and A2A traffic on Gateway API. kprompt is an AI Runtime for cluster ops: PlanResult → approve, plus Observe notify. Is kprompt an agentgateway alternative? Only for the ops job — decision guide. ## agentgateway alternatives in 2026: when you want PlanResult ops instead of an AI gateway URL: https://kprompt.ai/blog/agentgateway-alternatives Published: 2026-08-16 Looking for an agentgateway alternative? Map by job: kprompt for plan-before-apply day-2 + Observe notify, other AI/MCP gateways for LLM traffic policy, kagent for Agents-as-CRDs — plus when to keep Linux Foundation agentgateway. ## AI Runtime vs AI Gateway vs Agent Platform — kprompt, agentgateway, and kagent URL: https://kprompt.ai/blog/ai-runtime-vs-ai-gateway-vs-agent-platform Published: 2026-08-16 Three Kubernetes AI layers that share vocabulary and confuse buyers: AI Runtime (kprompt PlanResult ops), AI Gateway (agentgateway LLM/MCP/A2A data plane), Agent Platform (kagent Agents-as-CRDs). One hub, honest jobs, deep links. ## kprompt vs ARK: AI Runtime that operates the cluster vs Agentic Runtime that hosts agents URL: https://kprompt.ai/blog/kprompt-vs-ark Published: 2026-07-29 McKinsey’s ARK is an Agentic Runtime for Kubernetes — CRDs to run agent apps on the cluster. kprompt is an AI Runtime that reasons about the cluster under plan → approve. Same word “runtime,” different jobs. Decision guide. ## kprompt as an MCP tool provider — plan-gated ops from your editor URL: https://kprompt.ai/blog/kprompt-mcp-tool-provider Published: 2026-08-10 kprompt mcp serve exposes read and plan tools to Cursor, Claude Desktop, and other IDE assistants over stdio. Mutations return a PlanResult and never auto-apply. IDE interop, not an agent platform. ## Brownfield kprompt in 15 minutes — adopt without rebuilding the stack URL: https://kprompt.ai/blog/brownfield-kprompt-in-15-minutes Published: 2026-08-10 Starting from zero with kind is easy. The real challenge is attaching kprompt to a cluster you already run: bind existing Prometheus, read-first insight, optional MCP — install last. ## kprompt + Helm deep dive: install, upgrade, dry-run, and wipe denies URL: https://kprompt.ai/blog/kprompt-helm-deep-dive Published: 2026-08-10 Day-2 Helm with kprompt: real helm install/upgrade plans, template and client dry-run previews, Bitnami recipes, and hard denies for uninstall-all — without replacing Helm or GitOps. ## kprompt + Prometheus: why is my api slow — without inventing numbers URL: https://kprompt.ai/blog/kprompt-prometheus Published: 2026-08-11 Day-2 Prometheus with kprompt: bind an existing Prom URL, read-only performance explain (CPU, memory, p95, HPA), optimize idle/rightsizing, and fail clear when metrics are missing. Not a PromQL IDE and not auto-remediation. ## kprompt + OpenTelemetry: trace payment request — without inventing spans URL: https://kprompt.ai/blog/kprompt-opentelemetry Published: 2026-08-29 Day-2 OpenTelemetry with kprompt: bind Jaeger or Tempo, walk a span tree, narrate bottleneck waits, enrich service graphs with call edges when traces exist, and degrade honestly when OTel is missing. Not a Jaeger UI and not auto-remediation. ## kprompt + Argo CD: sync status, drift, and approve-gated reconcile URL: https://kprompt.ai/blog/kprompt-argo-cd Published: 2026-08-29 Day-2 Argo CD with kprompt: detect Application CRDs, show gitops sync status, investigate drift vs Git, approve-gated sync/promote/rollback through the real Application API, and optional --gitops PR mode instead of live reconcile. Flux is the peer engine on the same contract. Not an Argo UI and not silent sync. ## Top 100 Kubernetes prompts (natural language ↔ kubectl) URL: https://kprompt.ai/blog/top-100-kubernetes-prompts Published: 2026-08-10 A tagged hub of ~100 real Kubernetes ops prompts—Operations, Debug, GitOps, Observability, Security, and Multi-cluster—each with a kubectl or tooling note, linked to our cheat sheet, error playbook, and edge-case guide. ## The AI Runtime for Kubernetes — not another AI wrapper URL: https://kprompt.ai/blog/ai-runtime-for-kubernetes Published: 2026-07-29 Why kprompt’s category is an AI Runtime for Kubernetes: observe, reason, plan, approve, execute, learn — not a ChatGPT wrapper, chatbot, or silent auto-healer. Honest shipped vs building. ## Prompt engineering is dead. Context engineering begins URL: https://kprompt.ai/blog/context-engineering-not-prompt-engineering Published: 2026-07-28 For Kubernetes AI, clever prompts lose to curated context: live cluster facts, tool detection, local history, and a typed PlanResult. Why the next leap is what you feed the model — not how you word the sentence. ## Observe vs investigate: always-on agent vs on-demand CLI URL: https://kprompt.ai/blog/observe-vs-investigate Published: 2026-08-16 Same Investigation Graph DNA — different trigger. Laptop investigate is reactive; the optional Observe agent is continuous watch → Incident → gated notify. ## Stop paging on every kubelet Event: Incidents + confidence gates URL: https://kprompt.ai/blog/observe-agent-alert-fatigue Published: 2026-08-16 Always-on Kubernetes watch only helps if you correlate into Incidents and gate by severity and confidence — not one Slack message per BackOff. ## Break a kind cluster on purpose, then watch the Observe agent URL: https://kprompt.ai/blog/observe-agent-kind-demo Published: 2026-07-26 One command from kprompt-examples: kind up, seven failure scenarios, verify they actually broke, then run the Observe agent offline in heuristic mode. ## kprompt v0.5: optional Observe agent, still no silent Autopilot URL: https://kprompt.ai/blog/kprompt-v0-5-observe-agent Published: 2026-07-25 v0.5 ships the namespace-scoped Observe agent — watch → Incident → gated Slack/webhook — plus Operator, memory, patterns, and Autopilot propose-only under ADR-0015. The laptop CLI stays plan → approve → apply. ## Building AI SRE in Public URL: https://kprompt.ai/blog/building-ai-sre-in-public Published: 2026-07-23 A long-form series on building an AI SRE under an approval boundary — intent compiler, PlanResult, safety, multi-context, investigation, and why we refuse unsupervised auto-remediation. Episode index and honesty rules. ## Building AI SRE in Public #1: Why AI SRE URL: https://kprompt.ai/blog/building-ai-sre-01-why Published: 2026-07-23 AI kubectl is not enough. Production needs investigate, why, blast radius, and verify — still behind an approval boundary. Why the AI SRE category exists, what failed in classic AIOps, and what we ship first. ## Building AI SRE in Public #2: Intent Compiler URL: https://kprompt.ai/blog/building-ai-sre-02-intent-compiler Published: 2026-07-23 Kubernetes deserves a compiler, not a chatbot. How kprompt turns natural language into Intent → Actions → PlanResult, why Go owns planning and safety, and why the IR must stay reviewable for AI SRE. ## Building AI SRE in Public #3: PlanResult URL: https://kprompt.ai/blog/building-ai-sre-03-planresult Published: 2026-07-23 PlanResult is the IR of AI SRE: one typed document for humans and CI. Why JSON, what applied means vs verify, how blastRadius attaches, what never gets stored, and how investigate/why must extend the same artifact. ## Building AI SRE in Public #4: Safety Engine URL: https://kprompt.ai/blog/building-ai-sre-04-safety Published: 2026-07-23 Policy is code, not LLM vibes. How kprompt’s safety engine hard-denies wipe-class intents, scores risk, forces approval, and why fail-closed is the load-bearing wall of AI SRE. ## Building AI SRE in Public #5: Multi-context URL: https://kprompt.ai/blog/building-ai-sre-05-multi-context Published: 2026-07-27 AI SRE across kubeconfig contexts: single-context default, explicit read fan-out, per-context mutate approval, aliases, and why we refuse silent fleet --approve or uploading cluster credentials. ## kprompt is an intent compiler, not a Kubernetes chat REPL URL: https://kprompt.ai/blog/intent-compiler-not-chat Published: 2026-07-18 Why we compile natural language into a gated PlanResult instead of racing kubectl-ai on agentic chat — same NL CLI lane, different contract: typed plans, hard denies, CI JSON, multi-tool day-2 under one approval loop. ## Beyond AI kubectl: why kprompt is aiming at AI SRE URL: https://kprompt.ai/blog/ai-sre-not-ai-kubectl Published: 2026-07-23 Natural language → plan → approve is the wedge. The differentiator is thinking about the cluster — investigate, why, timeline, blast radius, verify — still under the same approval contract. Honest shipped vs building vs exploring. ## optimize my cluster: idle workloads, rightsizing, and HPA hints — without auto-apply URL: https://kprompt.ai/blog/optimize-my-cluster Published: 2026-07-23 How kprompt’s shipped optimize report works: inventory, Prometheus-backed idle and rightsizing findings, HPA hints, JSON output, and optional follow-up scale/patch plans that still require their own approval. What it is not. ## PlanResult JSON deep dive: fields, risk, jq recipes, and what is never stored URL: https://kprompt.ai/blog/planresult-json-deep-dive Published: 2026-07-23 Schema-focused companion to CI plan gates: apiVersion, plan.actions, risk.denied, result payloads, RouteResult / MultiContextResult, history vs CI artifacts, and hard rules on manifests and API keys. ## Kubernetes in CI/CD: gating cluster changes with plan JSON before apply URL: https://kprompt.ai/blog/kubernetes-ci-cd-plan-gates Published: 2026-07-16 How to use kprompt PlanResult JSON in CI/CD pipelines to review Kubernetes scale, deploy, and rollback plans before apply — with jq gates, GitHub Actions patterns, and production safety rules. ## Kubernetes OOMKilled: how to detect memory kills, raise limits, and avoid guesswork URL: https://kprompt.ai/blog/kubernetes-oomkilled Published: 2026-07-18 A practical guide to OOMKilled in Kubernetes — exit 137, Last State, memory requests vs limits, kubectl checks, and how kprompt explain can suggest a reviewable memory patch. ## Kubernetes CrashLoopBackOff: how to read it, find the cause, and fix it URL: https://kprompt.ai/blog/kubernetes-crashloopbackoff Published: 2026-07-26 CrashLoopBackOff is a symptom, not a cause. How the restart backoff works, what exit codes tell you, the kubectl ladder for finding the real failure, and how to apply a bounded fix you actually reviewed. ## Kubernetes ImagePullBackOff: how to read ErrImagePull and fix the image reference URL: https://kprompt.ai/blog/kubernetes-imagepullbackoff Published: 2026-07-26 ImagePullBackOff means the container never started. How ErrImagePull differs from CrashLoopBackOff, what Events tell you, common causes (bad tag, private registry, rate limit), and how to fix it without guessing. ## kubectl cheat sheet with natural-language equivalents (kprompt) URL: https://kprompt.ai/blog/kubectl-cheat-sheet-natural-language Published: 2026-07-18 A practical kubectl cheat sheet paired with natural-language prompts — get, list, describe, logs, scale, rollback, delete, explain, Helm, and JSON CI — for operators who know the API and want faster day-2 typing. ## Real Kubernetes error prompts: crash loops, OOM, ImagePull, denies, and slow APIs URL: https://kprompt.ai/blog/kubernetes-error-prompt-playbook Published: 2026-07-18 A playbook of real incident prompts for Kubernetes — what to type when pods crash, images fail to pull, memory kills, wipe-class mistakes, RBAC denials, and latency spikes — with kprompt examples that stay plan-before-apply. ## How to troubleshoot Kubernetes: deployments, pods, and crash loops from the terminal URL: https://kprompt.ai/blog/kubernetes-troubleshooting-guide Published: 2026-07-16 A practical guide to Kubernetes troubleshooting — CrashLoopBackOff, deployments not ready, image pull errors, and rollbacks — using kubectl workflows and natural-language explains with kprompt. ## Kubernetes safety with AI: plan, approve, hard denies, and production discipline URL: https://kprompt.ai/blog/kubernetes-safety-plan-approve Published: 2026-07-16 Why natural-language Kubernetes tools need plan-before-apply, risk scoring, and hard denies — with real kprompt examples for scale, rollback, and blocked wipe prompts. ## Choosing an LLM for Kubernetes: BYOK providers, privacy, and what to run in prod URL: https://kprompt.ai/blog/kubernetes-llm-providers-byok Published: 2026-07-16 Compare Gemini, OpenAI, Anthropic, Groq, and Ollama for Kubernetes CLI workflows with kprompt — BYOK keys, air-gapped setups, model speed vs explain quality, and security rules for operators. ## Optional Team app https://app.kprompt.ai — early; CLI stays free; nothing to buy as a public signup product today.