Download Latest Version v1.1.0 source code.tar.gz (4.3 MB)
Email in envelope

Get an email when there's a new version of agentgateway

Home / v1.0.0
Name Modified Size InfoDownloads / Week
Parent folder
agentgateway-darwin-arm64 2026-03-16 53.8 MB
0
agentgateway-darwin-arm64.sha256 2026-03-16 100 Bytes
0
agentgateway-linux-amd64 2026-03-16 58.8 MB
0
agentgateway-linux-amd64.sha256 2026-03-16 99 Bytes
0
agentgateway-linux-arm64 2026-03-16 53.3 MB
0
agentgateway-linux-arm64.sha256 2026-03-16 99 Bytes
0
agentgateway-windows-amd64.exe 2026-03-16 63.4 MB
0
agentgateway-windows-amd64.exe.sha256 2026-03-16 105 Bytes
0
README.md 2026-03-13 38.4 kB
0
v1.0.0 source code.tar.gz 2026-03-13 4.2 MB
0
v1.0.0 source code.zip 2026-03-13 5.1 MB
0
Totals: 11 Items   238.6 MB 0

🎉 Welcome to the 1.0.0 release of the agentgateway project!

Agentgateway is a production-ready gateway designed for cloud native environments, high scale, and native AI and Kubernetes workload support.

Agentgateway v1.0 represents a major milestone for the project, cementing its place as a production-ready foundation for managing AI agent traffic at scale. This release comes with a number of new features and improvements discussed below.

But first, I want to take a moment to look back on the project's growth. Agentgateway started exactly 1 year ago (🎂), and has already seen tremendous momentum. 2,000 stars and 1,000,000 image pulls later, Agentgateway has already had success in large scale production deployments across the globe. A special thanks to the 115 contributors who made this possible!

For more information, see the Standalone release notes and Kubernetes release notes.

Artifacts

Docker images are available:

  • cr.agentgateway.dev/agentgateway:v1.0.0
  • cr.agentgateway.dev/controller:v1.0.0

Helm charts are available:

  • cr.agentgateway.dev/charts/agentgateway:v1.0.0
  • cr.agentgateway.dev/charts/agentgateway-crds:v1.0.0

Binaries are available below.

Quick Start

Follow the Kubernetes or Standalone quick start guide to get started!

🔥 Breaking changes

New Kubernetes release version pattern

Previously, when running on Kubernetes, Agentgateway was deployed via Kgateway, and inherited its versioning. Because Agentgateway was independantly versioned as well, this meant there were two versions in play at once (such as v2.2 for the control plane, and v0.12 for the data plane).

This is the first release of Agentgateway that is entirely decoupled from Kgateway. There is now one shared version for the control plane, data plane, and helm charts (v1.0.0).

Please be advised that v1.0 is newer than v2.2.

Because of this, the Helm paths changed as follows:

  • CRDs: oci://cr.agentgateway.dev/charts/agentgateway-crds
  • Control plane: oci://cr.agentgateway.dev/charts/agentgateway

Make sure to update any CI/CD workflows and processes to use the new Helm chart locations.

XListenerSet API promoted to ListenerSet

The experimental XListenerSet API is promoted to the standard ListenerSet API in version 1.5.0. You must install the standard channel of the Kubernetes Gateway API to get the ListenerSet API definition. If you use XListenerSet resources in your setup today, update the CRD kind from XListenerSet to ListenerSet and api version from gateway.networking.x-k8s.io/v1alpha1 to gateway.networking.k8s.io/v1 as shown in the following examples.

Old XListenerSet example:

:::yaml
apiVersion: gateway.networking.x-k8s.io/v1alpha1
kind: XListenerSet
metadata:
  name: http-listenerset
  namespace: httpbin
spec:
  parentRef:
    name: agentgateway-proxy-http
    namespace: agentgateway-system
    kind: Gateway
    group: gateway.networking.k8s.io
  listeners:

  - protocol: HTTP
    port: 80
    name: http
    allowedRoutes:
      namespaces:
        from: All

Updated ListenerSet example: 

