andyk

> bingeineering

i'm gonna start using this

because it seems like the human mind does this and it was easy to start with. The human mind obviously also compresses by other dimensions so we'll keep experimenting

suggestions for what to try next?

fair point. the headlong agent running on my mac mini, cleo, doesn't pause between calls to "generate next thought". for a while the implementation didn't support pausing between thoughts. a `thinker`, which is where the thinking loop lives, only had a boolean variable `self_trigger`, which caused it to recursively fire itself to run again (ie immediate generate the next thought). We added the ability for it to slow down its thinking and prep for sharing it with the world since it makes it easier to leave it running and not have it spend a few hundred dollars a day and you can still observe the same mechanism, which is the heart of what we want to get at here:

I don't think the blog post fully conveys this, but for me it's not whether there's a pause between thought generations, but instead whether the agent is designed to stop after some human-set goal is achieved to wait for more instructions

In contrast the idea here was to force the agent to pick its own next goal (even when it receives no explicit tasks from a human) -- even if that goal is implicit -- and then watch and see what it picks (or at least what it does with its time). and then figure out what sort of mechanisms we can introduce to the architecture at that outermost life/goal picking loop

Should maybe have said more loudly in the posts that this is not intended to be disciplined engineering (or used in prod!) we did think about the architecture quite a bit and we've tried a bunch of different things out. We are fully optimizing for velocity of research experimentation and iterations on the design vs engineering hygiene

i've been playing with the project and idea for years now. the codebase started as javascript plus supabase before reasoning models were a thing (i incorrectly predicted the world would call reasoning models Large Thinking Models - bahaha). at one point the focus was almost entirely on a really easy-to-use human prosemirror UI for editing the agent's thought stream--because the models were still so bad at reasoning at that time.

then we pivoted to all bash at some point since it simplified things and i have this hypothesis that the LLMs will do better if as much of its world as possible is command line operations (inspired by terminus the agent we built as part of the terminal bench project)

the bash implementation is entirely written by coding agents - the human time goes into iterating with an AI agent on the design docs in the ./design folder

re security model - i think of the project as a research experiment about what it's like to treat an agent more like a person - so for secrets you have to trust its judgement about what it will share or if it will betray your trust. I don't know the OpenClaw architecture in great depth but my sense is that none of the LLM based agents that can interact with multiple people have strong guards in place that prevent the agent from leaking secrets between people. Definitely an interesting area for research though!

so yeah security is not a priority in this research per se - easier to assume you don't share sensitive things with a headlong agent

Along those lines, because we keeping it research and optimizing the velocity with which we can try new things out, the current aim isn't necessarily to get a bunch of community contributions. but if we do start to get any i'm thinking we will actually require people to only create PRs with design docs (no code allowed) and maybe even also require the logs (or at least the human prompts and the agent's responses) from the coding session where they created the design doc.

maybe i should write up the history, philosophy, and big picture aims of the project at some point

andy here (headlong post author). terminal bench 3 is pretty popular for comparing different harnesses using the same underlying model (it's another laude project actually). artificial analysis has an index. you can look at the model cards of popular model releases- they tend to have the most popular current benchmarks on them. w/ headlong we decided to announce it before we've benchmarked it. we mostly wanted to informally share our experiences w/ it in this initial post. we plan to do some benchmarking coming up here soon tho

andy here - happy to answer questions

I hope the competition will inspire people to make breakthroughs in the open, so I won't take any rights to the IP, instead the winning solutions must use open source code and open weight models.

yes the prize money is from me to the winners

That has a double meaning - half tongue in cheek.

1) since we are creating a contamination-free version of SWE-bench (i.e. scraping a new test set after submissions are frozen) it is guaranteed that agents in this contest can't "cheat", i.e., models can't have trained on the benchmark / agents cant memorize answers.

2) as a general rule in life, don't cheat on things (not that there aren't exceptions)

(reposting from locallama and lower down here) yep that's true.

one of my goals is to inspire and honor those that work on open source AI. Those people tend to be motivated by things like impact and the excitement of being part of something big. i know that's how i always feel when i'm around Berkeley and get to meet or work with OG BSD hackers or the people who helped invent core internet protocols.

those people are doing this kind of OSS work and sharing it with the world anyway, without any cash prize. i think of this as a sort of thank you gift for them. and also a way to maybe convince a few people to explore that path who might not have otherwise.

andy here - happy to answer questions.

Also, I answered a bunch of questions yesterday on LocalLLaMA that people here might find interesting https://www.reddit.com/r/LocalLLaMA/comments/1hdfng5/ill_giv...

yeah i agree. one of my goals is to inspire and honor those that work on open source AI.

people who work on open source tend to be motivated by things like impact and the excitement of being part of something bigger than themselves - at least that's how i always feel when i'm around Berkeley and get to meet or work with OG BSD hackers and people who helped invent core internet protocols or the guys who invented RISC or more recently RISC-V

those people are going to do this kind of OSS work and share it with the world anyway, without any cash prize. i think of this as a sort of thank you gift for them. and also a way to maybe convince a few people to explore that path who might not have otherwise.

I tweeted this on stage at NeurIPS on weds: "I'll give $1M to the first open source AI that gets 90% on this sweet new contamination-free version of SWE-bench - http://kprize.ai" - K Prize is a new kaggle competition

done! in the "Alternatives and related projects" section I just added to the ht readme -- https://github.com/andyk/ht/blob/main/README.md#alternatives...

