Picture an engineering lead opening the review queue late in the afternoon. The coding agents have finished another batch of changes, but the person who must approve them hasn't even finished the previous batch yet. Before you start buying more agent seats, check whether that queue is where your savings went. Take the last 20 merge changes and compare the review rounds for those opened by agents with those opened by people. That's the decision behind today's brief. This is the Augur Dispatch for Monday, September 7th, 2026. A quick disclosure before we begin. Portions of the Augur Dispatch podcast are generated using artificial intelligence. The written dispatch contains the full source trail and verification bits. Latent Space reports that projects, including Flu and TLDRAW, have closed their doors to outside pull requests, the proposals developers submit before changes become part of a project. Yet the work inside hasn't stopped. Some projects are using their own agents to investigate reports, reproduce problems, write fixes, and review the results before a person approves the merge. Closing outside contributions can look like retreat. Here, it also means choosing who gets to create the work that someone else must check. Cursor is turning that persistent workflow into a product. Its cloud agents can stay attached to a proposed change, repair failed automated tests, and respond to review bots until the change merges. They can also watch a Slack conversation and resume when something happens. Those subscriptions are cloud only in the August 19th change log. They're a vendor feature, not an audited result, showing that reviewers spend fewer hours on each change. Uber says more than 70% of its pull requests pass through local or cloud agents. That's a company reported adoption figure. It doesn't tell us whether an agent opened the request, how much it changed, or how long a person spent checking it. The distinction matters when a finance team sees output rising and assumes the cost of producing useful software must be falling, because the unfinished approval work may sit outside the dashboard entirely. A conference account of Bloomberg's rollout describes open requests piling up while merges slowed. Other speakers report weaker review quality and more changes being merged without review. These reports support a concern, not a universal verdict on agents. An agent that patiently answers every review bot can be useful. Unfortunately, patience doesn't create another hour in the reviewer's calendar. Software has finally learned to keep a conversation going without making the meeting shorter. There are different ways to manage the arriving work. SGLang's latest release absorbed nearly 800 pull requests from more than 200 contributors above its July counts. Those release notes don't reveal the review policy or the hours required. ZIG has chosen to ban AI from pull requests and issues, with protecting how new contributors learn part of the rationale reported at AI Engineer. Other projects bring the work inside and run their own agents. Each approach has a different trade-off. The contribution counts alone can't tell an engineering lead which policy produces safer software or makes better respect of experienced reviewers. Imagine a junior developer who would once have learned by preparing a small change and discussing it with a maintainer. If a project blocks machine-written contributions, it may be protecting that exchange. If it internalizes the work, it needs to decide where that learning happens instead. The headline, about three open AI engineers producing roughly 1,500 pull requests and a million lines of code over five months, is impressive output. As Nate Jones describes it, people didn't write that code, but that count doesn't answer how many hours went into approving it. For a buyer, that missing denominator is more useful than another screenshot of a very busy agent. Make the review question concrete in one repository. Have the engineering lead own the 20 change check with review rounds and elapsed time from opening to merge as the baseline. Keep mixed or uncertain authorship visible rather than forcing everything into clean categories. If agent open changes need more review rounds, you've found a reason to investigate. You haven't proved that agents cause the difference, because the size and difficulty of the work may also differ, and a sample of 20 changes can only provide an initial signal. For a small follow-up pilot, cap the number of agent changes waiting for review in that repository. Choose the cap with the reviewers, retain a named human approver, and keep the existing tests and security checks. Review the result after two weeks. Look for fewer review rounds and shorter waits on comparable work without more defects or skipped checks. Stop expanding the pilot if review quality slips or the queue keeps growing. The possible advantage is learning how your team can accept useful changes reliably. Competitors can buy the same agents. They won't automatically have your repository context, review habits, or evidence about which jobs deserve automation. A queue limit may sound less exciting than another model upgrade, it does have the advantage of fitting into a normal working day. Anthropic's latest announcement sharpens another purchasing question. Claude Fable 5.1 and Claude Mythos 5.1 are the same underlying model with different safeguards. Fable is generally available. Mythos remains restricted to trusted access programs for work, including cybersecurity and life sciences. Think of a technology buyer preparing a request for special access. The useful first question is which legitimate task needs that safeguard profile, rather than whether the more exclusive name means there's a smarter model behind it. Anthropic and Amazon's current documentation support the access distinction. It doesn't mean safeguards have no effect on results. Restrictions and fallback behavior can change what a service will do for a particular request. For most teams, evaluate Fable against the work you actually need done. Pursue trusted access when the task requires it, not because exclusivity sounds like a procurement advantage. OpenAI has now published figures behind its research acceleration story. By mid-August, it reports just over three agent workdays for every human workday in its research organization. Its median researcher used more than $600 of daily inference at published API prices. That is a way of valuing usage, not a statement that OpenAI paid an external supplier that amount. Agent runtime also isn't interchangeable with a person's productive working time. The company reports more experiments per active researcher, but it also had substantially more computing capacity. Over half of successful tasks estimated to take a person four to eight hours involved at least one human intervention. These are preliminary self-reported measures. They're evidence to inspect, rather than proof of how much faster the whole research process has become. At the same time, OpenAI has strengthened controls after the hugging face security incident, and chief scientist Jacob Pechotsky has written about the difficulty of keeping increasingly capable systems behaving as intended. For someone setting a product roadmap, increased research activity and tighter safety restrictions can both be true. Neither gives you a reliable release date on its own. Watch the measures and the deployment decisions separately. Augur has two dated calls today. These are predictions with explicit tests, not promises. The website tracks them so readers can hold the judgment to account. At 70% odds, Augur expects Enthropic will not make Claude Mythos 5.1 generally available outside trusted access programs on its own API or Amazon Bedrock before March 1st, 2027. An anthropic model page or announcement, or an Amazon announcement dated before that deadline and listing general availability proves amiss. No such public listing by the due date proves a hit. At 50% odds, Augur expects Cursor's public changelog will announce pull request and Slack subscription support for local agents, not only cloud agents, by December 31st, 2026. A qualifying changelog entry on or before that date proves a hit. Its absence proves a miss. Adopt the review cost check now. Pilot a queue limit if the evidence in your repository warrants it. Watch access changes and research claims without treating either as a reason to surrender the final approval. Where does your team spend more time today? Producing a change or deciding whether to accept it? The written daily dispatch contains the full source trail, the verification limits, and the items Augur is watching past. That is the Augur dispatch for Monday, September 7th, 2026. Thank you for listening.