Payload CMS shipped v3.81.0 on 1 April 2026. If you run Payload with Next.js in production, there are a few changes worth understanding before you upgrade.
The headline: an LLM eval suite for Payload code generation
Payload now includes a built-in test suite that measures how well large language models can understand and generate Payload-specific code. It works in two parts.
First, QA evals check whether an LLM can correctly answer questions about Payload’s API and conventions. Second, codegen evals test whether a model can take a real payload.config.ts file and apply a specific change that compiles and actually does what was asked.
The codegen pipeline runs three steps: the LLM generates modified code, the TypeScript compiler checks it builds, then a separate LLM pass scores whether the output fulfils the original intent. That third step matters because code can compile without doing the right thing.
They also test with and without a conventions document injected into the system prompt. This means they can measure exactly how much their documentation improves LLM accuracy when working with Payload projects.
Why this matters beyond Payload
This is one of the first CMS platforms to formally optimise its codebase and documentation for AI-assisted development. If your team uses Cursor, Copilot, or Claude Code to write Payload configs and collections, the accuracy of those suggestions should improve as this eval suite matures.
It also signals where the developer-first CMS market is heading. WordPress, Strapi, and Sanity do not have anything equivalent yet. Teams evaluating headless CMS options should factor in how well the platform works with AI tooling, not just traditional developer experience.
Next.js admin panel fix: cacheComponents
If you run Next.js 15 or 16 with Payload and had cacheComponents enabled, you may have seen admin panel errors or route 404s. This release fixes that. If you deferred upgrading Next.js because of admin instability, this is the version to test against.
Security and stability updates
This release also addresses several dependency vulnerabilities (file-type, ajv, jose packages), adds field-level access control to internal auth fields, and stabilises Postgres read replica support. If you run Payload on Postgres in production, the read replica fix is worth reviewing before you scale.
Multi-tenant improvements
The multi-tenant plugin fix resolves a forbidden error when logging in as a user with no tenant assignment and no access to all tenants. Combined with v3.80.0’s disableUnique slug field option, Payload’s multi-tenant story is getting more production-ready with each release.
Practical upgrade checklist
- Check your Next.js version. If you are on 16.2 or later, update your dev scripts to include
--no-server-fast-refreshfor compatibility. - Review the cacheComponents fix if you had it disabled as a workaround.
- Run
npm auditafter upgrading to confirm the dependency patches landed. - If you use Postgres read replicas, test your read/write split under load before deploying.
- If you run multi-tenant, test the login flow for users without a default tenant assignment.
FAQ
What is the Payload LLM eval suite?
It is a built-in test framework that measures how accurately large language models can answer questions about Payload and generate valid Payload configuration code. It uses TypeScript compilation and LLM scoring to verify outputs.
Does the Payload 3.81.0 update fix Next.js admin panel issues?
Yes. The release fixes errors caused by the cacheComponents setting in Next.js 15 and 16, which previously caused admin route failures and 404s.
Is Payload CMS production-ready for multi-tenant applications?
It is getting closer with each release. v3.80.0 added disableUnique for slug fields in multi-tenant setups, and v3.81.0 fixes a login issue for users without tenant assignments. Testing tenant isolation and access control thoroughly before production deployment is still recommended.
Should I upgrade to Payload 3.81.0 now?
If you run Payload with Next.js in production, yes. The admin stability fix and security patches are worth the upgrade. Test in staging first, especially if you use Postgres read replicas or multi-tenant features.