Kratos v3 is a microservice framework, not an AI stack
Kratos provides a Go application shell for services that expose HTTP and gRPC from Protobuf contracts. Its core covers transports, middleware, configuration, logging, encoding, validation, metadata, errors, and code generation. Contrib modules connect registries, config stores, middleware, encodings, and observability systems. There is no language model, vector store, agent loop, or inference server in the README.
That distinction matters because this review sits in an AI-tools category. Kratos can host an AI gateway or a model-backed business service, but it contributes the same infrastructure it would give a payments or inventory service. Choose it for API contracts and service operations. Bring your own model provider, queue, data store, prompt layer, evaluation system, and safety controls.
The framework's main opinion is API-first development. Define a Protobuf service, generate client and server bindings, implement business logic, then run HTTP and gRPC through common application lifecycle code. The small example listens on port 8000 for HTTP and 9000 for gRPC. Generated OpenAPI and consistent errors can keep several clients aligned with the same contract.
Go 1.25 and Protobuf are real prerequisites
The current README requires Go 1.25 or later, protoc, and protoc-gen-go. Installing the Kratos v3 CLI is one Go command, after which kratos new helloworld, go mod tidy, and kratos run produce a starting service. A fuller workflow adds a .proto file, generates clients and server stubs, runs go generate, and starts the application.
This machinery pays off across a service fleet, where generated contracts and standard middleware remove repeated decisions. It is harder to justify for a small HTTP endpoint. A developer has to understand Protobuf annotations, generated files, module versions, transport mappings, dependency injection in the chosen layout, and how errors cross HTTP and gRPC. Gin or the standard library is a shorter path when none of that coordination is needed.
External infrastructure remains external. Registry and configuration interfaces can connect to systems such as Nacos through contrib modules, while OpenTelemetry extensions connect service signals to an observability backend. Those components need addresses, credentials, deployment, and failure policy. Kratos gives them common interfaces; it does not operate the registry, certificate authority, trace collector, or configuration store.
What happened when we ran it
Our run at commit 668db92 installed 53 Go packages in 27 seconds and completed the build in 45 seconds. The test command finished in 27 seconds with all 44 packages passing and 0 failing. Among these seven reviews, Kratos was the only runnable repository whose measured test suite finished with no failures.
The checkout contained 465 files, about 45,874 lines of source, and occupied 6.5 MB. It had 6 CI workflow files, no Dockerfile, and no dedicated tests directory. Tests living beside Go packages are normal, so the missing top-level directory is not evidence of missing coverage. The 44-to-0 result is the evidence that matters for this commit and sandbox.
Our 3-CPU, 8 GB fresh Debian container measured the framework repository, not a generated service connected to gRPC clients, a registry, or telemetry. No credentials or external services were required for this lab path. A production evaluation should generate one representative API, exercise both transports, force middleware errors, and verify shutdown plus dependency failures.
Version 3 makes the upgrade boundary explicit
Release v3.0.0 shipped on 2026-06-26 and labels its module update a breaking change. The README says v3 reduces core dependencies and turns previously implicit behavior into explicit choices. Existing v2 applications should use the dedicated migration guide rather than changing the module path and waiting for compiler errors to reveal behavioral differences.
The release added standard-library error wrappers, HTTP streaming deadline controls, google.api.HttpBody responses, generic configuration reads, JWT parser options, custom validators, and new HTTP error mappings. Fixes covered transport mutation, hot-reload file events, config watcher panics, histogram names, service names, and registry clients. That is a broad service boundary, and each adopted component deserves an integration test.
Contrib versions can diverge. Issue #3861 reports that the v3 registry module used Nacos SDK v2.3.5 while the configuration module used v1.1.6; a subsequent pull request updates the config side to v2. This specific mismatch may move quickly, but it shows why a team should lock the complete module graph instead of assuming the Kratos major version settles every integration version.
Bind errors and metadata have current fixes in review
Issue #3815 says HTTP bind errors bypassed the middleware chain, so logging, tracing, and recovery did not execute for that path. Pull request #3877 changes bind errors to pass through middleware. Another current fix percent-encodes non-ASCII metadata for transport headers, and a separate change supports array values in forwarded gRPC headers. These are the sort of boundary cases a dual-transport framework must handle consistently.
Repository health looks good. Kratos v3.0.0 was followed by code and review activity through 2026-08-25, while the last repository push was 2026-08-19. GitHub listed 107 open issues and pull requests together. The project has 25,891 stars, an MIT license, English and Simplified Chinese READMEs, a documentation site, examples, a layout repository, Discord, and WeChat channels.
Kratos is an easy technical recommendation for a Go service fleet that accepts its Protobuf and generator choices. Our 44-package clean run supports the source quality claim more directly than stars do. For one HTTP service, use Gin or plain Go. For an AI system, use Kratos only as the service chassis, then evaluate the model and data layers separately.