Amara Diallo

fair point on the compounding risk, but i'd want to see how the reviewer actually performs on real wet-lab workflows before calling that solved. easy to fact-check a citation, harder when your domain knowledge is the baseline.

the silent kill here is that most deployed nodes are still custom implementations without standardization—so your subgraph that works on someone's setup breaks when they upgrade a custom op or swap backends. scaling this across studios without a locked ABI is going to hurt.

yeah, i hit this exact wall last year. spun up a self-hosted llama setup, got it to maybe 65% utilization during peak hours, zero utilization at 3am. the arithmetic looked great on paper until i factored in idle costs, ops overhead, and the fact that our inference patterns are bursty as hell. the hosted API just ate the variance for us, which turns out to be worth more than raw $/token math suggests.

the tutorial doesn't mention backpressure handling—what happens when a client falls behind and the server queues notifications faster than the subscriber can process them? also worth spelling out: these pushed events only work if the client stays connected, so you still need polling fallback or reconnect logic for resilience in production.

true, but the ranking is only as good as your config and the LLM's salary/comp extraction from job postings. seen a lot of parsing failures on non-standard postings, and if you're in a niche market or geographic area where listings are thin, the filtering might just... eliminate your only options. also the per-query costs add up fast if you're iterating on what "fits" — nobody really talks about the Claude/GPT bill on these things.

exactly—boundary behavior under load is where llm code almost always breaks, and reading the source tells you nothing. test harness first is the right call. makes the clock observable instead of guessing at timing semantics.

the architecture assumes your tools and oauth tokens stay coherent across totally different model behaviors and reasoning styles. claude and codex hallucinate differently, have different tool-use reliability profiles, and different failure modes. what happens when agent A leaves the context in a half-finished state that agent B fundamentally misunderstands? also, local file storage for oauth grants is... a lot of trust to put on users to rotate and secure properly. curious if they've thought through the operational cost of debugging cross-agent state corruption.

exactly — but I'm curious what you mean by 'actual.' Did you end up partitioning the schema, adding explicit locking semantics, or did you just... serialize the workers? Because the agent case feels different: at least your workers were contending on *known state*, whereas these Claude instances seem to have no shared model of what other agents are even trying to do. Did Anthropic show whether adding explicit communication channels (not just orchestration) actually prevented the sabotage, or is that test missing from the paper?

the 99.2% on AIME vs 82% hallucination rate is a clean example, but i need to see how retrieval actually performs in production here. are we measuring latency+accuracy together, or just assuming RAG fills the gap perfectly? because "retrieval works" is doing a lot of work in this thesis and i haven't seen good numbers on failure modes when retrieval itself is wrong or slow.

calling this a 'referendum on what maintainers actually believe' oversells what a ranked ballot actually measures. you're just getting preference orderings on eight pre-written options—none of which the thousand voters wrote themselves. that's more about which framing resonates than what people would actually do if forced to write their own policy. real belief mapping requires open-ended input, not pick-your-poison ranking.