1. Docs
  2. Changes and releases
  3. AI Agents

AI Agents

  • AI Agents klaus v0.1.42

    Fixed

    Full Changelog: https://github.com/giantswarm/klaus/compare/v0.1.41...v0.1.42

  • AI Agents agent-platform v4.86.0

    Changed

    • Every OCIRepository this chart renders polls gsoci every minute: gitops.sourceInterval, default 1m (giantswarm/giantswarm-management-clusters#2589). The component OCIRepositories and the self-management one polled on gitops.interval and gitops.self.interval (10m), so a component or platform release pushed to gsoci was stored and installed up to ten minutes later. The sources now poll on gitops.sourceInterval; a poll is one tag list per chart. Every child HelmRelease keeps reconciling on gitops.interval and the self HelmRelease on gitops.self.interval, both 10m, which now govern the HelmReleases only. tests/verify-components.py and tests/verify-self.py assert both cadences and both knobs.
  • AI Agents agent-platform v4.85.0

    Changed

    • A targeted release (gitops.target.kubeConfig) names its children per target and installs them into a namespace of the platform’s own (giantswarm/agent-platform#688). Each OCIRepository and HelmRelease on the installation is <gitops.target.name>-<component> (gitops.target.name is new; empty means the release name), and so is every dependsOn and chartRef. Two targeted releases in one namespace (two workload clusters of one organization) no longer collide. Each child’s Helm release keeps the component’s name. gitops.targetNamespace now defaults to agent-platform with the knob, and the Helm storage follows it (storageNamespace), so nothing lands in the organization namespace on the target any more. Without the knob, the render is unchanged. A targeted release rendered by an older chart renames its children on upgrade: Flux uninstalls the old ones from the target and installs the new ones into the new namespace.
  • AI Agents agent-platform v4.84.2

    Fixed

    • An uninstall with the bundled engine completes: the engine is removed after Helm’s delete pass (#708). The pre-delete hook at weight 5 deleted the FluxInstance, the operator then uninstalled Flux with its CRDs, and Helm’s pass, which builds every object of the release before deleting any, failed on the first HelmRelease whose kind was no longer served (resource mapping not found … ensure CRDs are installed first), leaving the release uninstalling, a retry failing the same way. The FluxInstance and the Flux Operator’s Deployment, ServiceAccount and ClusterRoleBinding carry helm.sh/resource-policy: keep, so Helm’s pass neither builds nor deletes them and Flux is served until it is over; the post-delete hooks teardown-engine (weight 0: delete the FluxInstance and wait for Flux to be uninstalled) and teardown-operator (weight 5: delete the operator’s three objects) remove the engine after it. The hook identity and its network policy render at post-delete too. Switching components.flux.enabled off in place now leaves the engine running outside the release; the README names what to delete. make verify-engine, verify-self and verify-hooks-netpol assert the hooks, their events and the kept objects.
  • AI Agents agent-platform v4.84.1

    Fixed

    • The catalog’s Anthropic ModelConfigs answer at the platform’s output bound, not kagent’s 8192 (giantswarm/agent-platform#702). A kagent.modelConfigs[] entry rendered no maxTokens, so an agent on one (gazelle’s four Opus agents) stopped a long answer at kagent’s built-in 8192 tokens, thinking included, while the default ModelConfig had the 32000 the platform manager sets. An Anthropic entry now inherits kagent.providers.anthropic.config.maxTokens like the cache keys; an entry’s own maxTokens wins and lands in its provider’s block (Anthropic, AnthropicVertexAI, AzureOpenAI, Mistral, OpenAI); on any other provider the render refuses it naming the entry. make verify-max-tokens asserts it.
  • AI Agents agent-platform v4.84.0

    Removed

    • modelManager.route: model-manager’s REST route, its JWT policy and the data-plane legs of its network policies (giantswarm/agent-platform#271). The portal, agents and the agentlab proofs reach model-manager through muster as the signed-in person (its MCPServer CR, x_model-manager_*), so nothing called the route. The connectivity chart renders no AgentgatewayBackend, HTTPRoute or AgentgatewayPolicy for model-manager, its ingress policy admits muster, additionalPeers and the probes, and dataplane-to-model-manager is gone in both flavours. A set modelManager.route fails the render naming the issue; model-manager’s oauth.baseURL stays https://agentgateway.<global.domain>/model-manager. agentManager.route, kagent.controllerRoute and gateway.jwksEgress are unchanged. UPGRADE.md.
  • AI Agents agent-platform v4.83.0

    Changed

    • gemma-4-31b serves 32k on one L40S: --kv-cache-dtype=fp8 with --max-model-len=32768 (was 8k) (giantswarm/agent-platform#611). With vLLM’s bf16 KV cache the 48 GB card held 8640 tokens beside the 31 GiB of weights. The fp8 cache halves the need: on one L40S (g6e.2xlarge) with vLLM 0.23.0 the preset reached Ready with 49,885 tokens of KV cache (1.5 full-length requests at a time) and served tool calls through the gemma4 parser.
  • AI Agents agent-platform v4.82.0

    Added

    • muse-glimmer-30b: Meta’s Muse Glimmer 30B on one 48 GB GPU, on vLLM’s own server image (giantswarm/agent-platform#597). Red Hat AI’s FP8 block quantization (RedHatAI/Muse-Glimmer-30B-FP8-block, 32 GiB, served from the signed model image giantswarm/models/muse-glimmer-30b-fp8:1deb4641ff84) at 32k context, four concurrent requests, one image per prompt, reasoning and tools with vLLM’s muse_glimmer parsers under vLLM v0.30.0’s Muse Glimmer chat template (chat-templates/muse-glimmer-30b.jinja). The model’s architecture and parsers first ship in vLLM 0.28.0 and the llm-d runtime carries an older vLLM, so the preset names its runtime in spec.template: gsoci.azurecr.io/giantswarm/vllm-openai:v0.30.0, the signed copy of vllm/vllm-openai that retagger pins by digest (giantswarm/retagger#1245). The well-known template’s command runs it unchanged. Sized for a g6e.2xlarge or g6e.4xlarge.
  • AI Agents agent-platform v4.81.2

    Fixed

    • gpt-oss-20b and gpt-oss-120b answer after Ready: the harmony renderer reads its tiktoken encodings from the model image (giantswarm/agent-platform#606). vLLM’s harmony renderer loads the o200k_base and cl100k_base encodings at the first request, from openaipublic.blob.core.windows.net unless TIKTOKEN_ENCODINGS_BASE names a local directory. The serving namespace has no egress to that host, so both presets reached Ready and then answered every chat completion with HTTP 500 (HarmonyError: error downloading or loading vocab file). The presets now serve the model images that carry both files under /models/tiktoken (giantswarm/models/gpt-oss-20b:6cee5e81ee83-7abb6426, gpt-oss-120b:b5c939de8f75-7abb6426: the same checkpoint layers plus one layer with the encodings at their pinned sha256, giantswarm/models#13) and set TIKTOKEN_ENCODINGS_BASE=/mnt/models/tiktoken. The pod stays offline.
  • AI Agents agent-platform v4.81.1

    Fixed

    • A retried uninstall runs the serving teardown again without failing once the bundled engine has removed Flux (giantswarm/agent-platform#527). The <release>-serving-teardown hook deleted its two child HelmReleases unconditionally; on a retry after the engine’s teardown the HelmRelease API is gone, and every attempt failed with the server doesn't have a resource type "helmreleases", so the uninstall could not be retried. Without the API there is no child release left to order: the hook skips the two deletes and still frees any remaining config.