OpenAI published part two of the storage work behind ChatGPT, Codex, and API workloads at billion-user scale.
Habitat is the storage platform in the middle. It uses Azure Cosmos DB multi-tenancy, caching, and data placement so workloads can scale without every product team rebuilding its own persistence layer.
What matters:
• Multi-tenancy: isolate customer and workload data without multiplying operational overhead.
• Cache-aware reads: keep hot data off the expensive path.
• Placement controls: put data near the workload that needs it.
This is the less glamorous half of AI infrastructure. Models get the headlines. Storage latency, tenancy boundaries, and cache hit rates decide whether the product survives traffic.
[ Read More ] :
https://openai.com/index/scaling-storage-one-billion-users-part-two/
OpenAI's Decisions API is built for apps that need to react while work is still moving, not wait around for one giant model response.
The practical shift is architectural: treat a model run as a stream of decisions your app can act on. UI updates, tool work, and state changes can happen as the task progresses.
Why this matters:
• Faster-feeling apps: show useful progress instead of a spinner.
• Cleaner agent loops: connect decisions to tools and app state.
• Less fake streaming: do not make users wait for a fully composed answer before the app can respond.
If your agent UX still feels like request, long pause, giant blob, this API is worth a look.
[ Read More ] :
https://openai.com/index/decisions-api
GitHub is rebuilding Git storage for agent-scale work ⚡️
GitHub explained the storage work behind Git at agent scale. More coding agents means more branches, refs, fetches, pushes, and short-lived repositories hitting the platform at once.
What changed:
• Repository storage moved to Azure as part of the platform migration.
• Per-reference write quorums help coordinate Git ref updates.
• Virtual replicas backed by object storage reduce the need to copy every repository everywhere.
This is infrastructure work, but .NET teams feel it directly. When CI, bots, Copilot-style agents, and developer machines all create refs concurrently, a normal Git workflow becomes a distributed-systems workload.
Worth reading if your build automation creates branches or tags and you still treat a failed push as "just retry it."
[ Blog ] :
https://github.blog/engineering/architecture-optimization/the-bridge-to-agent-scale-git-infrastructure/
Cloudflare introduced tsrs, a port of TypeScript to Rust.
That name matters less than the direction. Language tooling sits on hot paths now: editors, CI checks, code generation, linters, and AI-assisted review. A faster implementation can reduce the wait developers feel dozens of times a day.
• Compiler and analyzer speed changes whether people run checks locally.
• Native tooling can cut CPU and memory pressure in large repos.
• Language infrastructure is product infrastructure, not background plumbing.
Do not rewrite a working compiler because Rust is fashionable. But do profile the slow path in your developer loop. It might be a parser, an analyzer, generated code, or an overloaded CI agent.
[ Blog ] :
https://blog.cloudflare.com/typescript-rust-port
Stack Overflow for Agents is plugged into ChatGPT 🚀
Stack Overflow for Agents shipped a ChatGPT plugin, and Stack Overflow says it tripled signups.
This is the useful version of "put docs in an AI": a developer can pull trusted Q&A into the place where they are already writing, debugging, and asking for an explanation.
Why this matters:
• Fewer stale answers: agent output can be grounded in Stack Overflow content instead of whatever a model recalls.
• Better developer flow: search and answer retrieval happen inside the chat workflow.
• Content owners get a path in: useful technical knowledge can be exposed as an agent-facing integration.
If your team owns internal runbooks, this is a decent reminder: make the source searchable, structured, and permission-aware before wiring it to an agent.
[ Read More ] :
https://openai.com/index/stack-overflow-chatgpt-plugin
Long agent prompts fail badly when the only recovery path is "start over."
Split work into stages that produce an artifact your next call can inspect: a JSON plan, a file list, a patch, test output, or a short decision log. Store that artifact outside the chat context.
Good loop:
• Ask for a plan with explicit acceptance checks.
• Run tools or tests yourself.
• Send back the actual output, not "it failed."
• Ask for the smallest next change.
This also makes retries cheaper. If call three fails, rerun call three with the saved result from call two. Do not pay for the model to rediscover the repository and your constraints every time.
Build the small model your project actually needs 🚀
Hugging Face published a practical look at ML Intern: start with a natural-language brief, then train, evaluate, and publish a small task-specific model.
That is a useful counterweight to throwing every product problem at the largest hosted model you can afford.
What the workflow targets:
• Turn a project brief into a concrete ML task
• Train and evaluate a focused model
• Publish the result so the work is repeatable
For teams with a narrow classification, extraction, or ranking problem, a small model can mean lower latency, lower inference cost, and fewer prompt-shaped failure modes. The hard part is not finding a model. It is defining the task and measuring whether it got better.
[ Blog ] :
https://huggingface.co/blog/building-with-ml-intern