software made during idle cycles.
A loose group of people building things in hobby time, unemployed time, weekends, late nights, or whenever there are spare CPU cycles.
We mostly mess with:
- AI / LLM infrastructure
- developer tools
- agents and automation
- Linux desktop software
- interfaces
- infrastructure
- applied ML research, especially Khmer language technology
- whatever seems interesting next
| Project | What it is |
|---|---|
| Kanade | A top-center Dynamic Island and desktop shell experience for niri, built with Amane. |
| Kinetix | A self-hosted LLM gateway for coding agents and small teams: compatible APIs, routing, fallback, account pools, and usage tracking. |
| Kinetix Plugins | Plugins, SDK, and tooling for extending Kinetix through WebAssembly. |
| Khmer Decision Lab | Reproducible research on lightweight Khmer language understanding, decision models, fine-tuning, and evaluation on consumer GPUs. |
The repositories are at different stages. Some are actively changing, some are experiments, and some may be paused or archived. Check each project's README for its current state.
Not every useful result is an app.
Khmer Decision Lab starts with Khmer intent classification and small decision models. The broader questions include cross-task generalization, OCR robustness, retrieval relevance, calibration, latency, and memory use.
We want research that can be checked: documented datasets and splits, reproducible experiments, baselines, error analysis, and negative results when an idea doesn't work.
A benchmark result is evidence for the task and setup that produced it—not a claim that a model works everywhere.
Most projects here start with some variation of:
"what if we just built it?"
Sometimes that produces a useful tool.
Sometimes it produces a prototype that answers one question and is never touched again.
Both are valid outcomes.
Working software usually teaches us more than discussing hypothetical software.
If something depends on an assumption, test it.
Source code, benchmarks, traces, reproductions, real usage, and measurements beat guesses.
Experiments are allowed to fail.
When something works well enough to keep, we gradually make it less cursed.
A project being public does not mean it is:
- production-ready;
- stable;
- maintained forever;
- backward compatible;
- suitable for your infrastructure.
Check the repository.
Projects move when someone wants to work on them.
Issues and roadmaps describe intent, not contractual delivery dates.
Unless a repository explicitly says otherwise, assume:
experimental — APIs may break, designs may change, dragons possible.
Individual repositories define their own stability, releases, compatibility guarantees, and support expectations.
Bug reports, experiments, fixes, criticism, benchmarks, weird ideas, and good pull requests are welcome.
Repository-specific instructions override the organization defaults.
See CONTRIBUTING.md.
Please don't put vulnerabilities in public issues.
See SECURITY.md.