One prompt burned through half of his $200 monthly plan.
That is the sentence in this video that should stop you, and it is the reason the
chapter at 10:13 is the whole thing.
Here is the number that should end the "just add more agents" reflex for good.
Anthropic's own multi-agent research system outperformed a single agent by 90.2% on
their internal eval. Everyone quotes that.
Nobody quotes the rest of the same analysis:
→ it consumed roughly 15x the tokens
→ token usage alone explained about 80% of the performance variance
→ tool calls explained ~10%
→ model choice explained ~5%
Read that last line again. The model you argue about on the timeline is the smallest
term in the equation.
Which makes fanning out a purchase decision, not an architecture decision. It clears
when the task is worth more than the tokens, and it does not clear the rest of the time
- and there is no amount of prompt engineering that changes that arithmetic.
More agents is a thing you buy. Better routing is a thing you design. Only one of them
gets cheaper over time.
That is the whole argument, and it is here ↓
375,740 people have traded on fomo.
229 of them made more than $10,000.
that's 0.06%. the full ladder, off dune:
> 357,528 lost money or made under $100 — 95.2%
> 3,504 cleared $1,000 — 0.9%
> 653 cleared $5,000 — 0.17%
> 229 cleared $10,000 — 0.06%
everyone's reading that as "the app is a scam." that's the boring takeaway. the interesting one is what the leaderboard is actually measuring.
i've had to build PnL attribution before. here's where those numbers come from and where they lie:
> a fomo profile is a social handle mapped to a wallet. that mapping is not reliably 1:1
> the board shows realized + unrealized on tracked positions
> unrealized on an illiquid token is a quote, not money. a $600k position in a $900k mcap coin cannot exit at $600k
> cost basis is reconstructed from the swaps the indexer sees. transfers in, airdrops and seeded supply all distort it
> where wallets are shared or rotated, some buys sitting under a famous name were never that person's
so the board ranks two different populations and prints one number for both: people who are genuinely good, and people holding an unexitable bag at a flattering mark.
the second group is who most of you are copying.
how to actually read it:
> sort by realized, not total
> size the position against real liquidity, not market cap
> look for repeated 3–5x, not one 400x. a lottery ticket is not a strategy
> watch exits, not entries. entries are free to post. exits cost the poster their edge
the 0.06% isn't proof the game is rigged.
it's proof the scoreboard is showing you the wrong column.
Eleven use cases in 22 minutes. Watch it with one question in your head and it becomes
a completely different video:
for each of these, could a machine tell you it went wrong?
→ 00:31 - email agent
→ 07:00 - calendar agent
→ 08:13 - browser tasks
→ 10:20 - coding ← a machine can absolutely tell you this went wrong
→ 12:35 - food delivery
→ 13:50 - meeting summary
→ 15:39 - chief of staff agent ← nothing can tell you this went wrong
→ 18:21 - computer cleanup
→ 19:50 - messaging
Run the question down that list and it splits cleanly in two.
Coding fails loudly - a test goes red, a build breaks, a diff will not apply. You can
leave it running.
A meeting summary, a chief-of-staff decision, a sent email: nothing comes back. There
is no red. The system's confidence and the system's correctness are unrelated numbers
and only one of them is visible to you.
Both piles are legitimate. They just need completely different treatment, and almost
every setup I see treats them identically - because the second pile is where the
impressive demos live.
The demos are impressive precisely because nobody is checking.
Sorting the two piles is Part 2, and everything else follows from it ↓
An agent opens a website. It hits an email gate. It enters its own email address,
opens its own inbox, retrieves the code, and lets itself in.
No human in that loop at any point.
→ 00:57 - install and connect the accounts
→ 05:20 - building the team, and how a soul file controls each agent's role
→ 14:13 - inbox rules, and giving agents their own email addresses
→ 20:47 - the live demo: an agent passing email verification on its own ← watch this
→ 26:12 - daily cron jobs, and the honest verdict at the end
I want to be precise about why 20:47 is worth your attention, because "agent does thing
autonomously" is the most devalued sentence on this website.
Email verification is not a task. It is a trust boundary. It exists specifically to
establish that a human is present. An agent with its own inbox does not defeat that
check - it satisfies it, legitimately, as its own identity.
That is a different thing from automation and it deserves a different word.
Two honest constraints from the same video, which is why it is worth watching rather
than reading a summary:
→ one session used 14% of his weekly quota on the entry plan
→ macOS and iOS only at the time of recording
Two rules I would not run this without, and both are in there:
→ draft-only email rules, so nothing sends without approval
→ restrict inbox and calendar access to the specific agents that need it
The perimeter argument in full is Part 11 ↓
you cannot outbid a sniper on robinhood chain.
that's not an opinion. it's in the sequencer.
everybody brought their ethereum instincts here and is getting eaten by them.
the boring specs first - RH chain is an arbitrum orbit chain running nitro. ETH for gas, full EVM, ~100ms blocks, transaction data posted to ethereum in blobs. nothing surprising.
the part that changes how you trade:
> a single sequencer, operated by robinhood, orders every transaction
> ordering follows arrival time, not a priority-fee auction
> paying a higher gas price does not move you ahead of anything already queued
> the validator set is permissioned
> compliance screening happens at the sequencer level
read it twice. on ethereum you win a snipe with money. here you win it with latency.
what that actually means:
> gas wars are theater. a 10x tip buys you exactly nothing
> the winner is whoever's packet lands first. proximity, connection quality, fewer hops
> "i got frontrun" on this chain usually means "someone was closer", not "someone paid more"
> every bot ported over from pumpfun priority-fee logic is burning ETH for zero edge
> and one sequencer doing compliance screening is one policy change away from being a filter, not just an orderer
half of CT is optimizing gas settings for a chain that doesn't sell the thing they're trying to buy.
Almost every "AI agents" video shows you one product. This one shows two products doing
the halves neither can do alone, and the structure is the lesson.
→ 02:10 - structuring the system ← the part to actually watch
→ 04:15 - setting up the foundations
→ 07:48 - creating the client brief
→ 11:40 - setting up the second agent
→ 18:06 - testing
→ 22:46 - deploying it as a daily routine
→ 25:42 - pricing it
Watch the order of operations, because it is the correct one and it is not obvious:
The qualification rules and the research schema get written first, in files, in a
code editor. Only then does the browsing agent get pointed at the internet.
That is the demotion rule working in the wild. The rules are file-shaped, so they live
where things can be diffed and versioned. Only the part that genuinely requires being
signed into a live browser goes to the agent that is signed into a live browser.
Do it in the other order - start with the browsing agent and let it work out the rules
as it goes — and you get a system whose logic exists only inside a chat log, which
means you cannot audit it, cannot version it, and cannot fix it without starting over.
Same two products. Same 26 minutes. Completely different outcome, decided entirely by
which floor you started on.
Anthropic cut roughly 80% of Claude Code's own system prompt when Opus 5 shipped.
Eighty percent. Deleted. By the people who wrote it.
Every instruction you have ever added to a config file was written to compensate for a
model that no longer exists. Most people never take any of it back out - they just keep
stacking, and pay for the whole stack on every single turn.
Boris Cherny's rule for what to delete is one question:
→ Would the model have worked this out on its own? If yes, delete it.
Three more things from the same interview that are worth more than most courses:
→ Say what you want, not how to do it. He says experienced engineers are the worst at
this — they specify the method and get the method instead of the result.
→ Hand an agent an inspiration image and you get a near copy. Describe it and it works
out its own approach.
→ Order of operations: prompt, then the config file, then a skill, then MCP only when
the model genuinely cannot reach the information otherwise.
And the one that reframes everything: an eval is a check strict enough to fail. He had
Claude rebuild a desktop app with a pixel-by-pixel screenshot comparison as the gate,
and it ran for over two weeks.
Without a check like that, he notes, an agent stalls out inside an hour.
Two weeks versus one hour. Same model. The check is the entire difference.
the most important piece of infrastructure in memecoins right now is not a chain.
it's a 4-digit number.
i spent years on payments infra at meta before i started shipping onchain. that's the only reason this jumped out at me.
when you buy a memecoin with apple pay inside fomo or robinhood wallet, here's what actually happens:
> checkout is embedded in the app, not a redirect to an onramp
> crossmint's token checkout orchestrates the card leg
> no separate KYC step for you
> the swap settles onchain. you never touch a CEX
now the part nobody reads. every card transaction carries a merchant category code. crypto purchases are supposed to ride MCC 6012 or 6051, flagged as crypto, ineligible for rewards.
The Block ran test buys of $WIF on both visa and mastercard. they came back coded 5815 - "books, movies, digital artwork or music delivered in electronic format." no crypto flag. normal card rewards paid out.
the defense offered: the march 2026 SEC/CFTC joint guidance named WIF a "digital collectible."
that argument exists in securities law. it does not exist in card network rules. there is no collectible exception in the visa rulebook.
what happened next:
> chase decided the code was wrong and opened a case with visa
> the NY attorney general's office started reviewing it
> visa and mastercard both declined to comment
why you care as a trader and not a lawyer: this rail is the widest retail door crypto has ever had. fomo went 7x weekly active traders after the crossmint integration. 68,000+ first-time crypto buyers came through apple pay checkout.
one field. one re-code. door shuts.
i don't think it survives Q4 in its current shape. build like it doesn't.
Five levels of things to do with GPT-6 Astra. Four of them are what you expect.
Level 1 is not, and it is 90 seconds long:
A prompt that interviews you one question at a time, finds the single bottleneck
holding your business back, turns it into a 90-day plan — and then makes a second
model argue with that plan.
→ 00:22 - Level 1: the interview, the bottleneck, and the cross-model debate
→ 01:58 - Level 2: a business intelligence system from one prompt
→ 04:58 - Level 3: one-shot websites with generated images and video
→ 08:35 - Level 4: UI systems from component libraries
→ 11:37 - Level 5: auditing your own spending
Levels 2 through 5 are one model doing more. Level 1 is two models checking each other,
and that is a categorically different thing.
Here is why it works, and it is the same reason the rest of this account exists:
A model reviewing its own plan sees every reason it wrote the plan that way, so it
approves. That is true of every model on the board. A real check has to come from
outside the run.
Two models from two vendors is the cheapest external check that exists. It costs one
extra prompt.
The version of this that scales past two prompts is the whole playbook ↓
Five levels of things to do with GPT-6 Astra. Four of them are what you expect.
Level 1 is not, and it is 90 seconds long:
A prompt that interviews you one question at a time, finds the single bottleneck
holding your business back, turns it into a 90-day plan — and then makes a second
model argue with that plan.
→ 00:22 - Level 1: the interview, the bottleneck, and the cross-model debate
→ 01:58 - Level 2: a business intelligence system from one prompt
→ 04:58 - Level 3: one-shot websites with generated images and video
→ 08:35 - Level 4: UI systems from component libraries
→ 11:37 - Level 5: auditing your own spending
Levels 2 through 5 are one model doing more. Level 1 is two models checking each other,
and that is a categorically different thing.
Here is why it works, and it is the same reason the rest of this account exists:
A model reviewing its own plan sees every reason it wrote the plan that way, so it
approves. That is true of every model on the board. A real check has to come from
outside the run.
Two models from two vendors is the cheapest external check that exists. It costs one
extra prompt.
The version of this that scales past two prompts is the whole playbook ↓
The most useful line written about agent security this year is in a product review,
and it is nine words long:
"one shared computer authorizes every bot at once"
Read it twice. That is the feature and the risk in the same sentence, and there is no
version of the product where you get one without the other.
The review is worth the 19 minutes:
→ 01:10 - the agent signup pain point this actually solves ← the setup for everything
→ 06:55 - the twelve bots he built
→ 09:41 - what the $200 subscription actually costs, as opposed to what it charges
→ 12:25 - the two bots worth starting with
His verdict is the balanced one: the first agent product he would hand to someone
completely non-technical - and that same shared computer is the one security perimeter
you accept when you do.
So the perimeter is not per-bot. It is per-account, and it is permanent.
Three rules, and they cost nothing:
→ connect only what is currently needed, and disconnect what stops being needed
→ never type a credential into a chat message - the correct pattern is the login
handoff, where the bot hits the wall, hands you the screen, and resumes with a
session instead of a secret
→ draft-only by default on anything outbound
That third one is what turns an always-on system from a liability into an employee.
robinhood has been paying your gas.
that ends september 29.
since launch, qualifying swaps through robinhood wallet have had gas covered. the current offer runs to 11:59pm EST, september 29, 2026.
the mechanism, since nobody says it out loud: this is ERC-4337 account abstraction. a paymaster sponsors the userop so your wallet never needs to hold ETH first.
that single design decision is most of why this chain onboarded so fast. "go buy ETH for gas before you can do anything" is the worst funnel in crypto and they deleted it.
what i'm watching on september 30:
> does the paymaster quietly keep running
> does it narrow - specific pairs, per-user caps, wallet-only
> do daily active wallets hold, or does the subsidized half walk
> memecoins are 80%+ of chain volume, so that cohort eats the change first
> at ~100ms blocks the gas per swap is small, which makes the honest question whether the subsidy was ever the driver or just the story
context for what's at stake: $1.595B in daily DEX volume on sept 1, first-ever day above $2B in spot DEX volume, roughly $20B cumulative in ~70 days, $3–4M a day in revenue.
if that volume is real, ending a gas subsidy costs them nothing.
if it isn't, you'll see it inside 48 hours.
put sept 30 in your calendar. it's a free read on whether any of this is organic.