daily

2026-07-20
1

I burned all my tokens researching how to save tokens

Hacker News · original → · 8/10 · AI/work: token economics for AI agents, direct work interest
I burned all my tokens researching how to save tokens At Quesma we are researching the economics of AI agents: what agentic coding really costs and what you can do about it. For this research I am…

I burned all my tokens researching how to save tokens At Quesma we are researching the economics of AI agents: what agentic coding really costs and what you can do about it. For this research I am running my own deep research setup, a pipeline of agents that builds a knowledge base I can actually trust. The first version of this setup burned the whole limit of my Claude Max 5x plan in 30 minutes. This post is the story of how I fixed the cost and the trust, using only subscriptions I already pay for, and how you can build the same. My goal was to understand the entire state of so-called tokenomics. I wanted to know what monitoring systems exist, how teams govern their AI spend, and which optimization tools and practices actually work, both in the papers and in the real world. I started the usual way, with /deep-research . I gave it the big open question and let it run. After around 30 minutes of research, I hit a limit and had to wait a few hours for it to reset. And I had no results. The run launched 111 agents and queued 123 claims for verification, but only 25 got verified before the limit hit, and the final synthesis never ran. So, it hit me personally. And this is a bit funny: from the very first day I had to optimize tokens while still discovering how to optimize tokens. Learning by doing. Using every subscription I already pay for If Claude Fable 5 is out after 30 minutes and /deep-research is consuming so many tokens without giving me any results, what can I do to make the research more effective? I started thinking about what kind of tools I already have and pay for. Claude, Codex, and Antigravity: 3 subscriptions, and in theory 3 times more tokens without paying anything extra. What if I use all of these tools together, with shared memory? Since I am already using the claude-mem plugin I extended it to support Codex and Antigravity locally, so that all 3 tools can use shared memory during sessions. Whatever one tool learns, the others can use. Cheaper models as subagents My default setup is Claude Code, so I used it as the main harness. While doing the research manually, I discovered a model-orchestration pattern, which was exactly what I needed at that moment. We don’t really need Fable for everything: Claude Opus 4.8, Claude Sonnet 5, GPT-5.5, and Gemini 3.1 Pro are already excellent models for many tasks. So I checked a few benchmarks and cost analyses, mostly Terminal-Bench for terminal and agentic work, SWE-bench Pro for end-to-end software engineering, and Artificial Analysis for a general view of performance and prices. I did not treat any of them as the final truth; benchmarks measure their own thing and the numbers move every month. I just needed a loose starting point for who is good at what, and using several different models was part of the experiment from the beginning; I expected to adjust the split after real runs anyway: | Role | Model | Why this one | |---|---|---| | Find | Claude Sonnet 5 | Strong on agentic benchmarks and cheap enough to run in bulk | | Verify | Claude Opus 4.8 | The most accurate Claude worker; checking needs more accuracy than searching | | Judge & plan | Claude Fable 5 | The most expensive one, so it only plans, decomposes, and resolves disputes | | Small stuff | Claude Haiku 4.5 | Cheap and fast for extraction and formatting, too weak for multi-step work | | Run tools | Codex (GPT-5.5) | Very strong on terminal benchmarks; clones, installs, runs, and inspects tools | | Second opinion | Antigravity (Gemini 3.1 Pro) | A different model family, so it does not share the same blind spots | This split was not my first version; I adjusted it a few times when live runs showed weaknesses, and the fallback rules came from those failures. The best thing here is that I prepared Codex and Antigravity to be used as Claude subagents, orchestrated by Fable, using the headless nature of both. Why is it cool? Because tokens are taken from the Codex and Antigravity subscriptions, so I was not paying extra, but I instantly had much more intelligence to use. The whole trick is one small Bash script that my Claude agents can call like any other command: # run-cli: call another vendor's CLI as a headless subagent # usage: run-cli <codex|antigravity> "<prompt>" VENDOR="$1"; PROMPT="$2" case "$VENDOR" in codex) OUT="$(codex exec --sandbox read-only "$PROMPT")" ;; antigravity) OUT="$(agy --model "Gemini 3.1 Pro (High)" -p "$PROMPT")" ;; esac echo "$OUT" echo "$OUT" | claude-mem-save -s "$VENDOR" # save to shared memory (my locally extended claude-mem) The wrapper also watches the output for “usage limit” and “out of credits” messages and returns a special exit code, and this is exactly how the automatic fallback to Claude models works: the orchestrator sees the signal and does the work with a Claude agent instead. One more thing that really matters is to pin the model per role, because subagents inherit their parent’s model by default, and that is exactly how I burned my Fable limit in 30 minutes. With this technique I was able to run the research continuously for roughly 10 times longer than initially with Fable only, measured simply as how long I can keep the agents working before any of the 3 subscriptions hits a limit. Before it was 30 minutes of research, now it is a few hours, without paying a single penny more. And when Codex or Antigravity hits its own limit, the framework simply falls back to Claude models, so the research does not stop. Reducing hallucinations Cost was only the first problem, the second one was trust. Before my research framework, when everything was done by Fable, I was sometimes getting findings that looked solid but were not true. For example, a wrong license on a repo, a savings figure with no source, or a number that was not on the cited page. To reduce hallucinations, I implemented explicit rules in the research framework that every finding must pass before it can be shared. A few of them: - Whoever finds a claim never verifies it, a different model or agent checks the links, quotes, and numbers. - Nothing lands in the knowledge base without a URL and a quote from the primary source. - Never state a number the source page doesn’t contain. This list was not designed upfront. It grew during the research, because every time verification caught a new class of mistake, the rule went back into the prompts. And such a framework is really effective only if you keep tuning it, so review the findings, flag the useless ones, and feed that back. /deep-research goes last With cost and trust handled, the last piece was the /deep-research tool that started this whole story. It is still in the pipeline, but as the last step, not the first. At the end of each day I run it over the findings that already survived verification, so instead of researching blindly it goes through the existing findings, deepens them, eliminates the mess, and tries to fill the gaps that the framework missed. It also uses fewer tokens this way, because it works through a fixed list of claims instead of exploring the internet. The last run used 61 agents and took 22 minutes. Compare that to day one, when 111 agents burned the whole limit in around 30 minutes and never produced the report. Same tool, just a much smaller job. The result: a knowledge base I can trust Everything that survives verification lands in an LLM wiki I keep in Obsidian, inspired by Karpathy’s LLM wiki pattern: linked atomic notes, agents doing the sweeps, and me setting the rules. One week in, it holds hundreds of validated notes on pricing, tools, benchmarks, and practices. Automated checks aren’t enough on their own. Once, my triage rule quietly rejected Headroom, a 56k-star project and one of the biggest in its category. The agents did everything right, verification confirmed the project is legit, and a claim check correctly flagged that its headline savings numbers were not quality-controlled. But my rule said “unvalidated claims mean no entry”, so a project half the industry uses was invisible in my knowledge base. I only noticed 2 days later, when I asked “how did we miss this?” The fix was a new rule: reject the claim, not the project. Agents can do the searching and checking, but no agent will ever tell you that your own rule is the bug. If you want to build a quality knowledge base, human verification and research supplementation are mandatory. AI-only research can be really poor quality. Human-only research is too slow. The best way is a hybrid one: agents do the heavy research work, but they run on a pipeline crafted and constantly improved by a human. The human also verifies the results and fills the gaps. A few findings from the knowledge base The token economics topic turned out to be much larger than I expected. Here is a small sample of what is already inside, the findings that surprised me the most: - Your harness can matter as much as your model. On Terminal-Bench the same model shows a ~66x token spread across different harnesses, and the thinner setups actually score higher, not lower. Another study measured a swing of about 54 percentage points on the same model, changing only the harness. We saw a small version of this ourselves when we checked the true cost of saying “Hi” to an AI agent. - Context compaction can double your bill instead of saving it. Compaction sounds like compression, so it is easy to assume it is always good, but it is not free: the model has to summarize your history and that summarization call consumes tokens too. It can also evict files the agent still needs, so the agent re-reads them, the context fills up again, and compaction fires again. One documented regression shows how bad this loop can get: after a harness retuned its compaction threshold, it went from 4 to 12-26 compactions per session, and token usage on identical tasks went from 89 million to 160-185 million. - One mid-session tool change silently re-bills everything. Cache reads cost about 0.1x of the base input price, but the cache invalidates as a hierarchy (tools, then system, then messages). Add or reorder a single tool schema in the middle of a session and the entire cached prefix re-bills at full price. You get no error, just a bigger invoice. - Your token counter is not your invoice. In one documented case a calculated $3.60/month landed as a $25-40/month invoice, a 7-11x gap coming from context accumulation, retry amplification, framework overhead, and evaluation calls that a simple token estimate never captured. Our framework tags most of these as medium confidence, usually 1 or 2 solid sources, and we keep that visible instead of pretending it is settled. Before you burn your next limit If you are burning your limits on deep research today, try reversing the order. Cheap models find, accurate models verify, and deep research goes last. And check how much intelligence you already pay for. A few subscriptions with a clear role for each model give you much more than one frontier model used blindly. And if you are building your own research pipeline, or your AI bill grows faster than your usage, we would really like to hear from you. Join the discussion on Hacker News or LinkedIn. Stay tuned for future posts and releases

