leonickson

no Anthropic involvement, I just used Claude Code heavily while building this and putting that in the README felt more honest than not mentioning it. Now that I think about it may be it shuld be "built with claude code" instead of "built in collaboration...". Changed it.

It's tunable, --cache-gb N on the CLI. In my sweep the speed barely moved between a 1GB and 6GB cache (43% vs 70% hit rate, same tok/s) because right now the bottleneck is GPU dispatch, not the SSD. so more RAM doesnt buy much yet. once the kernel work lands it should start to matter, so on 32GB I would just set 8 and let it age well. Also the hit rates themselves answer the "can you even know which experts stay hot" question, reuse across tokens is very real.

agree, prefill is the weak spot right now. it goes through the same per-token path as decode, which is dumb for long prompts. The fix is on the list: during prefill we can batch the expert reads for the whole prompt per layer instead of per token, that amortizes the IO a lot. until that lands, honest answer is this is good for chat-length stuff, not for feeding it a 10k token document.

Thanks

It is free, for higher limits you have to sign up. Thanks.

I have updated the terms, and all the community submissions are under MIT.

Thanks! From what I've seen, LLMs confidently generate SwiftUI that looks off from what you want on the first try, then you're spending a couple of rounds getting it to fix it. I am just making it easier. These are all real, compiled, and Simulator-rendered, so you start from something that actually builds. The MCP just hands them to your agent so it composes from working components instead of guessing.

Also, this is community based, if you have some awesome components and would be happy to share. Please do so. Thanks

Yes, DCR is supported (WorkOS exposes the registration endpoint). What error is Aperture throwing? I suspect a metadata-discovery detail.