Dagens Vibes — 19. september 2026

We just ran Jev on our WebMCP benchmark. The result: basically broke the benchmark. Jev + Mercury 2.5 (a fast, low-cost LLM) using WebMCP solved 100% of the tasks at roughly 112× lower model cost than GPT-6 Astra using computer use with code execution. Compared to Astra using screenshot-based computer use, the model cost was 245× lower (!). We also compared Jev operating the browser with and without WebMCP. We used Browser Use’s open-source Ultrafast, with some improvements to the harness to make it more reliable across the benchmark. Jev’s browser-control accuracy on its own was not amazing - adding WebMCP nearly doubled the number of solved tasks, from 25/49 to 49/49, while reducing model cost by 18% (more on why below). The benchmark and methodology are fully open and reproducible. Full results: https://webmcp.com/benchmark A few words on how the Jev + WebMCP harness works and why this is exciting: Jev receives text as input and a set of discrete options it can choose from. With WebMCP, those options are the tools exposed by the website. At each step, Jev sees the task, the available tools and previous results, then picks what to do next. The limitation is that Jev can’t generate arbitrary text, which you need for tool arguments. For example, it can choose the search_products tool, but it can’t generate the search query itself. So we split the work: Jev picks the tool and Mercury 2.5 generates the arguments if needed. This works well because turns out most of the cognitive load in these tasks is around choosing the right action. The argument generation itself is relatively simple, so we can delegate to a small and very fast model. We used Mercury, which outputs 1,000+ tokens/sec and is very cheap. The result is a pretty simple combination: Jev for tool selection + Mercury for arguments + WebMCP for the interface. It ends up being very reliable, very fast, and very cheap. A few words about Ultrafast and why do we think it underperforms: Without WebMCP, Jev chooses from the page’s controls: which button to click, which field to fill, or which option to select. But choosing a valid button is different from choosing the right next step. The agent still has to navigate menus, understand forms, recover from errors and recognize when the task is actually complete. Our hypothesis is that WebMCP makes the decision space much simpler. Instead of figuring out a sequence of clicks through a website, Jev chooses explicit actions that directly advance the task. @typesafeai itself documents weaker accuracy on questions requiring multiple reasoning steps. WebMCP moves much of that complexity into the website’s tools, leaving Jev with clearer decisions and fewer opportunities to go wrong (in a sense WebMCP "compresses" a sequence of clicks into one tool call). Our modified Ultrafast setup solved 25/49 tasks - that is a result for our particular implementation and benchmark, not a universal limit on Jev or Browser Use. We are open to more harness optimization to get this result to perform better, feel free to directly contribute to the benchmark here: https://github.com/nekuda-ai/WindTunnel Browser-use ultrafast: https://github.com/browser-use/jev-ultrafast

I ran some real, live evals on Jev vs DiffusionGemma-as-Jev (my patch for vLLM!) DiffusionGemma comes out as the winner, I think. Headlines: Is Jev faster than DiffusionGemma? No ❌ (API vs DGX Spark) Is Jev smarter than DiffusionGemma? No ❌ (they're roughly tied!)

"Pi reaches the Pareto frontier on both benchmarks by providing just four tools: read, write, edit, and bash. To understand how harness design affects spending, we examine costs across completed attempts, recorded turn counts, and initial context." Sharing this analysis on the Harness Tax by @MelissaPan and others. https://harnesstax.github.io

We're adding support for AGENTS.md to Claude Code. Starting today in version 2.1.277, if there is no CLAUDE.md in a folder, Claude will check for and use AGENTS.md. You can toggle this behavior in /config.

Prompt I've been working on for my @Muse, which should also work just as well with Instinct and Grok @bot. Goal is to protect travel time on my calendar. Fun fact: I tried to build this as a small app last year, but was blocked for over 6 months by Google's approval process, so I gave up. Fast-forward, the bots in our lives can do it! give this link to your bot https://share.trev.in/trevin/f/qMGOLo/travel-time-buddy.md Full prompt: ---- Job: Protect my calendar with travel buffers so I can physically get to meetings that aren’t at wherever I’m working that day. Horizon: Look 14 days ahead in my local timezone. Re-scan on a standing cadence (e.g. each weekday morning, plus when I tell you something changed). Don’t pretend you watch the calendar continuously. Before you start (ask once, then remember): My usual workplace address(es) — office, home office, or both. How you can tell office vs WFH (or ask me that day if you can’t). Which calendar(s) to protect, and whether travel blocks go on personal, work, or both. Default travel mode (car unless I say transit/walk/bike). Which events get buffers: Has a real place (street address or place you can reliably locate). That place is meaningfully different from my workplace for that day. Skip: video/phone-only with no place; already at my workplace that day; vague locations (“downtown”); all-day soft holds; flights/hotels unless I explicitly want airport buffers. Origin for each leg: Start from my workplace that day, or from the previous event’s location if I’m chaining in-person meetings. Evenings/weekends default to home if I’ve given you a home address. How to block: Use live travel time (Maps-class ETA) for the mode in force. Add a to buffer before and a from buffer after (ETA + a small pad, rounded to sensible calendar minutes). Title every buffer exactly: Travel time. Busy, no attendees. Put origin → destination, mode, ETA source, and managed-by: travel-buffer in the description only — not the title. If a buffer collides with another hard commitment, don’t silently overwrite — ask, or shorten and leave the calendar as the record of what you did. Ask when unsure (one clear question, then stop): ambiguous place, unknown office/WFH, unclear mode, or a buffer that would wreck the day. Do not fight me: If I delete, shorten, move, or retitle a travel block, that’s policy for that event. Remember it. Never recreate the same buffer unless the meeting time/place changed or I ask. Keep a small ledger of buffers you created and any I dismissed or edited. On re-scan: skip dismissed; only update when the underlying meeting moved or changed address. Stay quiet: Don’t narrate adds or changes in chat. The calendar is the evidence. Only message me when you need a decision. ---

loaded. bonsai 2 27b is sitting on an rtx 3060 12gb right now, served through the prismml llama cpp fork with the full 262k context window resident, 11.7 of 12 gigs in use, hermes agent pointed at it. first receipt before a single benchmark: a 27b holds its entire native window on a 12gb card. now we find out what it does and how fast it runs. for anyone new here, bonsai 2 is not a new model. prismml took qwen 3.8 27b, a dense 27b that needs around 16gb at q4, and compressed the weights to ternary, three values per weight, 1.75 bits each, 5.95gb on disk, and their table says it keeps 98.2% of the full model on their suite. the 3060 is the number one desktop gpu on steam at 3.92% of every pc, a five year old card, so if a 27b runs as an agent here, it runs for more people than on any other card on earth. for anyone who followed the july run, bonsai 1 was the same idea on qwen 3.6 27b at 1 bit, 3.9gb, and it held a 30 minute agent loop on an 8gb 3060 ti. bonsai 2 is a bigger file on a better base, so the question moved from does it run to how much of the full model survived. tonight, in order: speed at empty context and at 64k filled, then a real build through hermes agent, the same spec the july run had to pass. receipts as they land, tool named on every number.

Taking this back, unfortunately. It really struggles with basic things. I have a workflow where I ask the agent to check something that requires using jq. 27B completes it in 2 turns. This one takes 10-20 tripping over syntax errors repeatedly.