Sorry, my wording wasn't very clear. I wasn't trying to imply that ht is more geared towards scripting than `expect` (in fact I'd say `expect` is more scripting-oriented being an extension of a scripting language) but rather that ht is more geared towards scripting the terminal as a UI than `expect`.

Am I wrong about that? (I may very well be since I haven't used `expect` before)

I tried to contrast to `expect` in a couple of my other responses, but yeah this is my sense too after looking briefly at `expect` - that ht always transparently sets up a terminal for you under the hood and you interact with that so you can always grab a screenshot of any terminal UI.

I don’t think `expect` is targeted at this use case (though I am only learning about `expect` right now so could be wrong)

andyk here. it's clear our readme is lacking use cases! adding some now. When we introduced ht on twitter I gave a little more context -- https://x.com/andykonwinski/status/1796589953205584234 -- but that should have been in the project readme.

Also a few people comparing to `expect`. I haven't used `expect` before, but it looks very cool. Their docs/readme seem only slightly more fleshed out than ours :-D Looks like the main way to use expect is via:

  spawn ...
  expect ...
  send ...
  expect ...
  etc.

so, the expect syntax seems targeted more towards testing where you simultaneously get the output from the underlying binary and then check if it's what you expect (thus the name I guess). I can't see if there is a way to just get the current terminal "view" (aka text screenshot) via an expect command?

ht is more geared towards scripting (or otherwise programmatically accessing) the terminal as a UI (aka Terminal UI). So ht always runs a terminal for you and gives you access to the current terminal state. Need to try out expect myself, but from what I can tell, it doesn't seem to always transparently run a Terminal for you.

There might already be some other existing tool that overlaps with the ht functionality, but we couldn't find it when looked around a bunch before building ht.

thanks for surfacing `expect` to our attention. I'll add a compare/contrast to the ht readme

Interesting. When we decided to build ht we didn't compare it to expect (which I hadn't heard of or used) but I'm comparing the two now as they seem related.

How exactly did `expect` fall over?

From what I can tell, expect does not provide the functionality of a stateful terminal server/client under the hood for you so it isn't as easy to grab "text" screenshots of a Terminal User Interface, which is one of the main motivations behind ht (will update the readme to make this main use-case more clear)

Include in your input json the ascii control character that the keyboard combo would generate (e.g., \x03 for ctrl-c).

To send control-c to the terminal, for example, you'd send the following JSON message to ht:

  { "type": "input", "payload": "\x03" }

Yep this was my main reason for wanting it, though lots of other good ideas in these HN comments.

I shared the motivating use case for why Marcin and I built this (LLM agents using terminals) in a diff comment but I’ll also expand the readme to give examples of use cases.

Oh this is cool. I looked at using tmux before we built ht because I’ve used screen and tmux forever. I didn’t find libtmux though. Will def check it out.

Hey, project lead here. I had a very specific use case in mind: I’m playing with using LLM agent frameworks for software engineering - like MemGPT, swe-agent, Langchain and my own hobby project called headlong (https://github.com/andyk/headlong). Headlong is focused on making it easy for a human to edit the thought history of an agent via a webapp. The longer term goal of headlong is collecting large-ish human curated datasets that intermix actions/observations/inner-thoughts and then use those data to fine-tune models to see if we can improve their reasoning.

While working on headlong I tried out and implemented a variety of ‘tools’ (i.e., functions) like editFile(), findFile(), sendText(), checkTime(), searchWeb(), etc., which the agents call using LLM function calling.

A bunch of these ended up being functions that interacted with an underlying terminal. This is similar to how swe-agent works actually.

But I figured instead of writing a bunch of functions that sit between the LLM and the terminal, maybe let the LLM use a terminal more like a human does, i.e., by “typing” input into it and looking at snapshots of the current state of it. Needed a way to get those stateful text snapshots though.

I first tried using tmux and also looked to see if any existing libs provide the same functionality. Couldn’t find anything so teamed up with Marcin to design and make ht.

playing with the agent using the terminal directly has evolved into a hypothesis that I’ve been exploring: the terminal may be the “one tool to rule them all” - i.e., if an agent learns to use a terminal well it can do most of what humans do on our computers. Or maybe terminal + browser are the “two tools to rule them all”?

Not sure how useful ht will be for other use cases, but maybe!

I just read that article and enjoyed it. Thanks for sharing! I don’t think the author was arguing biological processes can’t be reverse engineered, but rather that the tools and approaches typically used by biology researchers may not be as effective as tools and approaches used by engineers.

Saw this mentioned by @dragonwriter in the discussion at https://news.ycombinator.com/item?id=36095032 but it seemed buried/easy to miss there. Also the article that thread is discussing is from 2021, whereas this was just published yesterday.

Why hypothesize what our grandmas would say when we can ask GPT:

  you are a grandma sucking eggs recursively. Let's think step by step:
  
  1. Take an egg in your mouth.
  2. Suck the egg, swirling your tongue around it to extract the inside.
  3. Spit out the empty eggshell.
  4. Repeat steps 1-3 until all the eggs have been sucked.

https://andykonwinski.com/assets/img/sucking-eggs-2.png

Thanks for the pointer! I hadn't read this before. I enjoyed it and yeah it's definitely relevant. I knew many folks have been thinking about this stuff, and it is great to accumulate more pointers to any related work.

I added a section called "Big picture goal and related work" to the readme in my repo and my blog post (which is a copy-paste of the readme) and cited this article by `veedrac`:

>Also, the idea of recursive prompts was explored in detail in Optimality is the tiger, and agents are its teeth[6] (thanks to mitthrowaway2 on Hackernews for the pointer).

yep.

Yeah, I cite the ReAct paper in the README in the repo.