The JasperFx AI Skills are already updated with content to help you upgrade quickly to our new versions.

The Critter Stack 2026 releases that I first mentioned a couple weeks ago have all hit Nuget — and in some cases might already have bug fix or even a small enhancement release since that major version release. It’s not a huge release at all, but it helps makes systems built with the Critter Stack tools potentially more performant, puts the technical foundation in a bit better place, and positions our tools to be much more usable within Serverless scenarios.

The major goals of this release wave have been to:

• Optimize the “cold start” time of both Marten and Wolverine (Polecat was purposely built with somewhat different internals and less flexibility than Marten to have an optimized cold start time from the get go) with the goal of making the tools better for Serverless applications, dynamic scaling, and just having faster cycle times in local development
• Believe it or not (I was pleasantly surprised), it’s now possible to compile applications using Marten, Polecat, and/or Wolverine with AOT compliance (there’s a catch or two of course)
• Reduce the technical duplication between Marten and Polecat with the hopes of having less code to support in general and improving Polecat’s usage by relying more on proven internals from the much older Marten
• Smuggle in a lot of new observability in the internals for CritterWatch usage soon
• Establish what had been recommended “opt in” configurations as the new defaults for better greenfield development with Wolverine and especially Marten

I don’t have final numbers, but there was an attempt to make some performance improvements to the internals of all the tools along the way. I’ll publish some benchmarking by the end of this coming week.

There will inevitably be problems with these new releases — and there’s already been a couple reports related to the projection changes in Marten that have been addressed so far. My attitude about this never ending stream of bug reports is summed up by the great philosopher of my youth, Vanilla Ice:

“If there was a problem, yo I’ll solve it” (or Babu or Anne or someone else active in the community will).

I’ve got to tell you that I love that the open issue and pull requests count across the entire Critter Stack is very low (single digits as I write this) and I’d like to keep it that way going forward, so we’ll just try to jump on whatever comes in.

Alright, on to some details:

Marten 9.0

The first change and most important change is that Marten 9.0 completely eliminated all usage of the runtime code generation that Marten has used since the 4.0 release in 2021. There’s still just the tiniest bit of FastExpressionCompiler usage for being able to read or write identity values to persisted types, but no other code generation. That’s where the cold start improvement happened for Marten 9.0. That also got us a lot farther along to the AOT compliance.

The conventional projections like this:

public sealed record QuestParty(Guid Id, List<string> Members)
{
    // These methods take in events and update the QuestParty
    public static QuestParty Create(QuestStarted started) => new(started.QuestId, []);
    public static QuestParty Apply(MembersJoined joined, QuestParty party) =>
        party with
        {
            Members = party.Members.Union(joined.Members).ToList()
        };
    public static QuestParty Apply(MembersDeparted departed, QuestParty party) =>
        party with
        {
            Members = party.Members.Where(x => !departed.Members.Contains(x)).ToList()
        };
    public static QuestParty Apply(MembersEscaped escaped, QuestParty party) =>
        party with
        {
            Members = party.Members.Where(x => !escaped.Members.Contains(x)).ToList()
        };
}

Got a maybe significant performance boost as we adopted a purely source generator approach around the conventional methods in place of our previous FastExpressionCompiler approach that didn’t build up the most efficient possible code by any means (FEC was not the problem by any means). Your experience will vary of course, and I expect that to probably be the biggest issue with the release just because of the sheer possible permutations of usage, but I think these changes will ultimately be beneficial for performance.

Marten 9.0 also adjusted some of the out of the box defaults and corrected what I think is “Marten’s original sin” (identity map enabled by default) when we were purposely building Marten at first as a drop in replacement for an existing tool way back when. The big changes are:

1. Lightweight sessions (no identity map) are now the Marten default. If you’re building a greenfield system or follow “Critter Stack” best practices and idioms, you’ll see a small performance improvement. If you have very deep call stacks where the same Marten session is getting reused at different times and possibly loading the same entity multiple times, you may want to explicitly enable identity sessions by default.
2. The event store append mode is “quick append with server timestamps” by default. The performance and even reliability benefits are so great that we made this the new default

