I just shipped an update with a full openCypher implementation in common lisp graph database Scalaxy (https://scalaxy.org) for the graph engine. Testing against the openCypher TCK is now at 3,898 out of 3,898 scenarios, so 100% coverage.
Next big goal: storing the entire node data in an S3 compatible bucket.
MIT licensed.
I have published my distributed database Scalaxy fully written in Common Lisp. Working on graph query language Cypher right now. MIT license. Github stars are welcome :-)
I have published my distributed database Scalaxy fully written in Common Lisp. Working on graph query language Cypher right now. MIT license. Github stars are welcome :-)
Any one did chargeback on Kimi subscription due to unusable account just after one week of using, even if weekly and daily limits are 100% available after reset?
Hi!
I have Allegretto plan. I've used my Kimi Code weekly usage, then paid $30 for extra credits. Then waited for daily and weekly usage limits resets. After it happened I still receiving this error in Kimi Code:
Server: Error code: 403 - {'error': {'message': "You've reached your usage limit for this billing cycle. Your quota will be refreshed in the next cycle. To continue now, purchase extra usage or upgrade your plan: https://www.kimi.com/code/#pricing", 'type': 'access_terminated_error'}}
It looks like ZFS deduplication is actually working incredibly well when running a local AI coding box fully integrated into the Nix ecosystem from day one. My zroot/nix dataset is reporting a staggering 18.1TB of logical data used, but thanks to a massive 136x deduplication ratio, it actually occupies only about 133GB of physical space. Because the Nix store naturally accumulates highly redundant package variants, generations, and build outputs across multiple development projects, ZFS is catching and compressing the data perfectly, keeping the entire footprint comfortably inside a 1.81TB NVMe pool with 1.19TB total allocated space. For heavy local AI development and native Nix workflows, the storage efficiency gains here are definitely real.
AMD Ryzen 9 7950X 16-Core Processor, 128GB RAM, 2TB NVMe
I am thinking about the idea of an AGENTS.md for a Kubernetes cluster.
Not as documentation for humans only, but as a machine readable guide for AI agents that need to understand how to safely inspect, operate, and modify a cluster.
For a regular Kubernetes cluster, this could describe things like namespaces, controllers, CRDs, ownership boundaries, deployment rules, escalation paths, and forbidden actions.
But I am more interested in the generic kcp version of this idea.
In a kcp style world, where APIs, workspaces, syncers, logical clusters, and tenancy boundaries matter more than a single physical cluster, what should AGENTS.md describe?
Would it be closer to an API contract, an operational policy, a workspace manifest, or something else?
Curious if anyone here has thought about a generic pattern for agent readable cluster context.
per aspera ad astra
