TLDR: Cezar is ⚡️🚀
On Friday morning I only knew that Cezar existed. By Saturday night I had a dozen or so worktrees, a herd of agents, a string of pull requests headed upstream, and Cezar building… Cezar itself.
That is roughly what my weekend at the Open Mercato hackathon in Wrocław looked like.
I am not going to pretend this is an objective post. After two days of heavy use, I think Cezar is one of the most interesting tools I have discovered this year.
First - what exactly is Cezar?
Cezar is an open source orchestrator for coding agents.
Instead of opening five terminals and five Codex sessions and trying to remember which agent is doing what, you get a cockpit for running many tasks in parallel.
Every task can get its own Git worktree. Tasks can work in parallel. Extra tasks wait in the queue. You can use Claude Code, Codex, OpenCode or pi, build workflows in YAML, wire up checks and watch the agents work live. There is no separate database either - Cezar keeps its state in ordinary .ai/cezar/ files.
The most interesting part, though, begins when an agent can delegate work to further agents.
That mechanism is Dispatch.
In broad strokes:
Human
↓
Lead agent
├── child agent
├── child agent
├── child agent
└── child agentThe lead receives a larger task, breaks it down and delegates smaller pieces to its children. The children work in parallel in their own worktrees, and the leader collects the results.
Sounds great.
Until you start wondering:
how many of those children can we actually run safely?
The problem showed up on its own
While using Cezar I quickly reached a point where delegation was at once its greatest strength and a potential problem.
If one agent can launch several more, and each of them does real work on the same machine, you need more than a simple “run the next task”.
You need control over scale. Patryk, one of Cezar’s co-creators (https://github.com/pat-lewczuk), pointed me toward the real problem on Saturday evening: measurement and autoscaling. I dropped the feature I had been building that day, because telemetry and adaptive control simply had more value.
The first step was therefore a simple mechanism:
Max running dispatched tasks
A human sets a hard limit on how many Dispatch-launched tasks may run. If the limit is 4, the fifth child does not start immediately. It waits in the queue.
Ordinary tasks are not blocked by this.
That matters, because a manual limit is simple, predictable and leaves the last word with the operator.
I did not want to remove it later.
Quite the opposite - it became the foundation for what came next.
OK, but how much can this machine actually take?
When I started thinking further about limiting agents, an obvious question came up.
How is anyone supposed to know whether to set 2, 4, 8 or 16?
That is how the next piece came about - live Machine telemetry.
A card appeared in Resources showing, live:
CPU, memory, load average, the core count and a short CPU trend.
No Prometheus.
No Grafana.
No extra telemetry agent.
No database.
Just the current state of the machine.
And even that alone was very useful to me.
Except that a far more interesting problem showed up a moment later.
The host says one thing, the container another
The first version of the telemetry showed host resources.
On an ordinary machine that is fine.
But Cezar is very well suited to running on VPSes, sandboxes and containers. And that is where things get tricky.
The host may have:
24 CPU
58.5 GB RAMwhile the Cezar process may really have:
2 CPU
1 GB RAMIf the scheduler only looks at the host, everything looks great.
“Relax, we have 58 GB of RAM.”
Meanwhile the container is just about hitting its own 1 GB.
That was the moment a plain telemetry widget started turning into something far more interesting.
I added cgroup detection and effective capacity.
If the process runs with cgroup limits, the Machine card shows the resources that actually apply to that process. Host totals stay visible as context only.
So on a single screen we see:
effective:
2 CPU
952 MB / 1 GB
host:
24 CPU
58.5 GB RAMAnd suddenly we have information we can genuinely make decisions on.
Fine. So Cezar can see machine pressure…
…which means it does not have to merely display it.
It can react to it.
And this is where my favorite part of the project begins.
On top of the manual cap I added an adaptive admission governor.
The rule is very simple:
the human sets the maximum; the automation can only reduce that limit.
The manual limit does not disappear.
If I enter:
Max dispatched tasks = 8then 8 is a hard ceiling.
The governor cannot say:
“you have plenty of free RAM, so I will let 14 through”.
No.
What it can do is see memory pressure and say:
“you set a maximum of 8, but right now it will be safer to admit 4”.
That, to me, is the right human-in-the-loop model.
human ceiling
↓
effective machine capacity
↓
adaptive governor
↓
dispatch admission8 -> 4 -> 8
The best part is that this is no longer an architecture diagram.
It works.
For the test I ran Cezar in a container with:
2 CPU
1 GB RAMThe manual Dispatch limit:
8On a calm machine:
Dispatch admission: normal - 8 of 8Then we load the container’s memory.
The Machine card climbs to around:
952 MB / 1.0 GBand the governor moves to:
Dispatch admission: elevated - 4 of 8So it does not change the user’s configuration.
It does not stop children that are already running.
It simply admits fewer new tasks.
When the memory pressure disappears and the system stays calm for a moment:
4 -> 8We are back to normal admission.
And that is when I thought:
OK, this widget is not a widget anymore.
It has become an entry point into the orchestrator’s control loop.
Build Cezar with Cezar
The most meta part of the whole story?
Most of this work was done using Cezar itself.
One development tree went through 27 tasks:
1 lead
8 implementation
15 review
3 researchUp to 5 agents worked in parallel, and at one point I had 14 worktrees.
One agent implemented a piece.
Another reviewed it.
Another did QA.
Reviews were able to find real problems, the implementation got fixed, tests were re-run, and only then did the change land in a PR.
In one case the review caught a really nice detail - the sparkline showed host CPU %, while the number next to it already represented the container’s effective CPU.
A small thing.
Except it is exactly such small things that make telemetry stop being trustworthy.
Fix, test, new screenshot, on we go.
That is probably the biggest thing I took away from this weekend.
It is no longer only about “AI will write my code”.
More like:
idea
↓
lead agent
↓
dispatch
↓
worktrees
↓
implementation
↓
review agents
↓
QA
↓
human
↓
PRThe factory works.
The human still stands by the red button. 😎
My first weekend as an open source contributor
For me personally, this hackathon was also my first serious step into working on someone else’s open source project.
Fork.
Branches.
Spec PR.
Implementation PR.
Review.
CLA.
Rebase.
Conflicts.
Upstream.
More fixes.
And somewhere in the middle of all that, the moment:
“holy crap, my code is actually sitting there as an open PR in a project I use”.
That feels very different from building yet another side project of your own.
Here the solution has to fit more than your own workflow.
It has to fit the existing architecture, the project’s philosophy and the people who will maintain it later.
Where does Open Mercato fit into all this?
The hackathon was organized around the Open Mercato ecosystem.
Open Mercato is an open-source foundation for building CRM, ERP and commerce systems in TypeScript. The project provides ready-made architectural decisions and foundations such as multi-tenancy, RBAC, events and domain modules, so that both developers and coding agents do not have to reinvent the basics of the system every time.
Cezar grew out of that ecosystem.
And after this weekend I understand much better why.
If you really want to build software with many agents in parallel, the problem very quickly stops being:
“which model is the best?”
It starts to sound like:
how do I manage all of it?
Queue.
Worktree.
Delegation.
Review.
Budgets.
Resources.
Admission control.
Human-in-the-loop.
And that is exactly where Cezar gets interesting.
What comes next?
As I write this, my changes are still open PRs waiting for upstream review.
And that is how it should be.
Open source is not git push --force to production. 😉
Regardless of how many of these things eventually land in main in exactly their current form, I already know one thing:
Cezar stays in my workflow.
⚡️🚀
EDIT - 21:25, 21 Sep 2026
PS. The secret sauce for operating the factory floor at capacity is the Open Mercato skills collection:
https://github.com/open-mercato/skills
I was very lucky to have the chance to watch Piotr Karwatka’s live coding session at the Open Mercato Hackathon in Wrocław on Saturday, 19 Sep 2026.
The recording is available here:
https://www.youtube.com/watch?v=VEy3JOwH_ew
It is in Polish only for now.
Piotr is a co-founder of Open Mercato and one of the co-creators of Cezar:
https://github.com/pkarw
Pull requests from the hackathon
- #1033 - spec: dispatch admission cap
https://github.com/open-mercato/cezar/pull/1033
- #1034 - implementation: dispatch admission cap
https://github.com/open-mercato/cezar/pull/1034
- #1035 - spec: live host resource telemetry
https://github.com/open-mercato/cezar/pull/1035
- #1036 - implementation: Machine card / host telemetry
https://github.com/open-mercato/cezar/pull/1036
- #1041 - spec: effective capacity / cgroup-aware telemetry
https://github.com/open-mercato/cezar/pull/1041
- #1042 - implementation: effective capacity
https://github.com/open-mercato/cezar/pull/1042
- #1043 - spec: adaptive admission governor
https://github.com/open-mercato/cezar/pull/1043
- #1044 - implementation: adaptive admission governor
https://github.com/open-mercato/cezar/pull/1044
Cezar repository: https://github.com/open-mercato/cezar
Open Mercato: https://github.com/open-mercato/open-mercato