2

Show HN: I replaced a $120k bowling center system with $1,600 in ESP32s

Hacker News · original → · 7/10 · Work/tech: SRE bowling center automation with ESP32s
I might be the only SRE on Earth with his own bowling center. It's a more in-depth gig than you'd think. My family and I bought an abandoned 8-lane bowling center in the rural mid-west. In our small…

I might be the only SRE on Earth with his own bowling center. It's a more in-depth gig than you'd think. My family and I bought an abandoned 8-lane bowling center in the rural mid-west. In our small town there weren't many recreation options for families. You've heard of a food desert? This is an R&R desert. It had been abandoned for a good reason. The roof leaks, the electrical system was constantly surging, and my 70-year-old bowling equipment (still) doesn't work perfectly. The system that keeps your score is particularly interesting to me. It's the thing you watch during your game, but it fades into the background beyond that. Turns out these things are really cool, but absurdly expensive. Ours was installed in 2008 and cost six figures. It's calculating ball speed and trajectory, camera-based pin detection (object detection and trig, on ICs!), runs the fouling, the animations, the pinsetting machine and ball return. Very cool stuff for its age. From the business perspective, my facility only cost me $105k. To forklift-replace the score keeping system runs anywhere between $80-$120k, depending on features, vendor, and unit age. No upgrades or service contracts, mind you, and every feature and customization is a new line item. That's for a 1:1 replacement on a system installed in 2008. Incredible, given how fast the tech world moves. Replacement parts cost a shocking $4000 per pair of lanes. But wait, the bowling machines themselves are 70 years old, so what's this "advanced" system actually doing back there? Actuating a single relay to trigger that big old machine. Everything else is strictly mechanical. Meanwhile I've got a six-figure invoice in my hand. I'm upset. Given the state of open hardware, computer vision, real-time event streaming, and open source running megascale products worldwide, there had to be a way to do this myself. So far I've built an equivalent prototype for about $200 per lane-pair, $400 if you're fancy. ESP32 and ESPNow with an RS485 fallback, reporting to a raspberry pi lane computer that's really just redis and a state machine bolted to an ESP32 gateway for the mesh. Since it's all ESP32, I've got a fistful of spare controllers in a drawer, pre-flashed or waiting to be. All common off-the-shelf hardware: microcontrollers wired to relays, optocouplers, and IR-break-beam sensors, each running slightly different firmware. Writing the firmware and protocol is the actual hard part. It's an ESPNow star-topology mesh: each node emits events from its sensors and accepts commands for its controls, reporting to a gateway node connected to the raspi over UART. From there it's event streaming: RX packets get translated and tossed into redis, commands relay back out to the mesh as needed. RS485 sits underneath as a wired fallback for noisy RF environments. Once the data's in redis, it's familiar middleware/React/websocket/pub-sub stuff. Any React dev can build their own UI and bowling animations. Since it all runs on commodity hardware, I can do legit anything I want as the proprietor, and I own all my data. Repairs take five minutes; I can swap the rig on a lane pair in under 10. I'd bet a house like mine could go from zero to running in an hour or two. We're calling it OpenLaneLink, and I plan to open source the hardware, firmware, and software stack when it's ready. Bowling is fun, and I want to help keep it affordable for alleys like mine. I hate vendor lock-in. I'm not a fan of closed systems, calling support for every hiccup, or paying to "white label" my own equipment. Want to go Tron-themed for a night? Good luck finding a neon neumorphic theme in something bought at the turn of the century. All that bugged me. Sure, bowling equipment is niche, but the open hardware and software landscape is amazing. Thanks for reading! Let me know if anyone's interested in more posts about this bowling nonsense. Around 2019 or so I was approached by an engineer who had a small business retrofitting very old machine tools with modern motion controls. Think very large lathes and planers. The problem they had was that in order to get these systems working with newer controls, they had to make time-consuming modifications to the old machines, in some cases modifying the axis motors and that cost added up quickly. The engineer realized that it was theoretically possible to take the old analog position signals and convert them into something a modern motion controller could read. That converter box would make the retrofit pretty much plug & play, but he didn't have the programming expertise to make it happen. We probably built the first iteration of the converter for under $50 in parts and less than 50 hours of development time. That had me searching for other similar opportunities. I have found a few, but they tend to be one-offs that aren't worth the time unless you're already building something similar. Either that or my ability to see opportunity sucks! reply

