Pinned Tweet
AI video clippers SUCK. Build your own.
Anyone can write their own software and agentic workflows. Reverse engineering tools with AI is not enough. The true edge comes from understanding and solving your unique problems.
Here's how I save 15+ hours a week.
I livestream on X. Editing clips and shorts from livestreams is unglamorous and painstaking, but that's where most views come from. People wonder how I publish so much video content consistently... so here it is. I hope it gives you insights : )
My 30+ agent system doesn't give me choppy, awkward, disjointed clips and shorts. This is the full breakdown of how it works and gets results, with a real run in Claude Code CLI and local models, sped up on the screen recording below.
I built a career in video editing, so I know what a good cut looks like. I also know what a proper workflow and deliverables look like. While my video editing agents churn, I do other work or go for a walk.
And if this looks "complex"... you should try manually editing hours of clips week after week in Davinci or Capcut lmaooo
WHAT IT DOES
I stream live on X weekly through OBS and the input for this run (shown below) was a 2 hour 26 minute stream. The output was a published episode: a corrected transcript (JSON), chapters, shownotes (a Markdown page), 15 clips (MP4 video files) cut and captioned and uploaded to Google Drive, 5 of them queued on YouTube as private videos, and a page live on my site. The run took about 2 hours. 15+ hours down to a few minutes of decision making.
So, I type one command into Claude Code (a custom /show-wrap skill). I answer two questions at the start: is there a guest, and is there anything I want the clip search to look for. In the middle I pick the clips and sign off on the cut plan. The rest runs on its own.
A push notification API hooked into Claude pings my devices whenever it needs me so I can get on with my life and other work without babysitting my machine.
HOW IT WORKS
Seven stages, numbered 0 to 6, plus a final check. Two kinds of agentic workers do the job.
AI agents (separate model calls, each with one narrow job) do the judgment work: reading, proposing, scoring, writing. Code does everything that has to be exact: timestamps, vote counting, cutting, uploading, checking.
Every stage saves a checkpoint (JSON). If a run is interrupted it resumes where it stopped and remembers my two answers. On resume it re-checks each finished stage's output files, by hash (a fingerprint of the file's exact contents) wherever the stage recorded one (agents can hallucinate).
STAGE 0 → Capture and normalize
An agent pulls the replay from X creator studio via headless Playwright browser (Chrome). The main session then fingerprints the file and records it.
Next the file is normalized (re-encoded so the audio and video timing match exactly). A raw X livestream capture has tiny gaps in its audio packets that collapse when the file is decoded, so the transcript slowly drifts against the video.
STAGE 1 → Transcribe
WhisperX (an open-source speech-to-text system) runs locally with the large-v3 model, in the background. A vocabulary of names and terms from earlier shows is fed in so the model hears them right (self learning).
A check confirms the output belongs to this exact file, contains real segments, and has its manifest (the run's record of how it was made). Meanwhile the normalized master is archived to Google Drive.
STAGE 2 → Correct transcripts
Auto AI transcripts mangle names, even from good AI models. Nothing here is edited in place. Every change goes through a ledger (a written record of each fix).
This stream had 1,223 transcript segments and 482 distinct proper nouns. Each one is listed with how often it appears, and each needs a decision: correct it, or confirm it as is. The ledger changed 9 segments.
A second check compares the transcript against every name I have ever published on the show, and flags near misses and known misspellings that survived. A validator agent compares corrected against raw, looking for dropped substance and changes that altered meaning. It gets three passes in total. After that the run stops and asks me, as an escape hatch.
The corrected file is stamped with its correction map, and later stages refuse any file without it, so the raw version can never flow downstream by accident.
STAGE 3 → Topics & chapters
A "topic" is a stretch of the show where I cover one subject, and it becomes a HH:MM:SS chapter in the shownotes. This is the hardest step to get right with AI.
A live show wanders: I read a post, riff on it for ten minutes, drift to something else, and come back later. A single model pass over 2.5 hours tends to lose the middle, and two readers rarely agree on exactly where a topic starts.
So five boundary-finder agents each read the whole transcript independently and propose where topics start. Code groups proposals that land within 17.5 seconds of each other, and a boundary needs 4 of the 5 to count. Three more calls then find where each chapter ends cleanly.
Agents can lie, so how do I know an agent read all 2.5 hours? The transcript goes to it as a file with unique markers woven through it, and it has to list the markers back in order. An agent that read the first page and the last cannot produce them. A response whose markers don't reconcile is thrown out.
Each answer comes back through a relay (a step that carries it from the agent to the files) that stamps a hash on it, and the collector rejects anything hand-placed or edited.
If one agent fails, it gets one retry on an identical prompt. If two fail, the run hard-stops. Two failing the same way means something is wrong, and re-running an unchanged prompt burns calls that cannot succeed.
Chapters are checked before the shownotes render: at least three, the first at zero, at least 10 seconds apart, and the last one starting past the 80 percent mark.
STAGE 4 → Find the clips
Three generator agents each read the whole show and propose clips. They quote the exact words where a moment starts and ends, and code finds the time in the word-level transcript. A quote that doesn't resolve is discarded with a reason.
Code merges the three lists. Two proposals count as the same moment only if they overlap in time and their titles share words.
Three scorer agents then rate each candidate high, medium, or drop and code settles it: "keep" versus "drop" is decided first, a tie goes to "keep", and the tier is the majority among the keeps.
A researcher agent looks up real X usernames and writes a grounded one-line summary for each clip. Another agent writes a summary of the whole show and a list of every brand and entity mentioned (web searching). One last agent checks any clip that only one run proposed, to see whether it cuts away just before its payoff (important for vibes).
On this stream: 27 candidates scored, 9 high, 17 medium, 1 dropped, 26 shown to me.
STAGE 5 → My gate (push notification)
This is the part I do (faster than reviewing with a human editor). The pool is grouped by tier, with timestamps, vote counts, entities with handles, and a summary for each clip. If the scorers dropped a clip that at least one run liked, it is shown too, so the disagreement is mine to settle.
I approve and the system tells me exactly which candidates I skipped, so I know what I left out. For YouTube I go through the stream in four equal quarters and pick from each. Easy peasy.
Then I see a dry run of the cut plan: how each clip will be treated, what will be removed, and a sample frame of the vertical crop. It states plainly what happens next: files cut, uploaded to my Drive, inserted as private YouTube videos, and an entry pushed to my site. My approval is tied to a hash of the exact approved clip list.
The cut, the Drive clip upload, the Drive shownotes upload, and the YouTube insert each re-hash that list when they run and refuse if it doesn't match. Change one clip after I approve and the approval is void. Re-rendering an approved clip keeps my approval, and changing the set of clips does not.
This stream: I approved 15 of the 26 and picked 5 for YouTube.
STAGE 6 → Cut, caption, publish (hard part)
Each approved clip is routed by length: Short (a vertical 9:16 version only, with burned-in captions, under 2mins), Clip (over 2mins a landscape master plus a captioned vertical), Highlight (5mins and up, a paced render, with dead air tightened and off-topic stretches in the middle removed).
Pacing is conservative. A gap in the transcript only proposes a cut, and the audio waveform can veto it. If there is audible sound in more than 5 percent of the gap, any brief loud sound, or the gap is shorter than 0.12 seconds, the pause stays. Removing off-topic speech is deliberate and produces its own list of every removal for me to review. Everything is loudness-normalized in two passes to -14 LUFS (a common streaming loudness level).
Captions run two to three words at a time with the active word highlighted, burned into the vertical version only. If captioning fails, the clip ships without them and the reason is recorded.
Four automatic check agents run on every cut before upload. One looks for words cut in half at the start or end, or a clip that opens on dead air. One measures audio levels, splices, and dead air. One reports what pacing removed and whether captions landed. One checks each file's audio timing. A clip that fails the first or last check is held back alone with its file kept, and the rest ship.
This stream: 15 approved clips became 16 files. 13 ran 2 minutes or longer, 1 was a short, and 1 ran just under 2 minutes. The short and the under-2-minute clip are the 2 captioned vertical versions, which is why 15 clips make 16 files.
Each file goes to Google Drive as an upsert (create, or replace the existing file), so a re-render replaces and never duplicates.
Before the shownotes page and the YouTube copy go out, the run looks up every username on X. This stream checked 27 handles. Each run adds to a ledger of known handles that is now over 300 (saves future work.
For the 5 YouTube picks, three writer agents each draft chapters from the clip's own transcript, code merges them and fixes the timing, and a fourth agent writes the title, description, and tags from a written style guide for my voice. I read the copy before anything is inserted. Everything goes in as a private video, and making one public is my step in YouTube Studio.
Last, the website entry. It is built from the checkpoint alone: runtime, a frame from the show, and the guest field from my first question. The site's own checks run, the entry is pushed, and the run waits until the page is confirmed live.
THE FINAL CHECK
Before the commit, an automatic text check runs over everything the run wrote. Then a fact reviewer agent re-fetches each claim in the shownotes from its source, not from memory. After a fix it gets two more tries, and a third failure holds the commit.
A publication audit then compares every link on the published page to what is live on Drive. For this stream: 0 problems across 16 published links and 16 live clips.
...AND IT'S DONE
I get another ping on my phone.
I have a Google Drive folder with all the clips ready to post, chapters and shownotes, transcript, my website is updated, the full recording is there, my website is updated, videos are ready to publish on my YouTube creator dashboard and I can go about my day.
CONSTANT EVALUATION
After each session, I have agents review the runs of previous streams to diagnose issues, harden the system and update dependancies or A/B different methods. I will soon be incorporating TypeSafe Jev for faster decision making on timestamped transcript work, possibly saving an hour of agent work and hundreds of thousands of expensive tokens.
That is what I mean by evaluation. Every stage has a check, and every check has a named reader: code that blocks the run, or me. In my design, a result that nobody acts on counts as a defect.
Each run also leaves the next one with more. The handle ledger, the names vocabulary, and the list of names I have published all carry over, and every run reads them before it starts.
THANKS FOR WATCHING
A few of you have said you want a system like this for your own work. I would build it the way I built mine: start from how you actually work, then check every step. That is why it has to be bespoke.
DM me here or reach me through my site : )
Below I'll attach the Google Drive folder with everything shown from the episode and more. A big shoutout to all my viewers and supporters, it's amazing what you can do with AI but the key is...
Know what problem you are trying to solve!
See the system in action below...
Anthropic: files the big S-1
OpenAI: hold my beer
We are announcing three new discoveries in mathematics, computer science, and physics about harmonic analysis, complexity theory, and quantum field theory.
openai.com/index/building-sc…
Brandon Davenport retweeted
Our Hedera deep dive is out: five reports, a price model you can adjust, and a Research Desk that answers questions from the reports. $39.
Usage, revenue, treasury runway, staking, Hedera vs Canton, and the HBR ETF traced via SEC filings and the ledger.
crypto.capeislandpoint.com/h…
aligned incentives builds a healthy ecosystem, i dig what’s happening on @CantonNetwork
GM
Canton's burn and mint model, sharpened by CIP-0129, ties network rewards to the applications and users generating real economic activity, extending beyond validators and infrastructure operators.
@ItsBrandonD explains why that matters for tokenomics.
#7 is absolutely key
"Our company culture has contributed to our success and, if we cannot maintain this culture as we grow, our business could be adversely affected."
most overlooked thing
Anthropic Risk Factors via the S-1:
1. Our success depends in large part on our ability to continue to develop the most advanced and capable AI models, and any failure to do so could adversely affect our business.
2. If we are unable to secure adequate compute or if we fail to direct our compute effectively across our workloads, we may be unable to train models that remain competitive with those of our competitors or adequately serve our customers.
3. If our actual compute requirements differ materially from our projections, we may fail to secure sufficient compute to meet our needs or we may be committed to excess compute that remains underutilized.
4. Constraints on the critical inputs supporting compute could limit our ability to secure adequate compute.
5. We are highly dependent on the continued service of our co-founders, senior management team, and key technical employees, and the loss of any of these individuals may adversely affect our business, financial condition, and results of operations.
6. We may require additional capital to meet our substantial ongoing obligations and support our business growth, and our ability to generate sufficient revenue and secure additional capital on acceptable terms is critical to our continued operations and competitive position.
7. Our company culture has contributed to our success and, if we cannot maintain this culture as we grow, our business could be adversely affected.
8. We face intense competition, and if we are unable to compete effectively, our business, financial condition, and results of operations could be adversely affected.
9. If we fail to attract new customers, retain existing customers, or expand usage of our models, platform, and applications, our business, financial condition, and results of operations could be adversely affected.
10. If the market for our models, platform, and applications develops more slowly than we expect or declines, our growth may slow or stall, and our business, financial condition, and results of operations could be adversely affected.
11. The political environment and our engagement with policymakers and public positions on AI regulation and safety could subject us to heightened scrutiny, political backlash, or disproportionate regulatory action.
12. If the use of our AI models results in harm, whether through use by malicious actors or misuse by other third parties, or if our model guardrails or safeguards fail to prevent such misuse, our reputation and brand, business, financial condition, and results of operations could be adversely affected.
13. Our AI models may behave in unintended, misaligned, or autonomous ways, including by taking harmful actions that no user or third party directed, which could adversely affect our reputation and brand, business, financial condition, and results of operations.
14. We may be exposed to liability, litigation, and regulatory action arising from harms associated with our AI models, and our contractual protections and insurance may be insufficient, any of which could adversely affect our business, financial condition, and results of operations.
15. If we are unable to manage the risks related to our focus on and commitment to AI safety, our brand, business, financial condition, and results of operations could be adversely affected.
16. If we are unable to maintain and enhance our brand and reputation, our business, financial condition, and results of operations may be adversely affected.
17. We derive substantially all of our revenue from a limited number of products and applications, and our failure to maintain and expand our product portfolio could adversely affect our business, financial condition, and results of operations.
18. A substantial portion of our revenue and accounts receivable is driven by a limited number of customers and distribution channels, and the loss of, or a significant reduction in, spend from one or more of our top customers or disruption through those channels could adversely affect our prospects, business, and financial condition.
19. We have incurred significant indebtedness in order to operate and grow our business, including to fund our substantial compute commitments, and our ability to service this indebtedness may be constrained by our cash flows and liquidity.
20. We may not have the ability to raise the funds necessary to repay the principal and accrued interest of our outstanding convertible promissory notes or the A&R Credit Agreement in cash when required by the terms of the notes or the A&R Credit Agreement, as applicable, or at their maturity.
21. Our pricing structures for our models, platform, and applications change from time to time, which could adversely affect our business, financial condition, and results of operations.
22. If we are unable to attract, retain, or motivate highly skilled personnel, we may not be able to grow or operate effectively.
23. We have a limited operating history in an evolving and nascent industry, which makes it difficult to evaluate our future prospects and may increase the risk that we will not be successful.
24. We are at an early stage of our revenue growth, we have experienced rapid growth in recent periods, and our historical growth rates are not indicative of future performance or our ability to sustain or forecast future revenue growth.
25. If we fail to manage our growth effectively, our brand, business, financial condition, and results of operations could be adversely affected.
26. We have a history of net losses and may not generate sufficient revenue to achieve or sustain profitability in the future.
27. Our results of operations may fluctuate significantly on a period-to-period basis, including as a result of strategic investment decisions and substantial compute-related expenditures, which could cause the market price of our Class A common stock to decline.
28. Certain of our operating metrics are subject to assumptions and limitations. As a result, these metrics may not provide an accurate indication of our actual performance or future results.
29. Our business is subject to an evolving and uncertain regulatory and political environment, which could increase our costs, restrict our operations, or adversely affect demand for our models, platform, and applications.
30. Our sales to government entities and highly regulated organizations are subject to challenges and risks.
31. Our reliance on a limited number of CSPs and suppliers, some of which have strategic and investment relationships with us and are our customers, creates complex dynamics that could give rise to conflicts of interest and adversely affect our access to compute.
32. We are pursuing initiatives to develop our own data center infrastructure, which involves significant capital commitments, operational complexities, and execution risks that could adversely affect our business, financial condition, and results of operations.
33. We may not successfully build, expand, and deploy our sales and marketing organization in a timely manner, or we may not successfully hire, retain, train, and motivate our sales personnel.
34. We have a limited history under our current go-to-market strategy, and our efforts to scale and evolve our customer acquisition, engagement, and retention model may not be successful.
35. Sales to enterprise customers involve complexities and risks that could adversely affect our business, financial condition, and results of operations.
36. If our marketing strategies, such as our free trials and free tiers, fail to generate the benefits we expect, or if their costs exceed those benefits, our ability to grow our revenue could be adversely affected.
37. If we fail to maintain high-quality customer support, our ability to retain and expand customers could suffer, which may adversely affect our prospects, business, financial condition, and results of operations.
38. Our product and investment decisions may not prioritize short-term financial results and may not align with investor expectations or preferences, which could adversely affect the market price of our Class A common stock.
39. Our investments in new products, technologies, and business initiatives may not produce the expected benefits and could adversely affect our business.
40. If we fail to manage our technical operations infrastructure, or experience service outages, interruptions, or delays in the deployment of our models, platform, and applications, our results of operations may be adversely affected.
41. If we are unable to make acquisitions and investments, or successfully integrate them into our business, our business, financial condition, and results of operations could be adversely affected.
42. Unfavorable media coverage regarding our business, our models, platform, and applications, the impacts of AI, and the AI industry more broadly could adversely affect our business, financial condition, and results of operations.
43. We will incur increased costs and demands upon management as a result of complying with the laws and regulations affecting public companies, which may adversely affect our business, financial condition, and results of operations.
44. Our business, financial condition, and results of operations may be adversely affected by war, terrorism, natural disasters, public health crises, political crises, or other unexpected events.
45. If we are unable to ensure that our models, platform, and applications interoperate with a variety of software applications that are developed by others, including our integration partners, we may become less competitive and our business, financial condition, and results of operations may be adversely affected.
46. Many of the risks we face are interconnected and may compound or trigger cascading adverse effects across our business, which could amplify their overall impact.
47. The application of certain copyright law doctrines and contractual interpretations of open-source licenses to modern AI model training are uncertain.
48. We are subject to complex and evolving laws, regulations, and other legal obligations related to privacy and data protection, and any actual or perceived failure to comply with such obligations could adversely affect our business, financial condition, and results of operations.
49. We process personal and sensitive data for AI safety, and any actual or perceived failure to comply with the legal and regulatory obligations applicable to such processing could adversely affect our business, financial condition, and results of operations.
50. Any security breaches or other incidents, including those that affect our networks, systems, or data, or the networks, systems, or data of our service providers, suppliers, or customers, could adversely affect our business, financial condition, and results of operations.
51. We employ automated data collection across the web and use other methods to collect data for training our AI models, and such activities may subject us to liability or limit our ability to use the collected data, which may adversely affect our business, financial condition, or results of operations.
52. We collect, integrate, and analyze data via agreements from multiple sources, including data provided by our customers and users and data sourced from third parties under contractual arrangements, and such activities may subject us to liability or limit our ability to use the collected data, which may adversely affect our business, financial condition, or results of operations.
53. We have been, are currently defending against, and may in the future be, subject to intellectual property rights claims by third parties, which are extremely costly to defend, may require us to pay significant damages and may limit our ability to use certain technologies, which may adversely affect our business, financial condition, and results of operations.
54. If we fail to adequately protect our intellectual property rights, our competitive position may be impaired, and we may lose valuable assets, generate reduced revenue, and incur costly litigation to protect our rights, which may adversely affect our business, financial condition, and results of operations.
55. We incorporate open-source software in our models, platform, and applications, which may subject us to litigation or other requirements, each of which may adversely affect our business, financial condition, and results of operations.
56. We currently, and may in the future, license technology from third parties for use in our models, platform, and applications, and our inability to maintain those licenses could adversely affect our business, financial condition, and results of operations, and our use of such third-party technology could subject us to litigation.
57. Our development of solutions that replace or reduce reliance on third-party vendors may expose us to litigation and other disputes.
58. We may be subject to claims that we or our employees have misappropriated the intellectual property of other companies, particularly as we hire employees from other AI and technology companies.
59. We are subject to claims, lawsuits, investigations, executive and administrative orders and directives, other regulatory actions, and various actions and proceedings, and face potential liability, expenses for legal claims, and harm to our business.
60. We are subject to anti-corruption and anti-bribery laws, anti-money laundering laws, and similar laws.
61. Governmental trade controls, including export and import controls, sanctions, customs requirements, and related regimes, could subject us to liability or loss of contracting privileges or limit our ability to compete in certain markets.
62. To continue to grow our business, we will need to continue to expand internationally, and our non-U.S. operations and sales to customers outside of the United States expose us to risks inherent in international expansion, sales, and operations.
63. Increasing scrutiny and changing expectations from global regulations, our investors, customers, and employees with respect to ESG may result in additional compliance risk and costs and may impact our reputation and business.
64. If we or our payment processing partners fail to manage the risks related to our payment processing activities, we could be subject to fines, regulatory scrutiny, disruptions to our business, or reputational harm.
65. Changes in tax laws or regulations could be enacted, or existing tax laws or regulations could be applied to us or our customers in a manner that could increase the costs of our models, platform, and applications and adversely affect our business.
66. Our business, financial condition, and results of operations may be adversely affected if we are required to collect sales or other related taxes for subscriptions to our models, platform, and applications in jurisdictions where we have not historically done so.
67. Our ability to use our net operating loss carryforwards and certain other tax attributes may be limited.
68. Our corporate structure and intercompany arrangements are subject to the tax laws of multiple jurisdictions, and we could be required to pay additional taxes, which could adversely affect our business, financial condition, and results of operations.
69. If our judgments or estimates relating to our critical accounting policies prove to be incorrect, our results of operations may be adversely affected.
70. If we fail to maintain an effective system of disclosure controls and internal control over financial reporting, our ability to produce timely and accurate financial statements or comply with applicable regulations may be impaired, which may adversely affect our business, financial condition, and results of operations.
71. We are exposed to fluctuations in interest rates and currency exchange rates, which could negatively affect our business, financial condition, and results of operations.
72. Our capital stock structure features certain provisions that are novel or otherwise not common among other corporations with multiple-class structures, and may effectively eliminate the ability of holders of our Class A common stock to influence important decisions, including a change in control.
73. Our capital structure will concentrate voting power with the LTBT and the Founder LLC for the foreseeable future and will result in the LTBT and the Founder LLC having voting power that is not derived from or proportionate to economic interests in our company.
74. Our governance structure and the adoption of our amended and restated certificate of incorporation may negatively affect the decision by certain institutional investors to purchase or hold shares of our Class A common stock.
75. We are considered a “controlled company” within the meaning of the Nasdaq Global Select Market corporate governance requirements, and, as a result, we qualify for, and currently rely on, exemptions from certain corporate governance requirements.
76. We operate as a Delaware public benefit corporation. As a public benefit corporation, we cannot provide any assurance that we will achieve our Company Purpose.
77. Our focus on the long-term best interests of our company as a PBC, and the duty of our directors to balance the pecuniary interests of our stockholders, the best interests of those stakeholders materially affected by our conduct, and our Company Purpose, may conflict with short-, medium-, or long-term financial interests and business performance, which may negatively impact the value of our Class A common stock.
78. As a Delaware public benefit corporation, we may be subject to increased litigation concerning our board of directors’ obligation to balance our stockholders’ pecuniary interests, the best interests of those materially affected by our conduct and our Company Purpose, the occurrence of which may have an adverse impact on our business, financial condition, and results of operations.
79. Our amended and restated bylaws will designate a state or federal court located within the State of Delaware as the exclusive forum for substantially all disputes between us and our stockholders, and also provide that the federal district courts will be the exclusive forum for resolving any complaint asserting a cause of action arising under the Securities Act of 1933, as amended, each of which may limit our stockholders’ ability to choose the judicial forum for disputes with us or our directors, officers, stockholders, or employees.
80. Provisions in our amended and restated certificate of incorporation and amended and restated bylaws could make a merger, tender offer, proxy contest, or other significant corporate transaction difficult, potentially depressing the market price of our Class A common stock.
Brandon Davenport retweeted
Anthropic expects AI that rivals top human experts, works autonomously for weeks and controls robots to become widely available within a few years.
Its IPO filing makes super exciting claims:
- Expert-level autonomous systems "within a few years": Anthropic expects AI to match or exceed leading human experts across most professional and scientific disciplines. These systems would work for hours, days or weeks, coordinate with other agents, and operate laboratory equipment and robots through digital interfaces.
- Millions of highly capable agents: Anthropic’s vision is "a country of geniuses in a data center". Vast numbers of agents working in parallel across software, physics, mathematics, biology, medicine and engineering. The company expects exponential progress in AI capabilities to continue.
- AI is already accelerating the development of its successors: Claude helps run experiments, generate and process training data, automate evaluations and safety audits, and write research code. Anthropic calls this "closing the loop": better models help discover improvements that make the next generation more capable. It says over 90% of September’s codebase contributions were written by Claude.
- Scientific progress could accelerate dramatically: Anthropic sees the potential for “compressing decades of scientific progress into years”. It also reports discovering a molecular machine with Claude that might become a new biotechnology tool, potentially for gene editing. That remains an early research finding requiring validation.
- Compute could remain the limiting factor: Anthropic expects increasingly capable models to unlock new categories of work, keeping demand ahead of available compute for the foreseeable future. It also argues that today’s models already have capabilities the wider economy has barely begun to use.
some fast moving stuff
big shifts coming for itsbrandond
GM $CC
revenue retention is 900%
absolutely the most nutty hard number from the Anthropic S-1, and i can relate. when u start using these services as an early adopter, its so good and you spend more…
Anthropic has filed an S-1 registration statement with the SEC related to its proposed IPO.
Read more: anthropic.com/news/s1-sec
Legal disclaimer: A registration statement relating to these securities has been filed with the SEC but has not yet become effective. These securities may not be sold, nor may offers to buy be accepted, prior to the time the registration statement becomes effective. This post does not constitute an offer to sell or the solicitation of an offer to buy these securities, nor shall there be any sale of these securities in any state or jurisdiction in which such offer, solicitation or sale would be unlawful prior to registration or qualification under the securities laws of any such state or jurisdiction.
Brandon Davenport retweeted
Canton's burn and mint model, sharpened by CIP-0129, ties network rewards to the applications and users generating real economic activity, extending beyond validators and infrastructure operators.
@ItsBrandonD explains why that matters for tokenomics.
Brandon Davenport retweeted
some great, measured analysis on Hedera recently from @CapeIslandDgtl and tbh it’s more in-depth than my own breakdowns
i encourage you follow & read !
$HBAR
Since 2021, Hedera's treasury has released ~28% of HBAR's supply for ecosystem development, nearly all of it to three foundations. In 2026 it sued two of them.
I went through the court filings, Council minutes and the ledger. Both sides quoted. Free:
crypto.capeislandpoint.com/h…
100% this
There’ll be times where you over-guide the AI. It knows better than you and is more intelligent than you.
There’ll be times where you under-guide the AI. It can go off-track, have the wrong biases, or miss context.
How well you manage this superpower is the #0 skill I look for.
Brandon Davenport retweeted
“how do you keep up with posting so much content, it’s so time consuming to do video clipping?”
harsh reality: all “AI clipping tools” suck
here’s how i do it
AI video clippers SUCK. Build your own.
Anyone can write their own software and agentic workflows. Reverse engineering tools with AI is not enough. The true edge comes from understanding and solving your unique problems.
Here's how I save 15+ hours a week.
I livestream on X. Editing clips and shorts from livestreams is unglamorous and painstaking, but that's where most views come from. People wonder how I publish so much video content consistently... so here it is. I hope it gives you insights : )
My 30+ agent system doesn't give me choppy, awkward, disjointed clips and shorts. This is the full breakdown of how it works and gets results, with a real run in Claude Code CLI and local models, sped up on the screen recording below.
I built a career in video editing, so I know what a good cut looks like. I also know what a proper workflow and deliverables look like. While my video editing agents churn, I do other work or go for a walk.
And if this looks "complex"... you should try manually editing hours of clips week after week in Davinci or Capcut lmaooo
WHAT IT DOES
I stream live on X weekly through OBS and the input for this run (shown below) was a 2 hour 26 minute stream. The output was a published episode: a corrected transcript (JSON), chapters, shownotes (a Markdown page), 15 clips (MP4 video files) cut and captioned and uploaded to Google Drive, 5 of them queued on YouTube as private videos, and a page live on my site. The run took about 2 hours. 15+ hours down to a few minutes of decision making.
So, I type one command into Claude Code (a custom /show-wrap skill). I answer two questions at the start: is there a guest, and is there anything I want the clip search to look for. In the middle I pick the clips and sign off on the cut plan. The rest runs on its own.
A push notification API hooked into Claude pings my devices whenever it needs me so I can get on with my life and other work without babysitting my machine.
HOW IT WORKS
Seven stages, numbered 0 to 6, plus a final check. Two kinds of agentic workers do the job.
AI agents (separate model calls, each with one narrow job) do the judgment work: reading, proposing, scoring, writing. Code does everything that has to be exact: timestamps, vote counting, cutting, uploading, checking.
Every stage saves a checkpoint (JSON). If a run is interrupted it resumes where it stopped and remembers my two answers. On resume it re-checks each finished stage's output files, by hash (a fingerprint of the file's exact contents) wherever the stage recorded one (agents can hallucinate).
STAGE 0 → Capture and normalize
An agent pulls the replay from X creator studio via headless Playwright browser (Chrome). The main session then fingerprints the file and records it.
Next the file is normalized (re-encoded so the audio and video timing match exactly). A raw X livestream capture has tiny gaps in its audio packets that collapse when the file is decoded, so the transcript slowly drifts against the video.
STAGE 1 → Transcribe
WhisperX (an open-source speech-to-text system) runs locally with the large-v3 model, in the background. A vocabulary of names and terms from earlier shows is fed in so the model hears them right (self learning).
A check confirms the output belongs to this exact file, contains real segments, and has its manifest (the run's record of how it was made). Meanwhile the normalized master is archived to Google Drive.
STAGE 2 → Correct transcripts
Auto AI transcripts mangle names, even from good AI models. Nothing here is edited in place. Every change goes through a ledger (a written record of each fix).
This stream had 1,223 transcript segments and 482 distinct proper nouns. Each one is listed with how often it appears, and each needs a decision: correct it, or confirm it as is. The ledger changed 9 segments.
A second check compares the transcript against every name I have ever published on the show, and flags near misses and known misspellings that survived. A validator agent compares corrected against raw, looking for dropped substance and changes that altered meaning. It gets three passes in total. After that the run stops and asks me, as an escape hatch.
The corrected file is stamped with its correction map, and later stages refuse any file without it, so the raw version can never flow downstream by accident.
STAGE 3 → Topics & chapters
A "topic" is a stretch of the show where I cover one subject, and it becomes a HH:MM:SS chapter in the shownotes. This is the hardest step to get right with AI.
A live show wanders: I read a post, riff on it for ten minutes, drift to something else, and come back later. A single model pass over 2.5 hours tends to lose the middle, and two readers rarely agree on exactly where a topic starts.
So five boundary-finder agents each read the whole transcript independently and propose where topics start. Code groups proposals that land within 17.5 seconds of each other, and a boundary needs 4 of the 5 to count. Three more calls then find where each chapter ends cleanly.
Agents can lie, so how do I know an agent read all 2.5 hours? The transcript goes to it as a file with unique markers woven through it, and it has to list the markers back in order. An agent that read the first page and the last cannot produce them. A response whose markers don't reconcile is thrown out.
Each answer comes back through a relay (a step that carries it from the agent to the files) that stamps a hash on it, and the collector rejects anything hand-placed or edited.
If one agent fails, it gets one retry on an identical prompt. If two fail, the run hard-stops. Two failing the same way means something is wrong, and re-running an unchanged prompt burns calls that cannot succeed.
Chapters are checked before the shownotes render: at least three, the first at zero, at least 10 seconds apart, and the last one starting past the 80 percent mark.
STAGE 4 → Find the clips
Three generator agents each read the whole show and propose clips. They quote the exact words where a moment starts and ends, and code finds the time in the word-level transcript. A quote that doesn't resolve is discarded with a reason.
Code merges the three lists. Two proposals count as the same moment only if they overlap in time and their titles share words.
Three scorer agents then rate each candidate high, medium, or drop and code settles it: "keep" versus "drop" is decided first, a tie goes to "keep", and the tier is the majority among the keeps.
A researcher agent looks up real X usernames and writes a grounded one-line summary for each clip. Another agent writes a summary of the whole show and a list of every brand and entity mentioned (web searching). One last agent checks any clip that only one run proposed, to see whether it cuts away just before its payoff (important for vibes).
On this stream: 27 candidates scored, 9 high, 17 medium, 1 dropped, 26 shown to me.
STAGE 5 → My gate (push notification)
This is the part I do (faster than reviewing with a human editor). The pool is grouped by tier, with timestamps, vote counts, entities with handles, and a summary for each clip. If the scorers dropped a clip that at least one run liked, it is shown too, so the disagreement is mine to settle.
I approve and the system tells me exactly which candidates I skipped, so I know what I left out. For YouTube I go through the stream in four equal quarters and pick from each. Easy peasy.
Then I see a dry run of the cut plan: how each clip will be treated, what will be removed, and a sample frame of the vertical crop. It states plainly what happens next: files cut, uploaded to my Drive, inserted as private YouTube videos, and an entry pushed to my site. My approval is tied to a hash of the exact approved clip list.
The cut, the Drive clip upload, the Drive shownotes upload, and the YouTube insert each re-hash that list when they run and refuse if it doesn't match. Change one clip after I approve and the approval is void. Re-rendering an approved clip keeps my approval, and changing the set of clips does not.
This stream: I approved 15 of the 26 and picked 5 for YouTube.
STAGE 6 → Cut, caption, publish (hard part)
Each approved clip is routed by length: Short (a vertical 9:16 version only, with burned-in captions, under 2mins), Clip (over 2mins a landscape master plus a captioned vertical), Highlight (5mins and up, a paced render, with dead air tightened and off-topic stretches in the middle removed).
Pacing is conservative. A gap in the transcript only proposes a cut, and the audio waveform can veto it. If there is audible sound in more than 5 percent of the gap, any brief loud sound, or the gap is shorter than 0.12 seconds, the pause stays. Removing off-topic speech is deliberate and produces its own list of every removal for me to review. Everything is loudness-normalized in two passes to -14 LUFS (a common streaming loudness level).
Captions run two to three words at a time with the active word highlighted, burned into the vertical version only. If captioning fails, the clip ships without them and the reason is recorded.
Four automatic check agents run on every cut before upload. One looks for words cut in half at the start or end, or a clip that opens on dead air. One measures audio levels, splices, and dead air. One reports what pacing removed and whether captions landed. One checks each file's audio timing. A clip that fails the first or last check is held back alone with its file kept, and the rest ship.
This stream: 15 approved clips became 16 files. 13 ran 2 minutes or longer, 1 was a short, and 1 ran just under 2 minutes. The short and the under-2-minute clip are the 2 captioned vertical versions, which is why 15 clips make 16 files.
Each file goes to Google Drive as an upsert (create, or replace the existing file), so a re-render replaces and never duplicates.
Before the shownotes page and the YouTube copy go out, the run looks up every username on X. This stream checked 27 handles. Each run adds to a ledger of known handles that is now over 300 (saves future work.
For the 5 YouTube picks, three writer agents each draft chapters from the clip's own transcript, code merges them and fixes the timing, and a fourth agent writes the title, description, and tags from a written style guide for my voice. I read the copy before anything is inserted. Everything goes in as a private video, and making one public is my step in YouTube Studio.
Last, the website entry. It is built from the checkpoint alone: runtime, a frame from the show, and the guest field from my first question. The site's own checks run, the entry is pushed, and the run waits until the page is confirmed live.
THE FINAL CHECK
Before the commit, an automatic text check runs over everything the run wrote. Then a fact reviewer agent re-fetches each claim in the shownotes from its source, not from memory. After a fix it gets two more tries, and a third failure holds the commit.
A publication audit then compares every link on the published page to what is live on Drive. For this stream: 0 problems across 16 published links and 16 live clips.
...AND IT'S DONE
I get another ping on my phone.
I have a Google Drive folder with all the clips ready to post, chapters and shownotes, transcript, my website is updated, the full recording is there, my website is updated, videos are ready to publish on my YouTube creator dashboard and I can go about my day.
CONSTANT EVALUATION
After each session, I have agents review the runs of previous streams to diagnose issues, harden the system and update dependancies or A/B different methods. I will soon be incorporating TypeSafe Jev for faster decision making on timestamped transcript work, possibly saving an hour of agent work and hundreds of thousands of expensive tokens.
That is what I mean by evaluation. Every stage has a check, and every check has a named reader: code that blocks the run, or me. In my design, a result that nobody acts on counts as a defect.
Each run also leaves the next one with more. The handle ledger, the names vocabulary, and the list of names I have published all carry over, and every run reads them before it starts.
THANKS FOR WATCHING
A few of you have said you want a system like this for your own work. I would build it the way I built mine: start from how you actually work, then check every step. That is why it has to be bespoke.
DM me here or reach me through my site : )
Below I'll attach the Google Drive folder with everything shown from the episode and more. A big shoutout to all my viewers and supporters, it's amazing what you can do with AI but the key is...
Know what problem you are trying to solve!
See the system in action below...
some great, measured analysis on Hedera recently from @CapeIslandDgtl and tbh it’s more in-depth than my own breakdowns
i encourage you follow & read !
$HBAR
Since 2021, Hedera's treasury has released ~28% of HBAR's supply for ecosystem development, nearly all of it to three foundations. In 2026 it sued two of them.
I went through the court filings, Council minutes and the ledger. Both sides quoted. Free:
crypto.capeislandpoint.com/h…
Brandon Davenport retweeted
wild stuff in @CantonNetwork telegram
Cantonite might become a thing 👀
GM canton-network:native
this was an important convo
THE INTERNET IS ON FIRE:
We're back for the HOL x AI at 12PM ET and covering all of the active security exploits hitting the internet because of AI.
Join us live. This is an episode you do not want to miss.
xitter.cf/i/broadcasts/1kKzDPREA…
Brandon Davenport retweeted
CEO of @Nasdaq
On their quarterly earnings call, @Nasdaq CEO Adena Friedman highlighted collateral mobility as a leading near-term opportunity for tokenization, citing a Canton proof of concept with Vanguard and Wellington that moved collateral between pools “instantly” and “perfectly.”
Tokenizing assets was the first step. Making them move is the real opportunity.
That’s the financial market utility Canton is built for.

























