Posted by Topfi 15 hours ago
So this isn’t really a price cut. As to why, lots of possible reasons. Perhaps an agreement with OpenAI to help them drive up more diverse traffic priorities.
Paper: https://arxiv.org/abs/2603.07267
FWIW, there’s not that much value protected here anyway IMHO, and even raw thinking text can lie (as shown by Anthropic’s amazing research), so for legitimate interpretability research it’s limited.
Scaling frontier performance hasn’t been SFT-bounded for a while now; it’s now basically how much you can scale RL rollouts.
OpenRouter attributes this promotion to OpenAI https://x.com/OpenRouter/status/2089416739398254662
What's the incentive here?
Open Responses API doesn't appear to support state management (yet)
So yes, presumably a very small share of their total traffic.
At this point, I'm considering going back to cursor over codex due to the ability to get more control over what model I use since there is clearly a heap of user preference and having frontier providers constantly shift the goal post with "State of the Art" is complete non-sense.
The TypeScript code which was transpiled into Rust (and is compatible with most hugo templates) runs faster than the original hugo.
[1]: https://github.com/tsoniclang/tsonic-examples/tree/main/rust...
The transpiler is still WIP, but the fact that it can do this says a lot of about how far LLMs have come.
Its like rehiring an employee every few months then training them up. Its honestly tiring and cant stay like this.
Opus has the same problem too…
This is the csharp target for tsonic. It has a bunch of tests here: https://github.com/tsoniclang/tsonic-csharp/tree/main/test
More comprehensive e2e proving grounds are at
1: https://github.com/tsoniclang/proof-is-in-the-pudding
2: https://github.com/tsoniclang/tsumo/
They were built specifically for testing the C# target. There are several other large projects we built specifically for e2e testing.
But the more interesting thing would be the tooling built to support this. For example, our current TypeScript parser [1] is a file-by-file port of Microsoft's TypeScript V7 compiler written in golang. The challenge here is that every time Microsoft changes code, we'll have to fix our code and tests. It's doable, but a fair amount of work.
So we decided to write tooling to transpile Microsoft's v7 compiler from golang, and autogenerate our compiler. That tool is called gotots [2] - and it already produces a fully working TypeScript compiler. It's 3x slower than TypeScript v6 compiler, but we hope to get to rough performance parity in a week or so. Everytime Microsoft makes an update, we run gotots and our parser gets updated as well.
[1]: The old parser - https://github.com/tsoniclang/tsts-legacy
[2]: Golang to TypeScript transpiler - https://github.com/tsoniclang/gotots
if you want to solve basic problem then use Luna