3

Moonshine: Lets you stream games from your PC to any device running Moonlight

Hacker News · original → · 7/10 · Gaming/tech: game streaming tool, PC gaming relevant
Moonshine lets you stream games from your PC to any device running Moonlight. Your keyboard, mouse, and controller inputs are sent back to the host so you can play games remotely as if you were…

Moonshine lets you stream games from your PC to any device running Moonlight. Your keyboard, mouse, and controller inputs are sent back to the host so you can play games remotely as if you were sitting in front of it. - Isolated streaming sessions: Each stream runs in its own compositor, completely separate from your desktop environment. Your host PC can still be used for other things while you stream. - No monitor required: Works on headless servers — no HDMI dummy plug needed. - Hardware video encoding: H.264, H.265, and AV1 encoding using the GPU. ⚠️ AV1 Warning: AV1 encoding is experimental and has issues on NVIDIA GPUs that cause frame sizes to grow over time (see issue). This should be fixed in driver version 595.44.3.0. Until then, stick with H.264 or H.265. - HDR support: True 10-bit HDR streaming for supported games. - Full input support: Mouse, keyboard, and gamepad (including motion, touchpad, and haptics). - Audio streaming: Stereo and surround sound (5.1/7.1) with low-latency Opus encoding. - Linux only. Tested on Arch Linux, but it's been reported to work on other Linux distributions too. - systemd. Required for launching and managing application processes. Almost all modern Linux distributions include it by default. - A GPU with Vulkan video encoding. NVIDIA RTX, AMD RDNA2+, or Intel Arc. - Moonlight v6.0.0 or higher. Compatibility with older versions or unofficial ports is not guaranteed. The simplest method is to install through the AUR using: yay -S moonshine To run Moonshine for your user: - Enable user lingering: sudo loginctl enable-linger $USER This allows Moonshine to run applications in the user's session even when the user is not logged in. If your user is always logged in when you want to stream, you can skip this step. - Enable the service to start on boot and run immediately: sudo systemctl enable --now moonshine@$USER The following dependencies are required to build: sudo pacman -S \ clang \ cmake \ gcc-libs \ glibc \ libc++ \ libevdev \ libpulse \ libxkbcommon \ make \ mesa \ opus \ pkg-config \ rust \ shaderc \ vulkan-headers \ wayland Then compile and run: cargo run --release -- /path/to/config.toml A configuration file is created automatically if the path you provide doesn't exist. When using the AUR package, it defaults to $XDG_CONFIG_HOME/moonshine/config.toml . When you connect with Moonlight for the first time, it will show a PIN. A notification will appear on the host that you can click to open the pairing page, or you can visit it manually at http://localhost:47989/pin . You can also pair from the command line: curl -X POST "http://localhost:47989/submit-pin" -d "uniqueid=0123456789ABCDEF&pin=<PIN>" Each application runs in its own isolated streaming session. Add them to config.toml like this: [[application]] title = "Steam" boxart = "/path/to/steam.png" # optional command = ["/usr/bin/steam", "steam://open/bigpicture"] title : The name shown in Moonlight.boxart (optional): Path to a cover image.command : The command to run. First entry is the executable, the rest are arguments.pre_command (optional): Commands to run before launching the application. Each entry is a separate command, executed in order. Runs synchronously — the session waits for all to finish.post_command (optional): Commands to run after the streaming session ends. Each entry is a separate command, executed in order. Runs synchronously — the server waits for all to finish. Example: [[application]] title = "Steam" command = ["/usr/bin/steam", "steam://open/bigpicture"] pre_command = [ ["/usr/bin/systemctl", "stop", "conflicting.service"], ["/usr/bin/nvidia-smi", "pstate", "50"], ] post_command = [ ["/usr/bin/nvidia-smi", "pstate", "performance"], ] Scanners automatically detect installed applications so you don't have to add them manually. Steam scanner — finds all installed Steam games: [[application_scanner]] type = "steam" library = "$HOME/.local/share/Steam" command = ["/usr/bin/steam", "-bigpicture", "steam://rungameid/{game_id}"] Desktop scanner — finds applications from .desktop files: [[application_scanner]] type = "desktop" directories = [ "$HOME/.local/share/applications", "/usr/share/applications", ] include_terminal = false resolve_icons = true - How does this compare to Sunshine? - Sunshine supports more platforms and has more features overall. Moonshine is Linux-only. - Moonshine runs each streaming session in its own isolated environment, separate from your desktop. This means your host PC stays usable while you stream, and it works without an active desktop session. Moonshine is not designed for use on public networks. The underlying GameStream protocol has limitations that mean traffic is not fully encrypted at the application level. If you need to stream over the internet, use a VPN such as Tailscale, WireGuard, or ZeroTier. Do not expose Moonshine ports directly to the internet. This wouldn't have been possible without the incredible work by the people behind the following projects: - Moonlight, without it there would be no client for Moonshine. - Sunshine, which laid a lot of the groundwork for the host part of the API. - Inputtino, for a thorough implementation of input devices. - magic-mirror, for inspiration of using Vulkan and a Wayland compositor for headless streaming.