:::yaml
apiVersion: gateway.networking.k8s.io/v1
kind: ListenerSet
metadata:
  name: http-listenerset
  namespace: httpbin
spec:
  parentRef:
    name: agentgateway-proxy-http
    namespace: agentgateway-system
    kind: Gateway
    group: gateway.networking.k8s.io
  listeners:

  - protocol: HTTP
    port: 80
    name: http
    allowedRoutes:
      namespaces:
        from: All

CEL 2.0

This release includes a major refactor to the CEL implementation in agentgateway that brings substantial performance improvements and enhanced functionality. Individual CEL expressions are now 5-500x faster, which has improved end-to-end proxy performance by 50%+ in some tests. For more details on the performance improvements, see this blog post on CEL optimization.

The following user-facing changes were introduced:

  • Function name changes: For compatibility with the CEL-Go implementation, the base64Encode and base64Decode functions now use dot notation: base64.encode and base64.decode. The old camel case names remain in place for backwards compatibility.
  • New string functions: The following string manipulation functions were added to the CEL library: startsWith, endsWith, stripPrefix, and stripSuffix. These functions align with the Google CEL-Go strings extension.
  • Null values fail: If a top-level variable returns a null value, the CEL expression now fails. Previously, null values always returned true. For example, the has(jwt) expression was previously successful if the JWT was missing or could not be found. Now, this expression fails.
  • Logical operators: Logical || and && operators now handle evaluation errors gracefully instead of propagating them. For example, a || b returns true if a is true even if b errors. Previously, the CEL expression failed.

Make sure to update and verify any existing CEL expressions that you use in your environment.

For more information, see the CEL expression reference.

🌟 New features

Kubernetes Gateway API version 1.5.0

The Kubernetes Gateway API dependency is updated to support version 1.5.0. Gateway API 1.5 also comes with a number of new conformance tests; Agentgateway continues to be on the frontier of Gateway API support and passes all tests (standard, extended, and experimental).

This version introduces several changes, including:

  • XListenerSets promoted to ListenerSets: The experimental XListenerSet API is promoted to the standard ListenerSet API in version 1.5.0. You must install the standard channel of the Kubernetes Gateway API to get the ListenerSet API definition. If you use XListenerSet resources in your setup today, update these resources to use the ListenerSet API instead.
  • TLSRoute promotion: TLSRoute has been promoted from experimental to standard. If you are on the standard channel, you need to use v1 instead of v1alpha2. The experimental channel can continue to use v1alpha2.
  • AllowInsecureFallback mode for mTLS listeners: If you set up mTLS listeners on your agentgateway proxy, you can now configure the proxy to establish a TLS connection, even if the client TLS certificate could not be validated successfully. For more information, see the mTLS listener docs.
  • CORS wildcard support: The allowOrigins field now supports wildcard * origins to allow any origin. For an example, see the CORS guide.

Autoscaling policies for agentgateway controller

You can now configure Horizontal Pod Autoscaler policies for the agentgateway control plane. To set up these policies, you use the horizontalPodAutoscaler field in the Helm chart.

Review the following Helm configuration example. For more information, see Advanced install settings.

Horizontal Pod Autoscaler:

Make sure to deploy the Kubernetes metrics-server in your cluster. The metrics-server retrieves metrics, such as CPU and memory consumption for your workloads. These metrics can be used by the HPA plug-in to determine if the pod must be scaled up or down.

In the following example, you want to have 1 control plane replica running at any given time. If the CPU utilization averages 80%, you want to gradually scale up your replicas. You can have a maximum of 5 replicas at any given time.

:::yaml
horizontalPodAutoscaler:
  minReplicas: 1
  maxReplicas: 5
  metrics:

  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 80

Simplified LLM configuration

A new top-level llm configuration section provides a simplified way to configure LLM providers. Instead of setting up the full binds, listeners, routes, and backends hierarchy, you can now define models directly in a flat structure. The simplified format defaults to port 4000.

The following example configures an OpenAI provider with a wildcard model match:

:::yaml
# yaml-language-server: $schema=https://agentgateway.dev/schema/config
llm:
  models:

  - name: "*"
    provider: openAI
    params:
      apiKey: "$OPENAI_API_KEY"
