[mikicvi]

The engine already reports per-request prompt/decode timings, conversation-cache reuse and draft counts on its DONE line, but those numbers stayed inside server.py. This emits them everywhere the usage object already goes, in llama-server's dialect — a top-level timings object on the final streamed chunk, the non-streaming response, and the Anthropic message_delta:

"timings": {"prompt_n": 10597, "prompt_ms": 22683.0, "prompt_per_second": 467.3,
            "predicted_n": 64, "predicted_ms": 3248.0, "predicted_per_second": 19.7,
            "cache_n": 0, "draft_n": 59, "draft_n_accepted": 32}

(cache_n/draft_* only when the engine reported them.)

Why: proxies and monitors that chart per-request prefill/decode speed read exactly this shape — llama-swap's activity log (the llama-server, vLLM and TabbyAPI dialects it accepts), and anything else that already understands llama.cpp responses. Without it, Strata requests show token counts but unknown rates. Nothing else changes: fields are additive, and clients that don't know timings ignore it.

Verified end to end through llama-swap v257: streaming and non-streaming /v1/chat/completions, and /v1/messages, all produce activity rows with prefill/decode rates, cached-token counts on reused prompts, and draft acceptance — e.g. a 10.6k-token request charts PP 467 t/s, decode 19.7 t/s, drafts 32 of 59 accepted.

[Niko1221]

Thanks @mikicvi - #107 covers the same timings block (plus cached tokens and /v1/status), so I merged that one and added your draft fields (draft_n, draft_n_accepted) to it, credited in the commit. I'll close this one when 0.1.23 is out.

[Niko1221]

Closing: #107 (merged for 0.1.23) carries the same timings block, with your draft_n / draft_n_accepted fields added and credited. Thank you @mikicvi!