Because they're thinking like I did going into the article. Harnesses like Claude expose "tools" to the agent. I usually use Cline but I'm giving up on it for this exact reason. Cline tells the model "you tell me to write a file, I'll get it done" and then it messes everything up, causes tones of errors, and the model goes "wow that's a broken tool. I'm going to write a python script to write the file instead"
They said as of aug 23rd it's 100% rollout. I've noticed 0 improvement. If anything a downgrade. The agents often refuse to use the tools after 1 try because the results are so trash. An open ticket that shows my biggest gripe with the write tool https://github.com/cline/cline/issues/13276
I guess the mistake count is down though. But that's because it's bypassing all the tools and just running commands
This also comes with significant capability reduction. deepseek-v4-flash is very good in the < 250K range, then degrades between 250-500K, and is practically unusable after 500K.
[edit]
This is my observation from using it without an specific context engineering to optimize for Deepseek's cache compression and sparse attention mechanisms. I am pretty sure that if you specifically structure your context to align to the cache compression boundaries you can significantly improve performance in the full 1M context, but there is not much reason to do this, because if you design your outer loop to work with shorter contexts that solution is portable and more efficient, so I haven't bothered with a optimizing for DS at this point.
Btw - assuming NeurIPS reviews aren’t garbage tomorrow, I’ll have a paper out which claims that most long context problems in models are really sampling problems in disguise
Switch to a modern sampler like min_p or ideally a better one like top-n-sigma (it’s in llamacpp) and your “my model gets stupid at long context problems” will basically go away.
Unfortunately this fact is still not well appreciated yet despite nearly every modern sampling technique getting an oral wherever they get presented. Min-K just got an oral at ACL 2026, for a hyper recent example of this. There’s a reason they keep getting orals.
The field massively ignored sampling for mostly safety reasons and now the whole field incorrectly believes long context doesn’t work on small models. Long context is an out-of-distribution problem. Your sampler configured properly keeps you in distribution.
Oh and this is doubly true for quantized models. I run my qwen 3.6 27b with 4bit quants from unsloth and get excellent performance because my sampler stack is good and not the garbage that is top_p and top_k. Also, yes, you need to ignore the trash recommended sampler settings from the Chinese labs (they’re wrong/bad).
Interesting. I am not familiar with model internals at this level because I have only been working at the application layer so far, but will definitely research this further. When you get the paper published would appreciate if you can drop a comment with the link so I can read it.
Openrouter's pricing via the deepseek provider is the same as the official deepseek api for both flash and pro and for cached and uncached tokens. It's literally the same api.
And no, cache rates are not different if you're going through the official deepseek provider. The only way caching rates can drop is if you let openrouter fully control routing by preferring uptime or something, and then it might bounce you between providers. But you can control which providers for a given model are in its routing pool and stop that.
Did you read the blog post? They compare to deepswe and call it out as the worst one for false positives (failed, but the benchmark assessed it as correct). It also has less language variance.
This isn't how LLMs work. They aren't self aware like this, they're trained on the general internet. They might have some pointers to documentation for certain cases, but they generally aren't going to have specialized knowledge of themselves embedded within. Claude code has no need to know about its own internal programming, the core loop is just javascript code.
This take sucks. The anticheat software in this context is for competitive games. No one cares about people cheating in isolation in single player games. The anticheat is to stop 1 guy from ruining it for the 9 others he's playing with online.
You can argue about the methods used for anticheat, but your comment here is trying to defend the right to cheat in online games with other people. Just no.
PvE shouldn't need it either, and yet games routinely ship with anti-cheat applied to everything (including single player).
I rather suspect that the reason for this is the current gaming economy of unlockable cosmetics that you can either grind for, or pay for. If people can cheat in single player or PvE, they can unlock the cosmetics without paying. And so...
Multiplayer PvE can still be ruined by cheating. In many such games, such as MMORPGs, you are still competing for resources such as rare spawns.
Spending hours setting up conditions for the rare spawn to appear, and then before you can get to it having someone using a tracking cheat and a speed cheat get to it first is very annoying.
That is not the solution if you want to play competitively of whenever you feel like it.
Kernel level AC is a compromise for sure and it's the gamers job to assess if the game is worth the privacy risk but I'd say it's much more their right to take that risk than the cheaters right to ruin 9 other people's time for their own selfish amusement
Cheating may not be moral but it's better to put up with it than to cede control of our computers to the corporations that want to own it.
If it kills online gaming, then so be it. I accept that sacrifice. The alternative leads to the destruction of everything the word hacker ever stood for.
I'm sorry but you are fighting a crusade you can not win by definition. If I am free to use my computer for anything I want then I am also free to lock it down to enjoy my favorite game. If I care about my freedom I will have a dedicated machine for this game that I accept I will not have control over.
You are hijacking this thread about VOLUNTARY ceasing of freedom as if the small community even willing to install these is a slippery slope to something worse. You have a point when it comes to banking apps on rooted phones and I'm with you on that but this is not the thread for it
Valve drives significant development of compatibility layers for Linux for the sake of gaming. Their customer base is anything but small. There is potential for this kernel stuff to spill into the entire Linux ecosystem. It was bad enough having to deal with nvidia. I really don't want other companies screwing up the kernel.
Realistically I don't see how Valve can avoid this. They want all those games on Steam Deck and the new console. Game devs want KAC. Therefore Valve can either provide them with some way to implement KAC - which effectively requires a "signed kernel / drivers only", same as on Windows - or tell them to go away. Why would they do the latter?
Mind you, it doesn't mean that the Linux kernel will be "infected for everyone". It means that we'll see the desktop Linux ecosystem forking into the "secure" Linux which you don't actually have full control of but which you need to run any app that demands a "secure" environment (it'll start with KAC but inevitably progress to other kinds of DRM such as video streaming etc). Or you can run Linux that you actually control, but then you're missing on all those things. Similar to the current situation with mainline Android and its user-empowering forks.
> we'll see the desktop Linux ecosystem forking into the "secure" Linux
> Or you can run Linux that you actually control, but then you're missing on all those things
We cannot allow this stuff to be normalized. We can't just sit by and allow ourselves to be discriminated against for the crime of owning our own devices. We should be able to have control and have all of those nice things.
Everything is gonna demand "secure" Linux. Banks want it because fraud. Copyright monopolists want it because copyright infringement. Messaging services want it because bots. Government wants it because encryption. At some point they might start demanding attestation to connect to the fucking internet.
If this stuff becomes normal it's over. They win. I can't be the only person who cares about this.
I wish that is an option. Nowadays many non competitives games that you play with friends you trust still use EAC (yet accept non-kernel mode operation on Linux). I suppose other than VAC you can't buy a usermode anticheat middleware now.
Honeycomb is inspired by Facebook's Scuba (https://research.facebook.com/publications/scuba-diving-into...). The paper is from 2013, predating honeycomb. Charity worked there as well, but presumably was not part of the initial implementation given the timing.
MCP is just function calls with parameters. Whether or not it's push or pull can be decided by the author. A push model takes the scan as an input to the mcp call. A pull model does the pulling within the mcp call. Neither is right or wrong, it's situational.
To me, dabbled means learned the fundamentals of the language but hasn't written real software in it. I would expect a dabbler to have been exposed to class inheritance and primitives such ss symbols.
The end user doesn't need to implement the queue or the worker. They just need to implement the http api for receiving POST messages. The queue "server" is effectively just a http client that reads messages from the database and sends them off.
That makes sense as a general pattern, but probably less so in the context of rails which is typically a self contained monolith. It would be adding another hop, more indirection, and more complexity. It would introduce new problems like the need to segment your "real" api from your worker api for the purpose of load isolation.
If it is a self contained monolith, that's perfect for this. You have a long running process, which scans a database for new work and then posts to localhost.
reply