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

AI Agents

  • 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.
  • AI Agents agent-platform v4.81.0

    Added

    • clusterManager.networkPolicy.workloadClusters.provider: aws opens the CAPA API server load balancers, *.*.elb.amazonaws.com (giantswarm/agent-platform#487). cluster-manager dials the server: of a cluster’s Cluster API kubeconfig Secret, which on CAPA is the API server’s load balancer, never the api.*.<base domain> pattern the values used to document. The preset renders next to fqdns in cluster-manager’s egress and in model-manager’s, which follows cluster-manager’s block. An unknown provider is refused and the presets are named. The values now say which host to select and that Cilium’s * matches one DNS label.
  • AI Agents klaus-operator v0.0.173

    Fixed

    Full Changelog: https://github.com/giantswarm/klaus-operator/compare/v0.0.172...v0.0.173

  • AI Agents klaus v0.1.41

    Changed

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