Setting Description
name The model name to match in incoming requests. When a client sends "model": "<name>", the request is routed to this provider. Use * to match any model name.
provider The LLM provider to use, such as openAI, anthropic, bedrock, gemini, or vertex.
params.model The model name sent to the upstream provider. If set, this overrides the model from the request. If not set, the model from the request is passed through.
params.apiKey The API key for authentication. You can reference environment variables using the $VAR_NAME syntax.

You can also define model aliases to decouple client-facing model names from provider-specific identifiers:

:::yaml
llm:
  models:

  - name: fast
    provider: openAI
    params:
      model: gpt-4o-mini
      apiKey: "$OPENAI_API_KEY"
  - name: smart
    provider: openAI
    params:
      model: gpt-4o
      apiKey: "$OPENAI_API_KEY"

Policies such as rate limiting and authentication can be set at the llm level to apply to all models:

:::yaml
llm:
  policies:
    localRateLimit:

    - maxTokens: 10
      tokensPerFill: 1
      fillInterval: 60s
      type: tokens
  models:
  - name: "*"
    provider: openAI
    params:
      apiKey: "$OPENAI_API_KEY"

The traditional route-based configuration (binds/listeners/routes) remains fully supported for advanced use cases that require path-based routing or custom endpoints.

For more information, see the provider setup guides such as OpenAI, Anthropic, and Bedrock.

GRPCRoute support

You can now attach GRPCRoutes to your agentgateway proxy to route traffic to gRPC endpoints. For more information, see gRPC routing.

PreRouting phase support for policies

You can now use the phase: PreRouting setting on JWT, basic auth, API key authentication, and transformation policies. This setting applies policies before a routing decision is made, which allows the policies to influence how requests are routed. Note that the policy must target a Gateway rather than an HTTPRoute.

A key use case is body-based routing for LLM requests. The following example extracts the model field from a JSON request body and sets it as a header, which can then be used for routing decisions:

:::yaml
apiVersion: agentgateway.dev/v1alpha1
kind: AgentgatewayPolicy
metadata:
  name: body-based-routing
spec:
  targetRefs:

  - kind: Gateway
    name: my-gateway
    group: gateway.networking.k8s.io
  traffic:
    phase: PreRouting
    transformation:
      request:
        set:
        - name: X-Gateway-Model-Name
          value: 'json(request.body).model'

This allows you to route requests to different backends based on the model name specified in the request body. For example, you could route GPT-4 requests to one backend and Claude requests to another:

:::yaml
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: route-by-model
spec:
  parentRefs:

  - name: my-gateway
  rules:
  - matches:
    - headers:
      - name: X-Gateway-Model-Name
        value: gpt-4
    backendRefs:
    - name: openai-backend
  - matches:
    - headers:
      - name: X-Gateway-Model-Name
        value: claude-3
    backendRefs:
    - name: anthropic-backend

For more details on this pattern, see the body-based routing blog post.

Built-in CEL playground

The agentgateway admin UI now includes a built-in CEL playground for testing CEL expressions against agentgateway's CEL runtime. The playground supports the custom functions and variables specific to agentgateway that are not available in generic CEL environments. To open it, select CEL Playground in the admin UI sidebar.

CEL playground

For more information, see CEL playground.

LLM request transformations

You can now use CEL expressions to dynamically compute and set fields in LLM requests. This allows you to enforce policies, such as capping token usage, without changing client code.

The following example caps max_tokens to 10 for all requests to the openai HTTPRoute:

:::yaml
apiVersion: agentgateway.dev/v1alpha1
kind: AgentgatewayPolicy
metadata:
  name: cap-max-tokens
spec:
  targetRefs:

  - group: gateway.networking.k8s.io
    kind: HTTPRoute
    name: openai
  backend:
    ai:
      transformations:
      - field: max_tokens
        expression: "min(llmRequest.max_tokens, 10)"

Full Changelog

New Contributors

Full Changelog: https://github.com/agentgateway/agentgateway/compare/v0.12.0...v1.0.0

Source: README.md, updated 2026-03-13