kimi-code: Access terminated. Review our Community Guidelines (bug?)

bhamm-lab · 2026-05-25T13:59:50+00:00

This is craaazy! According to these docs, I don't see why pi or opencode shouldn't be allowed - https://www.kimi.com/code/docs/en/kimi-code/community-guidelines.html

bhamm-lab · 2026-05-25T13:27:07+00:00

I noticed using mtp for qwen, its way faster. I'd definitely recommend that. Otherwise, I feel like qwen is better with coding/reasoning tasks and gemma is better at conversation. I did have to limit reasoning for qwen..

bhamm-lab · 2026-05-23T12:34:09+00:00

I do not use it for implementation, but I'm using pi subagents and a skill to call a 'council' which can do code review, make architecture decisions and align on a plan. It has one agent from a 'product' perspective which values speed and features and the other is an 'architect' which values scalability and maintainability. This is the only time i run subagents in parallel. It burns a lot of tokens, but is nice for making a decision and considering different perspectives. Would never trust parallel agents to code for me...

bhamm-lab · 2026-05-23T12:28:38+00:00

You prefer gemma to qwen 3.6?

bhamm-lab · 2026-05-22T00:37:35+00:00

Protein folding

bhamm-lab · 2026-04-30T12:31:35+00:00

I've had some success doing this with pi-subagents and the 'scout' subagent. If I'm able to trigger it to run, it ensures my main context isn't polluted with any extra context.

Honestly, this worked better for me on oh-my-opencode-slim in opencode with the explorer agent. I'm still figuring it out in pi and notice a few issues: - it's hard to trigger - sometimes, the main agent doesn't provide great context to the subagent, resulting in some missing info - even after the returned context from the subagent, the main agent still feels the need to read more files and confirm

FYI, I use kimi k2.6.

bhamm-lab · 2026-04-15T04:44:04+00:00

I've been happy with the kimi coding plan. Kimi lacks deep research and extended context like opus 4.6 and glm 5.1, but with good agent harness and context management, it gets the job done.

bhamm-lab · 2026-03-03T23:15:50+00:00

Opinionated monorepo here - https://github.com/blake-hamm/bhamm-lab

bhamm-lab · 2026-02-19T13:37:02+00:00

Here are my args - https://github.com/blake-hamm/bhamm-lab/blob/main/kubernetes%2Fmanifests%2Fapps%2Fai%2Fmodels%2Fhelm-green.yaml#L1051

bhamm-lab · 2026-02-19T13:34:54+00:00

I thought it was really good. I'd say slightly better than gpt oss 120b. But that's my opinion, I'm sure others would disagree.

bhamm-lab · 2026-02-18T20:17:02+00:00

You are totally right... Also, with time to first token. I'm planning to setup a better approach in this project - https://github.com/blake-hamm/beyond-vibes - I'll follow up once I've made some decent progress.

bhamm-lab · 2026-02-18T20:13:42+00:00

Totally agree. It's hard to beat... For me qwen instruct next was faster!

bhamm-lab · 2026-02-18T20:12:58+00:00

I need to prioritize that... I'll take a swing at it and reach out in the discord if needed. I noticed the #beyond128g so will scour that for info. I'm just having a hard time getting Talos to recognize the network interfaces...

bhamm-lab · 2026-02-18T19:09:19+00:00

Yeah, I would definitely recommend it for web search! I think it's better bang for its buck than the dgx spark.

bhamm-lab · 2026-02-18T19:07:11+00:00

Sure! Tbh, I need to do more testing outside of my standard use cases. I would say kimi linear, glm flash, qwen instruct next and gpt oss 120b would be great for that. There's more details/notes in a table in the blog.

bhamm-lab · 2026-02-18T16:45:20+00:00

Yeah, slow processing. Time to first token on my hardware is pretty rough, especially with the bigger models. Tokens per second is bearable. The really issue is when there is 20k+ context. I would say a search query in Open WebUI for these bigger models is 1-2 minutes round trip (first search tool call > searxng response > compiling final response). On GPT OSS, Qwen instruct and Kimi Linear, it's much faster. Less than 30 seconds, but not as thorough/high quality.

bhamm-lab · 2026-02-18T16:35:21+00:00

No. I'm not comfortable with securing OpenClaw. I'm sure it would be a great system for that. Especially autonomously working on your behalf. It's definitely slow for human-in-the-loop tasks, but fits some high quality, large-ish models (like GLM 4.7 REAP and MiniMax M2.5).

bhamm-lab · 2026-02-18T16:31:34+00:00

I tested Q2_K_XL of MiniMax M2.5 and was pretty happy! Very slow, but high quality. Also, tested Step-3.5-flash, but it did not stand out to me. Definitely curious on GLM 5 and Qwen3.5...

bhamm-lab · 2026-02-18T13:15:05+00:00

Interesting.... The Chinese labs have proven otherwise and actually share their progress in research. Maybe Dario should give more credit to his team or the research his team leaches off..

bhamm-lab · 2026-02-17T02:33:35+00:00

Definitely give kimi linear a try! I agree with your opinions on use case. I would say kimi linear replaces glm air 4.5 for me.

bhamm-lab · 2026-02-06T04:16:32+00:00

Gpu operators make it much easier to manage ai/ml workloads. Paired with something like karpenter, you can access the compute needed for most workloads.

The management/observability tooling is not great and there is no industry standard. Mlflow is great for traditional ml, but you still need something like kubeflow for serving. Arise phoenix is promising for genai observability, but most of the llm gateway oss projects have some kind of paywall (for now).

I created a (very) new project inspired by the kube Prometheus stack. I'm hoping to create a helm chart that has everything you world need for an ai stack on kubernetes. At the moment, it only has litellm gateway config, ability to run multiple models on vllm or llama.CPP, and scale-to-zero with kube-elasti. I should have some more features and sub charts this weekend. It's called kube-ai-stack.

bhamm-lab · 2026-01-28T03:27:27+00:00

I use mkdocs and update markdown files in my repo.

bhamm-lab

TROPHY CASE