See this section of the migration guide for more information.

There is a set of new features coming for Marten in the next week around truly massive scalability of the event store for a JasperFx Software client but I didn’t want to hold up the Marten 9.0 release for that other than making some internal changes that will enable what we’re going to try to do.

Polecat 4.0

Polecat 4.0 benefits from all of the shared changes in the projections library with Marten and now shares far more internal guts with Marten. Polecat 4.1 that should be out before you read this post will also tighten up some error handling to be more consistent with proven patterns in Marten.

Wolverine 6.0

Wolverine 6.0 was a smaller release in terms of what users will notice. The release mostly revolved around the changes in the underlying dependencies, the AOT compliance, and cold start improvements. The runtime code generation with Roslyn is still there (and not going anywhere folks, not without Wolverine becoming a completely different tool anyway), but the JasperFx.RuntimeCompiler can now be just a development time dependency if you want so that you can have a much smaller deployed image. This again is part of the long standing plan to get around to having a better Serverless story for Wolverine.

I also smuggled in quite a bit of extra observability meant for CritterWatch, and we’ll hopefully show that off soon!

There’s a couple features still in the back log, with maybe an upcoming integration with job schedulers like Quartz.Net or TickerQ. Then a much bigger story for improving the usability of Wolverine with F# (more or less, being able to generate F# code instead of C# code).

JasperFx and Weasel

The baseline JasperFx, JasperFx.Events, and their related source generators flipped over to 2.0. Again, the goals where AOT compliance and improvements to the source generators for Marten & Polecat’s projection support. There was quite a bit of work smuggled into this layer as well for CritterWatch.

Weasel 9.0 did go through an effort to reduce code duplication across the different database engines that it supports, but otherwise just dropped .NET 8.0 and added a little bit of work meant for CritterWatch down the line (dynamic tenancy management).

Babu Annamalai and I have been working very hard on JasperFx Software‘s officially curated AI Skills for the “Critter Stack,” and I’m very pleased to announce today that these skills are officially open for business! Many of our support clients already have access, but as of today anyone interested is able to purchase access to the skills online at https://jasperfx.net/our-products/#ai-skills.

Distribution is done through a private NPM or Nuget repository, and purchasing the skills will give you access to these feeds. For any support, contact us at support@jasperfx.net, use our new GitHub tracker for our products, or contact JasperFx through our Discord server.

To read more about what AI Skills we offer so far, see the documentation website.

And these skills will be curated, meaning that we’ll work to continuously improve and add to the skills. As a matter of fact, there will be a new revision as early as tomorrow to provide AI assisted conversions to the next major releases of Marten, Polecat, and Wolverine.

Pardon the mess, but the Critter Stack 2026 releases are heavily underway in the JasperFx GitHub Organization. Busy enough that I am getting hit with GitHub rate limiting messages the past couple days and I think that’s a good sign about our productivity? It’s also blessedly coincided with a couple very quiet days in the community which has certainly helped too!

The main goals are to:

• Get CritterWatch out the damn door!
• Optimize the “cold start” times across the entire stack, have a better story for “Serverless” usage and, knock on wood, get to AOT compliance. To be clear, this will change the pattern of our previous Roslyn runtime compilation into a development time only thing where pre-generation of Wolverine or Marten types will be mandatory for production usage. And that’s the part I expect to be a little bit controversial or inconvenient.
• Bring Polecat up to par quality wise with Marten. Polecat has had growing pains.
• Adjusting some of our default settings to reflect more optimized usage for greenfield usage, which I mostly outlined in this post. But don’t worry, all of this will be documented in the migration guide, Marten will have a RestoreV8Defaults() and Wolverine is getting a RestoreV5Defaults() to make it easier to stay right were you are. Some of this is getting driven by real efficiency concerns, and other parts are purposely meant to enable CritterWatch management and oversight of production applications.

This wave of releases is going to include:

1. JasperFx and JasperFx.Events 2.0
2. Weasel 9.0
3. Marten 9.0
4. Polecat 4.0 (Event Sourcing & Document Db w/ SQL Server)
5. Wolverine 6.0
6. CritterWatch 1.0 – Our white whale, our “Duke Nukem Forever” release, “Winds of Winter” finally coming out so we can find out if Jon Snow survives! Add in Half Life 3 too. No seriously, it’s coming out on May 18th come hell or the river don’t rise.

