Kimi Code + Headroom field test: managed OAuth routing workaround and early K3-256k results

[pulmhealth]

I spent some time testing Headroom 0.36.2 with Kimi Code/K3-256k on a real data-governance workload and ran into an interesting routing issue with Kimi’s managed OAuth provider. I eventually got it working and thought the results and workaround might be useful to the team and anyone else testing Kimi.

My setup

Ubuntu 24.04
Headroom 0.36.2
Kimi Code 0.38.0
Model: K3-256k
Headroom mode: cache

I originally launched Kimi using:

headroom wrap kimi --port 8788 --kimi-api-url https://api.kimi.com/coding/v1

The wrapper showed:

KIMI_BASE_URL=http://127.0.0.1:8788/...

but Kimi requests were not actually reaching the Headroom proxy.

/stats showed zero model requests and only my own GETs to /stats.

I eventually traced this to the Kimi managed provider in ~/.kimi-code/config.toml:

[providers."managed:kimi-code"]
type = "kimi"
base_url = "https://api.kimi.com/coding/v1"

My K3-256k model was explicitly bound to that managed provider, so it appears the configured provider URL was taking precedence over KIMI_BASE_URL.

I created a separate provider in an isolated Kimi profile that reused the existing OAuth reference but pointed base_url to Headroom:

[providers."headroom-kimi"]
type = "kimi"
base_url = "http://127.0.0.1:8788/p/opt/v1"

[models."kimi-code/k3-256k"]
provider = "headroom-kimi"
model = "k3-256k"

After reloading the Kimi config, routing immediately worked.

Headroom then showed:

POST /v1/chat/completions
model: k3-256k
requests: 1
failed: 0

So there may be an opportunity for headroom wrap kimi to detect a Kimi managed provider and either override/clone its configured base_url, or at least warn when KIMI_BASE_URL will not affect the selected model.

Controlled test

I also ran a small controlled real-world test after establishing a baseline.

Baseline

Requests:        1
Before tokens:   21,829
After tokens:    21,015
Tokens saved:       814

After a bounded document-analysis task

Requests:        4
Before tokens:  101,357
After tokens:    98,023
Tokens saved:     3,334

Test-only delta

Requests:         3
Before tokens:   79,528
After tokens:    77,008
Tokens saved:     2,520

Effective reduction: 3.17%

What was more interesting to me than the raw compression percentage was the cache behavior.

For the three workload requests:

Cache-read tokens:       68,096
Uncached input tokens:    8,912
Cache-hit requests:         3/3
Request hit rate:           100%
Token cache hit rate:       88.4%
Cache busts:                   0

Headroom overhead also dropped considerably after the first request:

~460 ms
~8 ms
~6 ms

So for this workload, I’d characterize the result as modest compression, very good prefix-cache preservation, and effectively negligible proxy overhead once warm.

One thing I’m still trying to understand: Kimi token accounting

For example, an individual request reported:

input_tokens_original:  29,666
input_tokens_optimized: 21,339
tokens_saved:               892

The difference between original and optimized is much larger than the credited tokens_saved.

At the aggregate level, however:

proxy_total_before_compression
tokens.input
proxy_compression_saved

reconcile correctly, so I used those fields for the 3.17% calculation.

Is that difference expected because the input_tokens_original value includes tool/schema material that is treated differently in Headroom's savings accounting?

Overall

Overall, this has been a positive test. Kimi K3-256k is now successfully running through Headroom, output quality held up well, and cache behavior looks particularly good.

Happy to provide sanitized /stats output or test the Kimi wrapper behavior further if it would be useful.****