findjashua

Would it be fair to say that this is tailored for tool-selection subagents?

You're absolutely right!

nasdaq & russell, yes. but not s&p - that has a 6-month requirement for eligibility, which ensures stock is past the lock-up period.

almost all 401k plans offer funds based on s&p 500, not nasdaq/russell others. s&p has also halved their trading days requirement from 1 yr to 6 months, but that's still sufficient to be past the post-ipo lock-up period.

It's not even a fair comparison - the effort involved in learning and building stuff from the internet (in the pre-LLM era) is an order of magnitude higher than turning your OAI/Anthropic account into an absolute slop cannon.

I'm primarily backend dev, but want able to prompt my way into building tiny JS web apps for personal use.

Wife always wanted to write animated story books for kids, and was actually able to create a bunch with Gemini (our daughter enjoys these more than the store-bought ones, since they're tailord/personalized for her).

won't this essentially disable prompt caching, that you get from a standard append-only chat history?

failed the car wash test.

i think instead of postiioning as a general purpuse reasoning model, they'd have more success focusing on a specific use case (eg coding agent) and benchmark against the sota open models for the use case (eg qwen3-coder-next)

you need a reviewer agent for every step of the process - review the plan generated by the planner, the update made by the task worker subagent, and a final reviewer once all tasks are done.

this does eat up tokens _very_ quickly though :(

providers' ToS explicitly states whether or not any data provided is used for training purposes. the usual that i've seen is that while they retain the right to use the data on free tiers, it's almost never the case for paid tiers

i workshop a detailed outline w it first, and once i'm happy w the plan/outline, i let it run while i go do something else

NME at all - 5.1 codex has been the best by far.

i think the standard recommendation is to do range partitioning on the hash of the key, aka hash range partitioning (i know yugabyte supports this out of the box, i'd be surprised if others don't). this prevents the situation of all recent uuids ending up on the same shard.

RAG != EBR

why can't you create separate git worktrees, and open each worktree in a separate IDE window? then you get the same functionality, no?