4

Quoting Sam Altman

Simon Willison · original → · 7/10 · AI: Sam Altman on open source LLMs, AI strategy
20th July 2026 We have been having extensive discussions around open source strategy. We will discuss it more at our next board meeting, but one thing we’d like to do soon is to create a language…

20th July 2026 We have been having extensive discussions around open source strategy. We will discuss it more at our next board meeting, but one thing we’d like to do soon is to create a language model with the approximate capability of GPT-3 that can run locally on consumer hardware and release that. We’d like to do it soon, before Stability or someone else does. In general, we think this helps discourage others from releasing similarly-powerful models, and makes it harder for new efforts to get funded. — Sam Altman, Email to OpenAI's board, October 1, 2022 - exposed in Musk v. Altman (2026) Recent articles - Kimi K3, and what we can still learn from the pelican benchmark - 16th July 2026 - The new GPT-5.6 family: Luna, Terra, Sol - 9th July 2026 - sqlite-utils 4.0, now with database schema migrations - 7th July 2026

5

Inkling: Our open-weights model

Simon Willison · original → · 7/10 · AI: Mira Murati Inkling open-weights model, AI
16th July 2026 - Link Blog Inkling: Our open-weights model (via) Mira Murati's Thinking Machines Lab just released their first open-weights model. Inkling is "a Mixture-of-Experts transformer with…

