HN user

Aeroi

381 karma

building realtime visual intelligence

Posts14
Comments141
View on HN

sweet! i'm heaviliy using glm 5.2 in mouse.dev which is great for mobile. the ui looks really good, similar to cursor agents window ect.

Cool. I fished Kodiak and Chignik, and was in Bristol Bay in 2015 and 2016.

That first summer I studied historical escapement values to try to predict where to fish. I found almost zero correlation when targeting areas in Kodiak based on historical values, but I’m sure with better data and more experience there’s real alpha to be unlocked. Would be fun to model for some with more stat experience than me.

The more interesting problem to me was trying to understand how the pricing actually worked. Global macro events felt almost completely disconnected from what fishermen were paid, especially with the opaque October price adjustments from the canneries.

There were a lot of structural advantages for the corporations in that business. I came away thinking that vertically integrated processing, distribution, and retail was a much smarter place to be than catching the fish itself.

i'm working on something tangenially with cloud coding agents to bring the workflow to mobile. the breakthrough for me was realizing that the IDE isn't needed anymore and cloud repos + sandboxes open up the ability to continue working from anywhere. mouse.dev

I run the gemini live api over a mesh hosted managed webrtc cloud. works fantastic, and Ive been running it for 2 years. you can try websocket, handle ephemeral keys, ect ect. but when you speak with people running voice agents at scale in this space, many of the issues are solved with webRTC and pipecat and the many resources allocated to solved problems in this space. It certainly feels overkill, and it probably is, but once connection is established, it's pretty magical. the startup time and buffering has been solved for quicker voice connections too, https://github.com/pipecat-ai/pipecat-examples/tree/main/ins... (video is harder)

there are a lot of extremely smart people that have come back to webRTC time and time again because it continues to solve problems other methods and protocols can't. with saying that, quic is certainly interesting going forward, but i primarily stream voice + vision at 1fps so it just makes sense, and websockets fail and are insecure at scale for this use case (see https://www.daily.co/videosaurus/websockets-and-webrtc/) . also just listen to sean in this thread, dude knows whats up.

1. human verification for auth.

2. only human generated input composer, no copy/paste, no file uploads ect. control the composer. control the camera sessions for photos videos.

3. no algorithmic feed that is designed for ad-spend and eyeballs.

4. moderate

Ted Turner has died 3 months ago

Before starting CNN, Ted Turner captained the sailing Yacht Courageous to an America's Cup victor 4-0 over the Australians in Newport, RI during what was arguably sailings hay day.

cool! I've been mostly building for what coding from an iphone can look like. the cloud agent sandbox portion is definitely not polished yet but working well so far. i looked at daytona, e2b, modal ect. but decided to roll my own with fly.io. ttl on agent create. mouse uses per-thread sandboxes (not shared-container multi-workspace) and then post-gres for agent history ect.

i'll have to look more at islo, I definitely think its a growing space with alot of opportunity for those that participate and solve problems.

Nothing groundbreaking but i'll do a blog writeup on the architecture if it would be helpful for people. My focus has been on mobile.

The main pieces I've integrated for mouse.dev inspired by claude/cursor was plan mode, agent questions, subagents, pre/post hooks, context compaction, repo-local skills, and permission modes. So mostly tools like enter_plan_mode, ask_user_question, and spawn_subagent, plus .mouse/skills and .mouse/plans.

One nice feature is continuity. If you’re working on desktop and save a plan to .mouse/plans, you can pick it up later on mobile with cloud agents, or do the reverse. You can plan something from your phone, then when you’re back at your desk, review it/build it. That was my initial goal with this project because I've found the plan act loop so helpful.

Mouse Cloud Agents is mostly an OpenCode-based harness, but everything routes through our MCP/event system so it’s mobile-first and provider-agnostic.

I intentionally skipped a lot of IDE and Claude Code style desktop features. The bet is that this new style of coding is becoming less “edit files in an IDE” and more steer a capable coding chatbot.

Would love to hear from anyone reading that's iterating on harness architecture, it's been really fun to work on.

I haven’t run formal evals but i improved the experience for my own needs and it feels noticeably better with these modifications.

-Claude-style subagents -an MCP layer for higher-level tools -Cursor-style control plane modes like Ask, Plan, Debug, and Build.

The MCP layer lets the harness use things like GitHub file/code read, PR creation, web search/fetch, structured user questions, plan-mode switching, user skills, and subagents.

So the improvement is mostly from better ui/ux orchestration and tool access. There's some things from hermes that are interesting as well.

Most of my focus has been on applying this stack to sandboxed cloud agents so you can properly code and work from mobile devices.

I can't definitively say that the stack is better or worse than Claude code, more just tuned for my use case I guess.

agreed. OpenCode is a strong base, and with a couple modifications it can become a very effective harness. my sideproject mouse.dev I’ve been combining parts from OpenCode, Claude Code, and Hermes to build a cloud agent architecture that works well from mobile.

Great stories. I asked him about the pig thing, after he pivoted from biofuels (I think they raised $150m from Exxon). If I recall he teamed up with another infamous founder Martin, now Martine, Rothblatt who created SeriusXM and United Therapeutics.

I raced with him on his boat. During a gybe once, he was swept overboard and the mainsheet wrapped around his torso. He was dragged through the water, but somehow held onto the rail until I was able to pull him back aboard by the loop on his foullies.

He was an interesting guy. He had been a medic during the Vietnam War, and his old boat, Sorcerer II, became a platform for his Global Ocean Sampling Expedition from 2003 to 2010, which discovered millions of new marine microbial genes.

He collected a lot of friends, and definitely a few enemies, and, in his own strange and remarkable way, seemed to have lived a complete human experience here on Earth.

Personally would love to give back, if I ever make it there. I contribute to large open source communities and also benefit from the contributions of many others, but have never personally been in that situation. Curious what best practices have been historically.

genuinely asking, what is the appropriate compensation/donation/split for a company that uses open source heavily in their early days but later makes money off of it?

from these comments I'm going to make mouse.dev pricing as follows

-BYOK runs are $0 to Mouse, period.

-Hosted runs are billed at provider cost + a published markup.

-We will never invent a unit of billing that isn't denominated in tokens, seconds, or tool calls.

-Credits in the paid category never expire.

harness definitely makes a difference for the benchmarks. I ran my agent Camera Search against a few benchmarks and was able to beat Opus 4.7.

I created a real world benchmark, for mining, oil&gas, construction ect. called FieldOps-bench and it basically proves that vertical agents and specialized harness, tool, systems outperforms SOTA models alone still.

If you're using an apple phone to download the chatgpt app on the apple app store. That's still pretty much owning the ecosystem.

One thing that surprised me is how much code citation data is in most of the models training data already. Where the agents still fall apart is visual analysis like a corroded valve photo with a vague description and they'll confidently cite the wrong API standard. That gap is most of where the 87% delta comes from for us.

Happy to walk through specific cases if anyone wants to dig in.