Automation and control boundaries
What UnitVane runs automatically, what requires a decision, and which system applies each change across Kubernetes and AI.
Who does what
From infrastructure to an approved change
- 01
Collect
The read-only agent sends cluster snapshots. Billing exports or rate cards provide the cost basis.
Agent + billing
- 02
Allocate
The hub assigns cost to workloads and teams, separates shared and idle spend, and reconciles the totals.
KubeOn hub
- 03
Review
A proposal brings together the saving, evidence, risk and patch. An authorized reviewer records a decision.
Your reviewers
- 04
Apply + verify
Merge the pull request, or let KubeOn apply the change where you granted write access. The saving is then measured.
Your pipeline or KubeOn
Read-only by default. KubeOn changes a cluster only where you grant write access, feature by feature.
Read the workflowWho does what
One cost model, with control in the request path
- 01
Connect
Read provider billing, token usage and provisioned capacity. Map deployments and keys to their owners.
Provider data
- 02
Understand
Compare effective cost per 1M tokens, including provisioned and reserved capacity, for the same time window.
Tokenomics
- 03
Route + control
Applications call the gateway. It selects permitted targets, handles configured fallback and enforces key policies.
AI gateway
- 04
Measure + tune
Review request costs, errors, latency and capacity utilization. Adjust policies and approve commitments with evidence.
Your AI + FinOps team
Gateway policies control routed requests. Capacity purchases and renewals require named approval.
Read the workflowOn this page
The control model
| Workflow | Automatic behavior | Who applies changes |
|---|---|---|
| Kubernetes visibility | Scheduled snapshots, billing ingestion, allocation, reconciliation and alerts | No workload changes |
| Kubernetes savings | Computes findings, generates proposals with evidence, risk and a patch, and opens approved changes as pull requests | Your team approves, or Automatic mode per cluster within its safeguards. Your CD applies a pull request, or the controller applies the change where you granted write access. Production pull requests wait for a person to merge. |
| AI tokenomics | Imports billing and token telemetry; computes cost and capacity recommendations | Read-only analysis |
| AI gateway | Routes, retries, falls back and enforces configured key policies on incoming requests | Gateway, within the policies an administrator enables |
| AI reservations | Prepares purchase and renewal decisions | Named approval required before purchase or renewal |
| GPU optimizer (opt-in) | Shares, scales, packs, bursts and scales GPUs to zero, per policy | Recommend: your pipeline. Approve: the optimizer, after a named reviewer. Automatic: the optimizer, within the policy's limits |
Kubernetes: evidence to deployment
- Check Diagnostics, billing coverage and the recommendation's usage window before accepting a saving.
- Open the proposal and review the current state, proposed state, evidence, risk and rollout steps.
- An authorized reviewer approves or rejects the proposal. Approval is recorded in the audit log.
- KubeOn opens the change as a pull request on the file the workload is defined in, found through Argo CD, Flux, Helm release annotations or a
kubeon.io/sourceannotation. Your CI runs, a person merges it, and your CD deploys it in your usual change window. - KubeOn confirms the deployment, watches workload health, and opens a revert with an alert if checks fail. It then measures the saving and marks the proposal Applied.
Two delivery paths
get, list and watch. With write access, a separate controller can apply changes in the cluster, for the features you granted. Workloads deployed by Argo CD or Flux still go through their repository.Kubernetes automation modes
| Mode | What happens | Who merges |
|---|---|---|
| Team approval (default) | Each proposal waits for an approver; on approval KubeOn opens the pull request | A person |
| Automatic | KubeOn opens pull requests itself, within the cluster's safeguards | Your branch rules; production always waits for a person |
| Paused | No pull requests open and nothing is applied; proposals keep generating | Nobody |
Safeguards are checked before a pull request opens, and again by a CI check (GitHub Action or GitLab CI) before merge:
- Requests stay above p95 usage plus headroom, and above any floor you set; workloads with recent OOM kills are skipped.
- Cuts are staged, at most 30% per step by default, with at most 3 changes open per cluster.
- Freezes and change windows hold, and a workload or namespace can opt out with an annotation.
- After deploy, KubeOn watches for 30 minutes, then 24 hours. A failed check opens a revert and an alert; repeated rollbacks pause the cluster.
- One switch pauses automation everywhere.
GPU optimizer: policies you enable
The GPU optimizer changes a cluster only where you install it. It is a separate Helm release with its own published permissions, and it acts only on the node pools and namespaces its policies name.
- Start every policy in Recommend mode and compare its proposals with what your team would have done.
- Move a policy to Approve so each change waits for a named reviewer, then to Automatic once its record is clean.
- Set the limits first: minimum and maximum nodes, monthly cost, allowed GPU types, burst locations and change windows.
- Review the optimizer's actions in the audit log, revert any that should not have happened, and set a policy back to Recommend to stop it at once.
See GPU optimization for each policy kind and its rules.
AI gateway: policies in the request path
The gateway can route provisioned capacity first, spill over to pay-as-you-go and fall back after configured failures. A key can warn at budget thresholds or reject requests when its hard-stop policy is reached. These controls apply only to traffic using the gateway; direct provider calls are outside that enforcement path.
- Scope each key to a team, product and permitted routes.
- Set retry bounds and confirm fallback targets support the application's request and response requirements.
- Test budgets, rate limits, residency restrictions and redaction with non-production traffic.
- Review latency, errors, token usage and cost before expanding traffic. Keep a tested application routing rollback.
Capacity commitments
Purchases and renewals wait for a named approver with their term, scope and quantity recorded. Approval for routing does not imply approval to purchase capacity. See provisioned capacity sizing.
Evaluation evidence
Record who owns the policy, which workloads or routes it covers, the baseline, the validation result and the rollback procedure. Use the enterprise evaluation guide to agree on acceptance criteria with platform engineering, FinOps and security.