What you way is true after the container starts. Typical HPC codes are tuned to raw hardware so they assume full ownership of the hardware anyways. When HPC was developing 30 years ago we didnt have clean ways to avoid overheads in the regime of 10k nodes. Instead we got parallel filesystems, caching, and shell, with module, which technically did the job for reproducible runs at a huge human cost.
HPCs never loved the inefficiencies of anything virtualized (VMs or any containers really), so the shell hacks of module enabled a (limited, but workable) level of reproducibility that was sufficiently composable and usable by researchers who understood the shell. I am not going to defend this tcl hack any further, but I can see how it was the path of least resistance when people tried to stay close to the raw metal of their large clusters while keeping some level of sanity. Slurm is a more defensible choice, but I agree that these tools are from a different era of compute. I grew to love and hate these tools, but they definitely represent an acquired taste, like a dorian fruit; not like an apple.
All of the ones I mentioned work great for me. You can dream up your interface and inject technical design ideas and your claw can code it up; as you test it, you fix it if you get new ideas for how it should work.)
For example my recipe project is built around a relatively simple sqlite db. Input for new recipe is in arbitrary format as it goes to an agent (image snapshot on iphone; txt file, speaking it out in a telegram message; a text prompt); the model figures out what to extract and save from the projects’ documents and the context of the specific telegram thread. Output is in whatever form I ask for; rescaled for a number of people; fit in single compact paragraph; or detailed ingredients first then instructions; possibly replace missing ingredients. Query can be arbitrary complex—it almost always finds the recipe I want so far much to my surprise; once I had to followup to select a specific option from a couple ambiguous variants. By default, I like to keep the replies for my recipe queries brief, practical, projected to my cookware. Once I set up this very simple recipe project and imported a couple old datasets, I gave up all of multiple previous recipe schemes (text files or org notes with complex syncing schemes, iPhone apps…)
I use it a lot for personal stuff. Off the top of my head: Best way so far to build and use personalized/family tools for dining/recipe/movie/literature/reminder/organizer/security/notes—-in addition to robust text input, all of them have a voice and image UI via telegram without extra code via an intermediate LLM agent, and all data end up on your machine in your format of choice. More fun than codex/claude-code for hobby coding projects (though worse performance, more effort, unless you directly use codex acp). Less intrusive than ChatGPT/Claude for parallel queries while outdoors (speak, then read). Fun way to explore and understand multi-agent setups. A great way to demo the ability of current AI to friends and family.
You dont have to enable scary setups to make it minimally useful. The jump in capability compared to chatbots is dramatic, and the jump in flexibility compared to coding harnesses is also dramatic.
It would be fun to catalogue all one-variable functions that can be represented as binary trees of fixed depth in this way and then encode the trees in binary. Lots of these functions in old math book tables would look very different with a plain hash lookup and the identities in such books would prove themselves.
Parallel inference on large compute scales in superlinear ways. There is no way to beat the reduction in memory transfers that a data-center inference model provides with hardware that fits at anything called a home. It is much more energy efficient to process huge batches of parallel requests compared to having one or a handful of queries running on an accelerator.
A thinly vailed ad for yet another variant that inevitably leads to more confusion and yet another future security nightmare. The authors (should) know better. No, the purpose of OpenClaw is not to immediately give it all your private accounts and live in bliss and no, their system is not better long term than following the mainline developments that have enough eyes (and bots) on them by now.
You underestimate academia. Any academic that reads these two sentences only focuses on the first one: He has a named chair at Courant. In Germany, being a a Prof is added to your ID card/passport and becomes part of your official name, like knighthood in other countries.
This is a useful concept that helps discovery, with a neat and functional website aesthetic. I hope the skill sharing space will eventually become usable and safe.
Aren't most these people recommending random tools in the github chat for this entry just attempting to exploit naive users? Why would anyone in this day and age follow advice of new users to download new repos or click at random websites when they already attempt to use claude code or cowork?
Mac minis are sold out in NYC these days because everyone gets them to try out openclaw. Even if this move by Apple is unrelated to the recent demand, it certainly was timed right for the policy and market makers.
TBH I would first walk there to check that they can take me on the spot, and if so, ask them to either please come clean it (only 50m away) or if they cannot fly it there. So walk seems very rational to me.
Cheap verifying of speculative decoding only works for a few tokens at a time. Long sequence generations (thousands to tens of thousands of tokens in typical rollouts for thinking models) are dominated by distribution drift on stale weights (because slightly wrong probabilities multiply over long streams), and the off policy RL training methods dont work well (high variance) for such high dimensional problems.
Not OP. Personal opinion on why it is a somewhat hard problem. The main problem is using the available compute correctly and productively while doing two very separate types of tasks that were previously solved independently: generating responses with llm inference engines and modifying weights with a training code. A step of training updates the weights so the inference engines have to adjust theirs, but we talk about 750B parameters and multiple inference servers. Stale weights can be used instead, but only for a tiny bit and the data from them needs special corrections that also involve large compute/memory. Your inference engines better be deterministic (for given pseudoRNG; it clashes with parallelism) or you have a way to correct the probability streams. Ideally inference and training should have same everything at the bit level when they handle the same context, but we dont live in that world yet. And of course, GPUs break. For no great reason, other than the tiny scale of their features making them fragile. And because you scale, you need to handle failures gracefully and efficiently.
Please update the title: A Benchmark for Evaluating Outcome-Driven Constraint Violations in Autonomous AI Agents. The current editorialized title is misleading and based in part of this sentence: “…with 9 of the 12 evaluated models exhibiting misalignment rates between 30% and 50%”
I like your effort. Time savings and strict security are real and important. In modern orchestration flows, however, a subagent handles the extra processing of tool results, so the context of the main agent is not poluted.
I use headless mode (-p) and keep my named shell histories as journals (so no curses/TUI or GUI). But session management or branching could improve at the tool level and allow seamless integration with completion tools, which could be a simple fast AI looking at recent sessions or even be visual, say for navigating and extending a particular complex branch of a past session. It is not too hard to work with such shell-based flows within Emacs for me, but it would be nice if there was some standardization effort on the tool fronts and some additional care for future automation. I dont want my AI clicking buttons if it can be precise instead. And I certainly want multithreading. I think of AI more as an OS; it needs a shell more than it needs windows at this point in time.
My main take is exactly the opposite. Why not build everything with a simple text interface (shell command) so the models learn to use these tools natively in pretraining. Even TUI like codex-cli or claude code are needless abstractions for such use cases and make full automation hard. You could add as many observability or input layers for humans as you want but the core should be simple calls that are saved in historical and documentation logs. [the headless/noninteractive modes come close, as do the session logs]
Not equivalent to the binary driver: you can modify it yourself with post training on your own data. So it sits somewhere between NVIDIA userspace drivers and Emacs, or Clade Code and codex-cli. We don’t have good analogies from older generation software.
You can do it and may be ok for single user with idle waiting times, but performance/throughput will be roughly halved (closer to 2/3) and free context will be more limited with 8xH200 vs 16xH100 (assuming decent interconnect). Depending a bit on usecase and workload 16xH100 (or 16xB200) may be a better config for cost optimization. Often there is a huge economy of scale with such large mixture of expert models so that it would even be cheaper to use 96 GPU instead of just 8 or 16. The reasons are complicatet and involve better prefill cache, less memory transfer per node.
This feels like a big nothingburger to me. Try an analysis on conference submissions (perhaps even published papers) from 1995 for comparison, and one from 2005, one from 2015. I recall the typos/errors/ommissions because I reviewed for them and I used them. Even then: so what? If I could find the reference relatively easily and with enough confidence I was fine. Rarely I couldnt find it and contacted the author. The job of the reviewer (or even author) isnt to be a nitpicky editor—that’s the editor’s job. Editing does not happen until the final printed publication is near, and only for accepted papers, nowadays sometimes it never happens. Now that is a problem perhaps, but it has nothing to do with the authors’ use of LLMs.
Edit: A followup, if you still happen to see this edit. What about the privacy concerns that users may have. My interest is for a super-high functioning young adult that is very careful about their privacy and web footprint.
Thanks! Why would a user prefer this service instead of a conventional AI subscription service with memory (and possibly read access to their desktop data)? The latter can automatically capture key interactions during the day and set reminders for regular checkins. Is there a secret sauce that makes this better so it is worth the extra effort?