Now we just need the RAM market to get back to normal. Or at least fine OpenAI for speculating on raw wafers. There's an article on the front page [0] with this passage that gives me hope that consumer access to VRAM may improve
> On the infrastructure side: OpenAI signed non-binding letters of intent with Samsung and SK Hynix for up to 900,000 DRAM wafers per month, roughly 40% of global output. These were of course non-binding. Micron, reading the demand signal, shut down its 29-year-old Crucial consumer memory brand to redirect all capacity toward AI customers. Then Stargate Texas was cancelled, OpenAI and Oracle couldn’t agree terms, and the demand that had justified Micron’s entire strategic pivot simply vanished. Micron’s stock crashed.
That's what LLMs are best, actually. Go through all your stuff and painstakingly document, add tags, refer to other documents, etc
> Due to this, my Obsidian vault is pretty much a collection of a bunch of temporary to-do lists and then some folders with specific reference information
LLMs can also separate what information was only useful at a specific time vs more perennially useful notes.
Isn't the "gardening" aspect part of it though? It's where you naturally review and mentally correlate topics, infer connections in your brain and spark new paths?
This is true. It would be beneficial to do such a task
However, if one doesn't want (or just doesn't have time) to do the task but still want a tidy cross-referenced set of notes, one could outsource to a LLM
Yeah, the problem with AI is that they can become too good at performing general tasks, ranging from, like, designing cancer treatments, or designing bioweapons, and everything in between
yeah ruby API ideas and the _why poignant guide specifically, they were very influential in programming in general. a number of early rust devs came from ruby as well. all original authors of cargo worked on ruby's bundler earlier. etc
> These guides are up to date with Bevy version 0.18
This is huge, thanks. Unfortunately many Bevy resources became stale (the Bevy cookbook was even abandoned, there was little interest in keeping it up to date and so there were many sections for, say, Bevy 0.12)
Both will either download or ship the postgres binary with your app, and run it in a separate process. Pglite is different, it's actually a library (they have stripped some parts of the postgres source code) and it could in principle be ported to be used as a native library (meaning, you link to it and run as a single program)
There's even a draft PR to do this, but it became stale
Yes, what you get is a multi-server postgres under the covers. But for many users, the convenience of "uv pip install...", auto clean up via context manager is the higher order bit that takes them to SQLite.
Of course the bundled extensions are the key differentiator.
With enough distribution and market opportunities we (yes, there is a for profit company behind it) can invest in making it truly embedded.
frick this gotta be the tenth time ive read about pglite here and i always go look for native library. shame pr became stale, webapps simply arent always my end game. thanks for putting pglite-oxide on my radar tho, this is an interesting almost-there i can tinker with.
> Context Bloat: Using a skill often requires loading the entire SKILL.md into the LLM’s context window, rather than just exposing the single tool signature it needs. It’s like forcing someone to read the entire car’s owner’s manual when all they want to do is call car.turn_on().
MCP has severe context bloat just by starting a thread. If harnesses were smart enough to, during install time, summarize the tools provided by a MCP server (rather than dumping the whole thing in context), it would be better. But a worse problem is that the output of MCP goes straight into the context of the agent, rather than being piped somewhere else
A solution is to have the agent run a cli tool to access mcp services. That way the agent can filter the output with jq, store it in a file for analysis later, etc
I use this pattern with mcp-cli, and I do that instead of a curl request for two reasons: 1) not leaking my creds into the agent session, and 2) so I can allowlist / denylist specific tools on an MCP server, which I can't do as easily if I give the agent an API token and curl.
> MCP has severe context bloat just by starting a thread
Hi, author here. The “MCP has severe context bloat” problem has already been solved with tool discovery. Modern harnesses don’t load every single tool + their descriptions into the context on load, but use tool search to discover the tools lazily when they’re needed. You can further limit this by telling the LLM exactly which tool to load, the rest will stay unloaded / invisible
> But a worse problem is that the output of MCP goes straight into the context of the agent, rather than being piped somewhere else
This is semi-solved as agents and harnesses get smarter. Claude Code for example does discovery in subagents. So it spawns a sub-agent with a cheaper model that explores your codebase / environment (also through MCP) and provides a summary to the parent process. So the parent won’t get hit with the raw output log
> Claude Code for example does discovery in subagents.
but this still burns tokens needlessly in the subagent. if the agent could filter the mcp output using a cli (often jq, but sometimes something else), it could be more economical
maybe anthropic wants you to burn those tokens though
At least when working with local MCP servers I solved this problem by wrapping the mcp tools inside an in-memory cache/store. Each tool output gets stored under a unique id and the id is returned with the tool output. The agent can then invoke other tools by passing the id instead of generating all the input. Adding attribute access made this pretty powerful (e.g. pass content under tool_return_xyz.some.data to tool A as parameter b). This saves token costs and is a lot faster. Granted, it only works for passing values between tools but I could imagine an additional tool to pipe stuff into the storage layer would solve this.
> On the infrastructure side: OpenAI signed non-binding letters of intent with Samsung and SK Hynix for up to 900,000 DRAM wafers per month, roughly 40% of global output. These were of course non-binding. Micron, reading the demand signal, shut down its 29-year-old Crucial consumer memory brand to redirect all capacity toward AI customers. Then Stargate Texas was cancelled, OpenAI and Oracle couldn’t agree terms, and the demand that had justified Micron’s entire strategic pivot simply vanished. Micron’s stock crashed.
[0] https://adlrocha.substack.com/p/adlrocha-how-the-ai-loser-ma...
reply