anthropic on agent memory: the agent wrote a wrong location note, trusted it next session, and looped on a mountain
an offline 'dreaming' pass rechecked the note against the transcript and fixed it
would you let your agent rewrite its own long-term memory while idle?
hot take: most list endpoints don't need a total count
postgres keeps no cached row count, so a filtered COUNT(*) visits every matching row. on big tables it can cost more than the page itself
fetch limit+1 rows and return has_more instead
delete /items/123. first call 204. client retries, item's already gone. 204 again or 404?
i lean 204 so a flaky network doesn't turn a success into an error for the client. what's your default?
openai's agent pipeline found 948 working linux root exploits at roughly $1,279 each
finding bugs just got cheap. reviewing 948 patches didn't
kernel maintainers are about to have a very long inbox
pgbouncer in transaction mode quietly breaks anything that leans on session state. SET without LOCAL, session advisory locks, LISTEN, temp tables. prepared statements too unless you're on 1.21+ with max_prepared_statements set
which one got you first?
anthropic open sourced flashprove, zk proofs that a reply came from the model your provider claims. weights stay hidden.
catch: proving costs ~70 to 95x the gpu time of running it on vllm.
honest q: would you pay more per call to know your api isn't quietly swapping models?
celery on a redis broker, things that bite:
1. acks_late + non idempotent task = a worker crash runs it twice
2. acks_late task running past visibility_timeout (1h default) gets redelivered while still running
3. eta/countdown longer than that timeout gets redelivered too
hot take: the best part of openai's pando git writeup isn't the nearly 5x faster pushes
it's that they gave up repo-wide consistency. each branch updates on its own, so two branches can look out of sync
once agents push in parallel, the global lock is the first thing to go
Casually updating CRED and checked “What’s new” out of curiosity.
Expected bug fixes, got Alan Turing and a philosophy lesson instead. 💀😂
Bro, I just wanted to know what changed!
Whoever writes @CRED_club release notes deserves a raise. 😂
user requests /orders/123 but it belongs to someone else. do you return 403 or 404?
403 is more honest, 404 doesn't leak that the order exists. i lean 404 for anything with guessable ids. what's your default?
meituan's longcat-2.5 writeup has my favorite training detail: they wipe git history and cached files from the task repos so the model can't just dig the fix out of git log
honestly that's the first thing i'd try too
do your agent eval sandboxes strip that stuff?
classic django mistake: looping over orders and reading order.customer.name in the template. 1 query for the list, then 1 more for every row.
fix: select_related("customer") for foreign keys, prefetch_related("items") for reverse fks and many to many.
deepseek open sourced a research coding agent that watches a repo and team chat and takes work when someone allowed asks
best line in its docs: an agent acting for a whole team can waste a whole team's attention
so it only talks when someone must act. more agents need that
rate limiting a public api, token bucket or sliding window?
token bucket allows short bursts, which most clients actually need. sliding window log is stricter but stores every request timestamp in redis.
also curious what you key it on. api key, user id, or ip
computer use agents: screenshots and guessing pixels, or reading the os accessibility tree like vercel's new agent-desktop does?
stable refs and retry-safe clicks sound boring but that's what makes it usable in a real workflow
which one would you trust in prod?
every fastapi codebase has that one async def endpoint calling requests.get() and everyone wonders why p99 goes up when one upstream is slow. plain def would've been fine, fastapi runs it in a threadpool
mistral large 4 weights are finally out. 1T params, open, but even the nvfp4 build wants 4 gb300s and the api is $0.70 in, $2.10 out per M
honest question for builders: does open weights at this size change anything for you, or do you just call the api anyway?
redis caching stuff tutorials skip:
1. add jitter to TTLs so a batch of keys doesn't expire in the same second
2. on a miss let one request rebuild the key, the rest wait or serve stale
3. cache "not found" too, short TTL
4. pick an eviction policy, the default is noeviction
gemini 4 carbon's launch post says it makes about half as many unsupported claims as argon and asks before guessing.
honestly that's the spec i care about. i can retry a timeout. i can't retry a confident wrong answer that already hit prod