silbercue

yes. i used it like that. big model is planning - JEV chooses elements on a site to click. i made a super fast mcp browser. JEV got a list & aim and gives back the probabilities - the tool clicks. result: in 6 cases (button, form, dropdown, read table) = 3 secs and 0,02 Cent. Opus did it in 10 sec vor 11 Cent. crazy imho. didn't do heavy tasks though - pity it can't write text. did anyone had a look at laya yet?

only harness. no container. no vm. no cloud. should run without problems in a vm (with chrome installed). do u have something in mind?

I used it today as browser agent, the "tool" is a menu of ~10–40 clickable refs from the accessibility tree. Jev picks one per step. 21–23 decisions for six benchmark cards, all correct (!), ~$0.001 total. Really good. The part it can't do is write the text for an input field so a nano model does that when Jev picks "type". Numbers and code in my top-level comment in this thread. Working very good.

been eyeing Instruments integration for my own iOS tooling for months and kept bouncing off it. xctrace output + parsing traces felt like a rabbit hole. DuckDB + Parquet is a way nicer angle than what I had in mind.

> Where the AI trips up is getting distracted by aggregate signals

this shows up everywhere in agent loops. anytime I hand Claude a wide slice of anything it starts reasoning in averages. the moment I narrow to ~10 rows it locks onto the actual root cause. so derived views sound like exactly the right shape. how big do real traces get in your duckdb format? does a 5min scroll-heavy trace stay manageable =)

> Streaming would make sense if I were piping large sample arrays directly, but those get aggregated server-side before returning

thitami's point on perceived latency is the thing I'd still watch. had the same "its fine, its fast enough" moment in a different MCP context (iOS simulator automation)... turned out the 300ms per-tool-call was what made the whole loop feel sluggish even though each individual query was "fast". got it down to ~20ms and Claude felt noticeably less hesitant between calls after that. cant fully explain why but the behavior shift was real.

probably not your problem at 90 rows of scalar data =) just a thing I wish I had clocked earlier.

mine kept growing until I'm pretty sure claude was just skipping half of it. ended up doing the same... moved verbose stuff into separate files and only kept the absolute hard rules in claude.md. rules it cant grep its way around.

on the fine tune... I feel like the gain probably isnt worth the maintenance vs just adding another constraint to the prompt. did you find concrete cases where prompting just couldnt get you there?

been ordering from REWE for years =) always wished the app was less annoying. all my programm skills - for what? lol. probs for reverse engineering the mTLS part, most people would have just given up.

how stable this is in practice? Internal APIs tend to break without warning when they update the app.

> Claude code hooks are blocking - performance degrades rapidly if you have a lot of plugins that use hooks

can confirm. ended up being really careful about what runs synchronously vs in the background.

IMHO the "sanitised optimism" thing others mention here is real too. had to add explicit verification steps because Claude kept reporting success when it just silenced the error. now I always make it prove things actually worked before moving on.

> Claude Code (Opus) wrote ~95% of the code. I provided architecture, constraints, and direction

76k lines in 53 days? Crazy. How much of the 95% did you end up rewriting?

> 87 plans total, averaging 2-3 pages each. The CLAUDE.md project file is 164 lines of hard constraints

164 lines of constraints... Did you build those up over time or write them upfront? I try to keep adding rules every time Claude does something dumb.

> It defaulted to OOP in TypeScript even though the project is data-oriented ECS

yeah Claude really wants to write OOP no matter what you tell it! true!

Cool) I'm doing something similar atm for iOS simulators instead of macOS / same idea though, giving Claude direct access through MCP instead of going through computer use. The latency difference is huge when you skip the screenshot-parse-click loop.

tell me more about you handle tool discovery... With macOS scripting there could be a ton of possible actions. I ended up with 49 and already feel like thats a lot for the context window.