{"slug": "show-hn-burnless-makes-llm-context-a-protocol-token-savings-are-a-side-effect", "title": "Show HN: Burnless makes LLM context a protocol. Token savings are a side effect", "summary": "Burnless, a new protocol for LLM context management, separates conversation, memory, and execution into layers, reducing active context tokens from 1.4 million to 1,590 tokens in a real-world task, achieving a 908:1 operational ratio. Creator Burnless argues that larger context windows are the wrong approach, as they fail to address the fundamental problem of mixing disparate data types in a single context.", "body_md": "I’ve created Burnless because I realized that we were using the context window for things that didn't need to be there anymore.\n\nI wanted to stop burning tokens with what had already happened and were no longer necessary for the next step.\n\nIt was not a discovery that came later. Burnless was born to separate things. What I didn’t know yet was the size of the problem, the size of the gain and how different it was from the path that everyone else was following. What I see nowadays is that everyone wants the context window to be bigger.\n\nThat helps, of course. But in my opinion, the concept is wrong. A larger window will only allow you to put more things inside it, but it does not solve the fact that we are using the same place for the conversation, memory, decisions, execution, open questions, work history and all the old records of what has already been done.\n\nBurnless separates that into layers.\n\nConversations, thoughts, debates, questions, and the history of the work are indexed and stored in your disk.\n\nThe main context contains only the decisions and information that are still necessary to continue the work. But the real words are still in disk if they need to be checked (not even necessary to be honest). Also when we say something and someone asks us to repeat we never use the same words, why do AI need to do that? (remember, the original is still in the disk dont worry…)\n\nTasks are delegated to independent, lightweight workers. They receive a clean task, write the code, manipulate files, execute commands and register on disk what they have done. And yes, the workers use the same byte cache header (don't worry with this too)\n\nBurnless then audits the result. If a worker claims that he created or altered a file, Burnless verifies that it actually exists before marking the task as complete.\n\nSo, the context stops being the place where everything has to live. It becomes the place where only what needs attention right now is kept.\n\nThat’s why I compared Burnless to a protocol and, in the beginning, even to TCP/IP. Not because it has the same history dimension, but because the movement is similar: separating responsibilities into layers, into worker capacities, into a useful and clean way of defining the communication between this alive system.\n\nMemory is no longer carried throughout the conversation.\n\nThe execution stops being a role for the main model.\n\nThe project history no longer permanently occupies the work's memory.\n\nThe project can go on even after a /clear command or after switching between models.\n\nToken's savings were the initial motivation, but it ended up becoming a consequence of the architecture.\n\nIn a real-world task, the workers processed approximately 1.4 million tokens. But the Brain’s active context had only 1,590 tokens after completing the full task.\n\nI’m not claiming that Burnless took the exact same 1.4M tokens of text and compressed it to 1,590 tokens.\n\nWhat really happened was that all of that work was done, recorded, verified and continued without the accumulated history remaining inside the active context.\n\nThe final operational ratio was approximately 908 to 1. (yeah 908x)\n\nWhen I show you that number, it sounds unbelievable. That was when I realized that the problem was much larger than I had initially imagined.\n\nWhile the general direction is to build increasingly larger context windows, I went in the opposite direction: removed from the context everything that doesn’t need to be considered at the moment.\n\nThe repository also includes an llms.txt file containing the complete architecture, benchmarks, calculations, limitations and commands that are required to reproduce the numbers.\n\nAs I cannot properly explain everything in a short comment, the llms.txt file is there for anyone who wants to understand what is happening at a deeper level and verify the claims. Use that to help your AI understand that stuff easily and respond to your questions.\n\nComments URL: [https://news.ycombinator.com/item?id=49112480](https://news.ycombinator.com/item?id=49112480)\n\nPoints: 1\n\n# Comments: 0", "url": "https://wpnews.pro/news/show-hn-burnless-makes-llm-context-a-protocol-token-savings-are-a-side-effect", "canonical_source": "https://github.com/Rudekwydra/burnless", "published_at": "2026-07-30 16:45:01+00:00", "updated_at": "2026-07-30 16:52:15.318947+00:00", "lang": "en", "topics": ["large-language-models", "ai-tools", "ai-infrastructure", "developer-tools"], "entities": ["Burnless"], "alternates": {"html": "https://wpnews.pro/news/show-hn-burnless-makes-llm-context-a-protocol-token-savings-are-a-side-effect", "markdown": "https://wpnews.pro/news/show-hn-burnless-makes-llm-context-a-protocol-token-savings-are-a-side-effect.md", "text": "https://wpnews.pro/news/show-hn-burnless-makes-llm-context-a-protocol-token-savings-are-a-side-effect.txt", "jsonld": "https://wpnews.pro/news/show-hn-burnless-makes-llm-context-a-protocol-token-savings-are-a-side-effect.jsonld"}}