Problem with most current "native" Spring AI's with ZK is that they cannot mex without doing some ZK-specific things.
This is because ZK is very nazi about where you can place mex: one pixel off, and your order is shot on spot, without trial.
To confound the poor bots further, metal spot detection algorithm used by ZK is not the same that bots use (which is bundled with Spring).
The ZK algorithm detects middles of metal spots, while Spring algorithm detects their top left corner - which causes the bots to fail at placing mex.
And if that wasn't enough, ZK extractors are not extractors in Spring engine sense of way, they are completely Lua-driven. Bots that are designed to detect mexes in TA-like Spring games simply gloss over them and never find anything that "exctractsMetal".
---
If you use engine version 97.0.1-135 or later, Shard should work for you quite well. It's not really smart, but it has a pretty thick chance of beating CAI on most maps due to recent addition of a config that lets it spam most OP things. And also because it's a maphack-using AI, while CAI plays fair.
Additionally there exist
three (one maphacking, two fair) different Java WIP AI's that can play ZK while beating both CAI and Shard. Those, however, not only require having a modern engine (again, anything newer than 97.0.1-135), but also one has to acquire a Java AI Interface which is not currently automatically built by Spring buildbot.
---
All those bots are not synced: unlike CAI, only one player has to have them to make them work. So you could occasionally spectate them on Friday evenings when there's some testing-in-anger bonanza.
---
As mentioned above, you have to use a non-ZKL lobby to deploy these bots. Weblobby is suggested as a more humane alternative, but Springlobby should work too.
---
Mandatory picture. I apologize for it not being gif. The picture displays a 2xCAI vs 1xZKGBAI game on CCR. ZKGBAI is teal. CAI are holding off. ZKGBAI has 500 solars.