vibe42

This is awesome! Thank you for building this.

I could find 3I/ATLAS using the search box for "ATLAS".

Would it be possible to also have the search for "interstellar" list objects classified as interstellar object?

"Almost every model finds the same winning ideas. What separates the best traces is what an experiment leaves behind. They preserve weak signals long enough to validate them, but they also have a better understanding of the results."

Curious if a harness that helped preserve signals in some history log would change the outcome.

Also curious if different goal prompts would have changed the outcome. Not a bunch of prompt engineering; small diffs like "consider novel solutions, keep track of weak signals".

IMO they allocated quite a bit of GPU time to the same goal prompt.

Meta released their own 4-bit quant of this model for devices with 24GB VRAM.

That's a modern gaming laptop; cheapest I see in the US with 24GB is $3.5k.

Should be quite a bit faster than the new M5 MacBook Pro, and you can run Linux on it!

I'm using the pi-mono coding agent (open source, free) without any extensions and very simple prompts. The 3.6 27B model (BF16, 250k context) uses 67GB VRAM on an RTX PRO 9000.

It's very capable on almost any coding task I've thrown at it, and very good for easy-to-medium hard scripts, new code bases.

It struggles on some complex tasks in larger code bases, e.g. using to debug and fix bugs in llama.cpp it gets close to working code but often introduces errors. For such tasks its still very useful as a search/explore tool and drafting fixes.

It can indeed cause some models to try too hard to come up stuff, but the next verification prompt does counteract it.

E.g. some findings first classified as moderate priority often get reclassified as low priority even if the finding itself is correct.

The exact phrasing doesn't seem to matter as much as keeping the prompts short, simple and to the point.

However some models seem to do a bit better when adding ", if any" to prompts such as "List potential improvements".

Something I've had good progress with using local models and simple open-source harnesses is to repeat, in a new context, simple verification prompts.

I'd run the following 5-10 times with one model, then again with a 2nd model.

"Verify the correctness and completeness of all security configs/rules in SETUP.md. Consider if anything is missing, and if anything is not needed. Do not modify any files; only write potential findings to report.txt"

"Verify all findings and claims in report.txt."

Replace "SETUP.md" with whatever you're working on.

It's both terrifying and incredible watching what the models get correct and what they get completely wrong.

However, after enough runs they tend to settle on a state they claim does not need any more edits. And that result is generally useful with much fewer errors/hallucinations compared to a single run.

Many crypto wallets use a key derivation function (KDF) to add an amount of computation (and memory usage) per password tried - to mitigate brute force of weak passwords.

The increase in compute (decrease in brute-force cost) combined with price increases in many crypto tokens means brute-forcing old wallets can become worth it years after passwords were forgotten.

And of course even smaller, local AI models can now easily write optimized scripts to brute-force any given KDF function.

I run both MoE and dense models on laptops.

One set of models run on 8GB VRAM / 16GB RAM and another set runs on 24GB VRAM / 64GB RAM. Both are very useful for easy and easy-to-moderate complex code, respectively.

The latest open, small models are incredibly useful even at smaller sizes when configured properly (quant size, sampling params, careful use of context etc).

Outside Trading.

This. And when possible, first asking the AI to add more granular logging around the code where the problem is - then re-run the code and feed the new log in a new context.

I've used this to debug some moderately complex bugs in golang and godot code and it works really well - the combo of having a new context with the (sometimes overly) granular debug logging and only the required, specific source code.

Keep it simple and run a fresh, new context for each prompt.

I use the pi-mono coding agent with several different new open models running locally.

The simpler and more precise the prompt the better it works. Some examples:

"Review all golang code files in this folder. Look for refactor opportunities that make the code simpler, shorter, easier to understand and easier to maintain, while not changing the logic, correctness or functionality of the code. Do not modify any code; only describe potential refactor changes."

After it lists a bunch of potential changes, it's then enough to write "Implement finding 4. XYZ" and sometimes add "Do not make any other changes" to keep the resulting agent actions focused.

With the pi-mono coding agent (running local, open models) this works very well:

"Do not modify any code; only describe potential changes."

I often add it to the end when prompting to e.g. review code for potential optimizations or refactor changes.