For some other details:

• There’s plenty of low level performance optimization and object allocation savings happening, but I don’t yet have numbers to know how much difference that’s going to make yet. We will be doing much more benchmarking before the release though
• We’re pulling Newtonsoft references out of the main tools altogether, but replacing the integration with extra extension packages. That feels like the end of an era!
• We’ll do the inevitable work of eliminating [Obsolete] APIs, but I don’t think there’s much
• We’re doing a huge amount of work to promote code sharing between Marten and Polecat, with me hoping that that improves Polecat especially. Some of that is driven by CritterWatch needs. This is also happily reducing code duplication throughout the Wolverine codebase as well.
• .NET 8 support was dropped, but we’re maintaining .NET 9 and .NET 10 for the lifetime of these versions. I realize that .NET 9 is EOL later this year, but I’m not eager to get yelled at for dropping it earlier than some of our users. We’ll add .NET 11 whenever that hits. For anyone wondering why this is a big deal at all, our usage of EF Core means that we do struggle somewhat with diamond dependency conflicts through major .NET versions.
• Marten is getting a more efficient option for “Dynamic Consistency Boundaries” (DCB) using PostgreSQL HSTORE
• There was also a big time round of code de-duplication in Weasel across the database engines that we support

Migration?

Other than some changes to the shape of our MultiStreamProjection types in Marten and Polecat, I’m expecting no other breaking changes except for some public types moving namespaces. I’m confident this time around that we’ll have a comprehensive migration guide that will cover all of those moves in a form that should be helpful for both humans or LLM tools.

If you utilize the new defaults though, there will be database migrations for extra fields and new tables that have been added in the past year or two for enhanced auditing and observability — but all of this will be purely additive.

The previous update on the Critter Stack roadmap was in early March.

I spent some time yesterday writing and thinking about the road map for the Critter Stack. Call this post a mix of me sorting out what I personally think happens next, but mostly asking for feedback and input on these thoughts.

Wrapping up Marten 8 and Wolverine 5

I think we’re pretty close to turning the page on the current versions of Marten and Wolverine. I made a housecleaning effort yesterday to either deal with any outstanding issues or pull requests against the current versions, or to tag issues for the next major milestone.

To that end, a new Marten 8.34 and Wolverine 5.34 release dropped this morning that I’m going to say symbolically marks the current versions of both tools as “done.”

Of course, software tools are never actually completed, only abandoned. At this point though, I think the only enhancements to these versions will be merely reacting to reported issues or client requests that don’t require any breaking changes (or changes for CritterWatch). We’re certainly happy to continue taking in community pull requests, but at least for me, I’m out of any ideas for new functionality right now.

Recent highlights of the two main tools are:

• PostgreSQL Role Level Security support for Marten as part of its Multi-Tenancy (community pull request)
• gRPC Support in Wolverine from core team member Erik Shafer

I also snuck in quite a few minor improvements for the “cold start” with both tools, and that’s going to be a theme of this post.

And I know full well that between the time I write this and you read it that there will be some new kind of bug report like “if I hop up and down on my left foot while pointing at the Big Dipper, I would have expected…” to land. Which we’ll address of course:)

CritterWatch and JasperFx Update

Just speaking personally, I should be putting the majority of my time for awhile pushing CritterWatch to a 1.0 release. We’re also working toward having all the infrastructure in place to allow customers to purchase licensing for CritterWatch and access to our new AI Skills collection on our website. Babu and I have also been very busy doing a complete overhaul of the JasperFx Software website.

At a bare minimum, I’m hoping to have every single bit of functionality in flight today for CritterWatch in a usable and somewhat polished state by the end of this week.

While the sales mechanisms aren’t completely in place yet, you can see the updated pricing online now.

And just so everybody knows, CritterWatch will be available on Nuget, but only usable in a read only way without the presence of a license file.

On to the next cycle!