16th July 2026 - Link Blog Inkling: Our open-weights model (via) Mira Murati's Thinking Machines Lab just released their first open-weights model. Inkling is "a Mixture-of-Experts transformer with 975B total parameters, 41B active" - an Apache-2.0 licensed multimodal model trained on 45 trillion tokens of text, images, audio and video. They're also promising Inkling-Small, a 276B (12B active) model, but that's still being tested and the weights will be released "once that work is complete". The model card is much shorter than I've come to expect from US AI labs. It links to even shorter Training Data Documentation with almost nothing of interest in it - it's best summarized by these two paragraphs: The datasets Thinking Machines Lab uses to develop its AI services includes content that is in the public domain as well as content that may be subject to intellectual property protection. Thinking Machines Lab’s services were developed using publicly available content obtained from the open internet and publicly accessible data repositories. Certain datasets were also obtained from third parties. By Thinking Machines' own admission, this is not a frontier model. It's instead intended as a strong base model for fine-tuning using their own Tinker training platform: Inkling is not the strongest overall model available today, open or closed. Instead, a combination of qualities makes it a good open-weights base for customization: multimodal capabilities, efficient thinking, and availability on Tinker for fine-tuning. There's a lot to like about this release. It's Apache-2.0 licensed, and looks competitive with the open weight models coming out of China - it's good to see the US open weights ecosystem gain a new viable contender to join NVIDIA Nemotron and Gemma 4. Here's its attempt at an SVG pelican riding a bicycle, which I generated using this curl command against the Thinking Machines API: curl "https://tinker.thinkingmachines.dev/services/tinker-prod/oai/api/v1/chat/completions" \ -H "Authorization: Bearer $TINKER_API_KEY" \ -H "Content-Type: application/json" \ -d '{ "model": "thinkingmachines/Inkling", "messages": [ {"role": "user", "content": "Generate an SVG of a pelican riding a bicycle"} ], "stream": false }' Full response here. Since it's a multi-modal model I had it describe its own image (after I rendered it to a JPEG) by sending this JSON: { "model": "thinkingmachines/Inkling", "messages": [{ "role": "user", "content": [ {"type": "image_url", "image_url": {"url": "data:image/jpeg;base64,$BASE_64_JPEG"}}, {"type": "text", "text": "Describe this image in detail"}, ], }], "stream": false } Here's the full response. It thought it had drawn a "stork or seagull": This is a cheerful, flat-vector cartoon illustration featuring a white bird riding a bicycle across a green landscape. The Bird: The central figure is a stylized white bird—resembling a stork or seagull—with a plump, rounded body. It has a long, prominent orange beak that is slightly open, revealing a black line for the mouth. Its eye is small and black with a tiny white highlight. The bird has black wing and tail feathers with white edges, and thin orange legs ending in black feet that rest on the bicycle's orange pedals. The Bicycle: The bike has a simple black frame with two large wheels featuring black tires, gray inner rims, and black spokes arranged in a cross pattern. The handlebars are black, and there are bright orange pedals attached to a black crank. A white seat is visible behind the bird's body. The Setting: The scene is set against a clear, light blue sky. There are two fluffy white clouds—one on the left side and a smaller one near the bird's head on the right. A bright, solid yellow sun shines in the upper right corner. At the bottom, there are rolling green hills with a smooth, curved top edge where the bicycle rests. The overall style is playful, simple, and colorful, with clean lines and a bright, sunny atmosphere. Recent articles - Kimi K3, and what we can still learn from the pelican benchmark - 16th July 2026 - The new GPT-5.6 family: Luna, Terra, Sol - 9th July 2026 - sqlite-utils 4.0, now with database schema migrations - 7th July 2026

Items scoring 7/10 or above from 11 sources, scored by claude-haiku-4-5-20251001 on relevance to my interests. At most 3 per source.

Scoring categories & sources
  1. Local Wexford or South East Ireland news
  2. Irish or EU-wide affairs affecting citizens broadly: elections, new laws or policy being debated, cost of living, education — especially impacts on mid-life adults or teenagers. Never courts/crime stories.
  3. Irish news on a topic relevant to my interests
  4. Work and tech topics: networking, AI, Kubernetes, platforms, SaaS
  5. AI news including critical or anti-AI perspectives
  6. Gaming: PC gaming, indie gaming, retro gaming
  7. General interests: gardening, woodwork, cycling, fitness, travel
  8. Comics

Sources: Breaking News Ireland, Wexford Local, Hacker News, r/gaming, r/pcgaming, r/antiAI, r/indiegaming, Lenny's Newsletter, One Useful Thing, Newcomer, Simon Willison