Another anecdotal data from an arxiv preprint [0]: "After the paper was written, the author learned that the same result was also proved independently and by a different method by Ningyi Li [7]. The result is also contained in a paper [8] released by OpenAI on October 6, 2026, in which the proof strategy and specific choices of notation are identical to a preliminary version of the present paper that was uploaded to ChatGPT on September 8, 2026."
So not only did OpenAI publish a proof similar to one discussed on ChatGPT, but also there were other possible strategies to prove the result, that OpenAI didn't follow.
Also, up to my knowledge, on the free plan, OpenAI doesn't claim that they won't use the chat data for training. So this seems plausible.
Out of curiosity, which harness do you use for this kind of task, and how do you sandbox it? I used Aider before, and consider switching to a more recent tool.
I started out with agy CLI but it's horrible because of its very indeterminate context compaction. But I live with it because it's the only way to use Google's subscription. I was and still use Opencode in parallel (accessing Openrouter ZDR endpoints) when I run out of rate limits / weekly limits.
Over the past two weeks, I have started using a locally modified version of deepseek-harness (modifications include disabling telemetry and querying a provider's model list dynamically through Openrouter, instead of relying on the pre-packaged pi-ai manifest that comes with the base code). So far, that has been the best experience - I really like the caching, tokens/sec stats that it provides. (EDIT: I don't know a lick of TypeScript but AI-driven modification of the harness is good enough for me to make these tweaks).
Sandboxing is a definite issue for me. As you perhaps know already, headless operation is often not an option in graphics/game programming which requires actual render-surface instantiations from windowing systems and then input-context handling (keyboard/mouse/gamepad) as well. So I run most development on a VM. But part of my test-suite and smoke-tests rely on runninng it directly on the host OS (which is not ideal). I'd love to hear suggestions to avoid this.
> So I run most development on a VM. But part of my test-suite and smoke-tests rely on runninng it directly on the host OS (which is not ideal). I'd love to hear suggestions to avoid this.
Power longevity might not be the reason since in this project, having faster transition seems to be done by using less change waves, which probably uses less electricity.
> Now, everything you say or write can be automatically screened for red flags
Considering that many people will share their deepest thought with LLM, it might start looking more and more like attempts of precog agents from Minority Report...
If we throw in hardware dedicated to a specific LLM, it seems to be a rather low hanging fruit. Especially considering that this is already happening for vision models [1].
One book cited several times in the preprint of OP is the volume 2 of the famous book series of Knuth, The Art of Computer Programming, notably its section 4.6.4. For readers interested in this kind of results, it is a really interesting gathering of classical theorems and useful tricks to evaluate quickly polynomials.
> I found that it was an overflow in the glue code (now fixed) that converts the exact rationals coordinates of the output mesh, for which we prove the specification, to floats
Preserving the topology of mesh intersections while rounding the coordinates is a hard problem. In particular, it is only in 2020 that an algorithm was found that handles all the cases [1]. In practice, an efficient algorithm for that was published last year [2].
So not only did OpenAI publish a proof similar to one discussed on ChatGPT, but also there were other possible strategies to prove the result, that OpenAI didn't follow.
Also, up to my knowledge, on the free plan, OpenAI doesn't claim that they won't use the chat data for training. So this seems plausible.
[0]: https://arxiv.org/abs/2610.10072