The next big set of releases will be Marten 9, Wolverine 6, and Polecat 3. The key goals for me are to do everything possible to improve the “cold start” performance of Marten, Wolverine, and Polecat to make our tools much more usable in “serverless” usage and to attempt to ruthlessly remove duplication today between Marten and Polecat.

The big ticket and potentially breaking changes are to:

• Move JasperFx.RuntimeCompiler and its massive dependency on Roslyn to being a development time dependency. We’ve already got a plan underway to allow you to deploy Marten and/or Wolverine applications (Polecat strictly uses source generators instead of our older code generation model) without that dependency so that we can actually do…
• AOT Compliance. I didn’t think this was ever going to be possible before, but it looks like we can pull this off
• We’re going to make a large effort to switch default configurations of the tools to reflect the absolute best performing and monitored application you can have. See Building a Greenfield System with the Critter Stack for plenty examples of the settings I mean. We introduced quite a few improvements to both Marten and Wolverine over the past year that we made “opt in” because using them would require database schema changes. A new major release is always the time to reconsider those defaults. I’m also hoping that AI tools make the converstions and upgrades a lot easier even with these kinds of changes to behavior.
• Dump [Obsolete] APIs of course, but I don’t think there are too many of those floating around anymore
• Drop support for .NET 8, then add support for .NET 11 when that hits later this year. If nothing else, our EF Core support is a nightmare for diamond dependency problems and our multi-targeting makes that much worse. Fewer .NET versions leads to fewer headaches.
• Try hard to eliminate duplication between Marten and Polecat, with more utility and infrastructure code landing in JasperFx.Events or Weasel.Core. I’m hoping that this work would shrink the Marten codebase especially, and open up some opportunities to reduce duplication in Wolverine too. I’m also hopeful that this elimination of duplication can lead to more advanced visualizations and tracking in CritterWatch.
• JasperFx will be working with a client this year for some pretty extreme scalability of the Event Store features in Marten. As part of that, I would like us to pursue using the HSTORE extension in PostgreSQL for more efficient “Dynamic Consistency Boundary” usage and to also pursue using alternative serializers for just event data as some early experimentation with MemoryPack inside of Marten has been very promising.

And just in case anyone asks, I don’t think it’s remotely possible to convert Wolverine to use source generators instead of our current source code generation model.

Bobcat?

This is my rough notes here, so don’t take any of this too seriously.

