Can it instruct DeepSeek during an LLM call to start removing old tool calls from the context instead of waiting for the LLM call to finish if the context size approaches DeepSeek's dumb zone? Claude Code can't do that, /compact can only happen after the LLM call; it's often preferable to start cleaning up context during an LLM call, especially when tool calls are huge like reading markdown files; implementation-wise all that is needed is to start removing earliest <tool call start> ... <tool call end> and replacing them just with some log entry stating this tool call was already performed, then re-running KV cache prefill (so the "online" compaction would get 0.5s latency hit every time it's performed). That way one can read 1000 files in one LLM call.

High caching rates for coding agents can drastically reduce latency and API costs. I am curious to see how the caching strategy handles context invalidation across multiple files.

Unusable thanks to the top animation pushing the rest of the site down repeatedly as you’re trying to read.

> Tool-call repair

> Tool arguments the model produces occasionally have JSON typos, unclosed quotes, or shape mismatches. Reasonix runs a schema-aware repair pass before dispatch so malformed args still execute.

So Deepseek API doesn't have a structured output option where you give a grammar and the model promises the output will follow this grammar?

Or it does, but it's buggy?

I would've liked benchmarks against other harnesses showing the caching performance

"byte-stable prefix cache" -- give us your codebase in a way that's even EASIER for us to train on.

Wow the UI looks exactly what I vibe coded yesterday. What a coincidence

Good timing given the cost spike across other frontier models.

Isn't caching a server-side thing? How does the agent affect it, significantly at least?