Opinion: Kimi's refusal to do certain tasks is more frustrating than helpful.

I've been testing Kimi for about a month now, mostly to see if it could help with on-call fatigue—maybe drafting postmortem summaries, parsing weird log snippets, or suggesting alert rule tweaks. Sometimes it's brilliant at extracting signal from noise.

But I've hit a consistent wall: its refusals. It's not about safety; it's about practicality. Last week, I had a fragmented error message from a legacy system. I asked Kimi to "write a Prometheus alert rule that triggers when this pattern appears more than 5 times in 2 minutes." Instead of giving me a rough draft I could adjust, it refused, stating it couldn't generate code for systems it didn't have specifics on. I wasn't asking for production-ready code—just a starting point. I had to go dig through old docs myself at 3 AM.

Compare this to how we build dashboards for night shifts: you give the on-call engineer something actionable, even if it's incomplete. A graph with a wonky query is better than a blank screen because you can iterate.

Here’s what that rough alert rule could have looked like—something to tweak:

```yaml
groups:
- name: legacy_errors
rules:
- alert: LegacySystemErrorSpike
expr: rate(legacy_system_errors_total{pattern="your_pattern_here"}[2m]) > 5
for: 0m
labels:
severity: warning
annotations:
description: "High frequency of legacy error pattern detected."
```

That’s a five-minute conversation starter, not a final config. Kimi’s insistence on perfect context before engaging leaves you stranded when you need a rubber duck the most. It prioritizes avoidance of being wrong over being useful, which is the opposite of what you need during an incident.

Has anyone else found workarounds for this, or have you just switched contexts when you hit these walls?

zzz