I haven’t talked about this much, but I’ve been playing a bit with a new Gherkin test runner tentatively called “Bobcat” half inspired by Storyteller (https://storyteller.github.io). What’s different about Bobcat from Reqnroll is much more focus on data intensive testing, and making it more CLI friendly purposely to create visibility on runtime activity so AI agents could iterate on the test execution results. This is my current thinking for “Spec Driven Development” w/ the Critter Stack as opposed to a quixotic attempt to do anything with user interface centric tooling.

So for example, if your spec calls through the Wolverine tracked sessions, the test output would have information about every exception encountered and the full messaging history on test failures. The test output itself is written to the CLI too where AI tools can scrape it. 

I’ve already played w/ built in helper packages for Alba and the Wolverine tracked sessions. Also trying to think through how Bobcat could be optimized for real integration testing where you have to juggle Docker dependencies and `IHost` lifecycles. 

To some degree, Bobcat is maybe just what I’ve always wanted to test the Critter Stack tools themselves.

I’m also thinking about how to make Bobcat + AI skills drive Spec Driven Development w/ the Critter Stack. So accelerators build the Gherkin runners based on event types and projection types. Then being able to generate code from the Gherkin specs. I’ve been watching a couple other event sourcing toolsets and how they’re trying to do Access 97 style user interfaces to “model” event sourcing workflows and have yet to see anything out there that would be faster than just writing C# or F# event types and maybe even the projection types themselves. My thought is just to lean on our existing code tools and build generators to quickly translate from C#/F# types to Gherkin syntax. I’m also hoping we can leverage the existing Gherkin language integration in Rider or VS Code rather than building something all new.

And lastly, I’m not opposed to trying to make this work with Reqnroll in the end.

All of this sample code is checked in on GitHub at https://github.com/JasperFx/CritterStackSamples/tree/main/Reports.

When you develop with Wolverine as your application framework, Wolverine is really trying to push you toward using pure functions for your main message handler or HTTP endpoint methods. Recently, I was reviewing a large codebase using Wolverine and found several message handlers that had to use a simple interface like this one just get the next assigned identifier:

public interface IReportIdService
{
    Task<int> GetNextReportId(CancellationToken cancellation);
}

In their command handlers, they were writing command handlers like this:

public static class StartReportEndpoint2
{
    [WolverinePost("/report")]
    public static async Task<ReportStarted> Handle(
        // The command
        StartReport command, 
        
        // Marten session
        IDocumentSession session, 
        
        // The service just to fetch the next report id
        IReportIdService idService,
        
        CancellationToken cancellation
        )
    {
        var id = await idService.GetNextReportId(cancellation);
        session.Store(new Report{Id = id, Name = command.Name});
        return new ReportStarted(command.Name, id);
    }
}

(the real life handlers were a little more complicated than this because real code is almost always far more complex than the simplistic samples people like me use to demonstrate concepts)

Of course, the code above isn’t very difficult to understand conceptually and maybe it’s not worth the effort to write it any differently. But all the same, let me show you a Wolverine capability to customize the code generation to turn that handler method above into a synchronous pure function.

First off — and shockingly maybe for anybody who has seen me complain about these dad gum little things online — I want to introduce a little custom value type for the report id like this:

// You'd probably use something like Vogen
// on this too, but I didn't need that just
// for the demo here
public record ReportId(int Number);

Just so we can use this little type to identify our Report entities:

public class Report(ReportId Id)
{
    public string Name { get; set; }
}

And next, what we want to get to is an HTTP endpoint signature that’s a pure function where the next ReportId is just poked in as a parameter argument:

public static class StartReportEndpoint
{
    [WolverinePost("/report")]
    public static (ReportStarted, IMartenOp) Handle(
        // The command
        StartReport command, 
        
        // The next report
        ReportId id)
    {
        var op = MartenOps.Store(new Report(id) { Name = command.Name });
        return (new ReportStarted(command.Name, id), op);
    }
}

The MartenOps.Store() thing above is a built in “side effect” from Wolverine.Marten. Many of Wolverine’s earliest serious users were Functional Programming fans and they helped push Wolverine into a bit of an FP direction.

Alright, so the next step is to teach Wolverine how to generate a ReportId automatically and relay that to handler or endpoint methods that express a need for that through a method parameter. As an intermediate step, let’s do this simply and say that we’re just using a PostgreSQL Sequence for the number (I think my client’s implementation was something meaningful and more complicated than this, but just go with it please).

Knowing that our application has this sequence:

builder.Services.AddMarten(opts =>
{
    // Set the connection string and database schema...
    
    
    // Create a sequence to generate unique ids for documents
    var sequence = new Sequence("report_sequence");
    opts.Storage.ExtendedSchemaObjects.Add(sequence);
}).IntegrateWithWolverine();

Then we can build this little extension helper:

public static class DocumentSessionExtensions
{
    public static async Task<ReportId> GetNextReportId(this IDocumentSession session, CancellationToken cancellation)
    {
        // This API was added in Marten 8.31 as I tried to write this blog post
        var number = await session.NextSequenceValue("reports.report_sequence", cancellation);
        return new ReportId(number);
    }
}

And finally to connect the dots, we’re going to teach Wolverine how to resolve ReportId parameters with this extension of Wolverine’s code generation:

// Variable source is part of JasperFx's code generation
// subsystem. This just tells the code generation how
// to resolve code for a variable of type ReportId
internal class ReportIdSource : IVariableSource
{
    public bool Matches(Type type)
    {
        return type == typeof(ReportId);
    }
    public Variable Create(Type type)
    {
        var methodCall = new MethodCall(typeof(DocumentSessionExtensions), nameof(DocumentSessionExtensions.GetNextReportId))
            {
                CommentText = "Creating a new ReportId"
            };
        // Little sleight of hand. The return variable here knows
        // that the MethodCall creates it, so that gets woven into 
        // the generated code
        return methodCall.ReturnVariable!;
    }
}

And finally to register that with Wolverine at bootstrapping:

builder.Host.UseWolverine(opts =>
{
    // Here's where we are adding the ReportId generation
    opts.CodeGeneration.Sources.Add(new ReportIdSource());
});

Now, moving back to the StartReportEndpoint HTTP endpoint from up above, Wolverine is going to generate code around it like this:

// <auto-generated/>
#pragma warning disable
using Microsoft.AspNetCore.Routing;
using System;
using System.Linq;
using Wolverine.Http;
using Wolverine.Marten.Publishing;
using Wolverine.Runtime;
namespace Internal.Generated.WolverineHandlers
{
    // START: POST_report
    [global::System.CodeDom.Compiler.GeneratedCode("JasperFx", "1.0.0")]
    public sealed class POST_report : Wolverine.Http.HttpHandler
    {
        private readonly Wolverine.Http.WolverineHttpOptions _wolverineHttpOptions;
        private readonly Wolverine.Runtime.IWolverineRuntime _wolverineRuntime;
        private readonly Wolverine.Marten.Publishing.OutboxedSessionFactory _outboxedSessionFactory;
        public POST_report(Wolverine.Http.WolverineHttpOptions wolverineHttpOptions, Wolverine.Runtime.IWolverineRuntime wolverineRuntime, Wolverine.Marten.Publishing.OutboxedSessionFactory outboxedSessionFactory) : base(wolverineHttpOptions)
        {
            _wolverineHttpOptions = wolverineHttpOptions;
            _wolverineRuntime = wolverineRuntime;
            _outboxedSessionFactory = outboxedSessionFactory;
        }
        public override async System.Threading.Tasks.Task Handle(Microsoft.AspNetCore.Http.HttpContext httpContext)
        {
            var messageContext = new Wolverine.Runtime.MessageContext(_wolverineRuntime);
            // Building the Marten session
            await using var documentSession = _outboxedSessionFactory.OpenSession(messageContext);
            
            // Creating a new ReportId
            var reportId = await DocumentSessionExtensions.GetNextReportId(documentSession, httpContext.RequestAborted).ConfigureAwait(false);
            System.Diagnostics.Activity.Current?.SetTag("handler.type", "StartReportEndpoint");
            // Reading the request body via JSON deserialization
            var (command, jsonContinue) = await ReadJsonAsync<StartReport>(httpContext);
            if (jsonContinue == Wolverine.HandlerContinuation.Stop) return;
            
            // The actual HTTP request handler execution
            (var reportStarted_response, var martenOp) = StartReportEndpoint.Handle(command, reportId);
            if (martenOp != null)
            {
                
                // Placed by Wolverine's ISideEffect policy
                martenOp.Execute(documentSession);
            }
            // Writing the response body to JSON because this was the first 'return variable' in the method signature
            await WriteJsonAsync(httpContext, reportStarted_response);
        }
    }
    // END: POST_report
    
    
}

And as usual, the generated code is an assault on the eyeballs, but if you squint and look for ReportId, you’ll see the generated code is executing our helper method to fetch the next report id value and pushing that into the call to our Handle() method.

Summary

I don’t know that this capability is something many teams would bother to employ, but it’s a possible way to simplify handler or endpoint code that hasn’t been previously documented very well. Wolverine itself uses this capability quite a bit for conventions.

What I think is more likely, I hope anyway, is that our continuing investment in AI Skills for the Critter Stack is that folks still get value out of these capabilities by either the AI skills recommending the usage upfront or helping people apply this later to continuously shrink the codebase and improve testability of the actual business logic and workflow code.

And because Wolverine has been such a busy project of the type that sometimes throws spaghetti up against the wall to see what sticks, there is another option for this kind of code generation customization you can see here in a sample that “pushes” DateTimeOffset.UtcNow into method parameters.

Lastly, we’re in the midst of an ongoing effort to improve the documentation across the JasperFx / Critter Stack family of projects and you can find more information about the code generation subsystem at https://shared-libs.jasperfx.net/codegen/.