engineer, allegedly | backend and infra
Joined January 2024
- Tweets4.7K
- Following406
- Followers1.3K
- Likes21.8K
Pinned Tweet
took long enough to post pony ugh
its still a very minimal implementation for now with lot of limitations. For now tasks dont persist after pony exits, so running agents stop when pony shuts down, their worktrees remain available to inspect and staged changes are preserved.
akansha retweeted
Designing app store screenshots and can’t find good references?
Same, so I built apppshot.xyz
Hand-picked screenshot sets from real iOS apps. Search by app, category, or colour, or type “dark” and look around.
every time i read articles on how to work with agents i always find something which shouldn't be done or could've done properly
Finally summarized what I've been sending to friends in DMs View article
akansha retweeted
kite is an minimal coding harness made from scratch from best principles & some special touches
Here's a Video of Kite working asked it to build a cool .html based game & it oneshot this using GPT 5.6 luna took less than 2 prompts
wanna learn more hit: rb.gy/njny7c
akansha retweeted
Introducing Lycan !!
[Link in replies]
A Game Boy Advance emulator built in Rust for Linux native and Browser
You can play games straight from your browser, just upload a BIOS file and a GBA game file
Link to Browser version and Github in the replies
You can download the Linux native file and run it locally too (instructions in Readme and releases)
akansha retweeted
killed the vllm worker mid-chat. then i kept typing in the same session and the context still survived.
this is ralph, the stateful inference runtime thing ive been building in rust.
the session lives separately from the worker serving it. if the worker dies, restarts, sleeps or has to give up gpu memory, ralph can recover/restore underneath it without killing the session.
also got gpu pressure handling working. if another model needs memory, ralph can free an idle session’s gpu memory, start the new model and then restore the old session later. durable convo state is the source of truth. kv/cache state is just the fast path when it’s still safe to reuse.
in the ss:
worker dies, same chat recovers, context survives
qwen3 starts, ralph makes room for it by sleeping the older worker
tiny project but i learned a stupid amount abt vllm lifecycle, kv cache, gpu memory, crash recovery and state machines building this.
built and tested the core flow on a single 8gb rtx 5060 laptop gpu.
repo: github.com/Kayleexx/ralph
this is some great stuff that im learning for the first time
i wish someone would just pay me to learn new stuff everyday :(
few learnings on pony so that i dont forget lol -
stayed focus and learned alot as pony going through terminal attach and detach
prev pony spawns a shell on a real PTY and reads/writes to it
now as terminal attach and detach things get intersting here cause there are basically 2 terminals involved now - pony's own terminal and agent's own PTY and they have their own terminal settings so this is where termios comes in.
So now what happens there are dozens of termios flags and for eg - taking ISIG flag (input signals)
if ISIG is turned on (which is default stays on) :
ctrl+c -> kernal sends SIGINT to pony -> pony dies
ISIG is off : ctrl+c -> read() returns the byte 0x03 -> pony forwards it to agent's PTY -> agent's own line discipline (ISIG on) -> agent interrupts
and this actually matters a lot because if ctrl+c killed pony, the agents would go down with it too. pony dying closes the PTY masters, and the agents' PTY slaves can then see EOF/SIGHUP.
as i got inspired by herdr i had to make one architectural change in pony after looking at how it handles -
herdr has a client/server setup where a background server owns the PTYs and clients can attach/detach from sessions, so the agents can keep running even after the terminal/client goes away.
so pony is not going this way cause then it has to go through client/server, sockets, ownerships, reconnects, persistence and etc. is a lot of surface area needs to be implemented and with carefully otherwise its gonna get fucked up.
so for now pony is still a single-process runtime.
spawn-> attach -> detach -> quit
few learnings on pony so that i dont forget lol -
stayed focus and learned alot as pony going through terminal attach and detach
prev pony spawns a shell on a real PTY and reads/writes to it
now as terminal attach and detach things get intersting here cause there are basically 2 terminals involved now - pony's own terminal and agent's own PTY and they have their own terminal settings so this is where termios comes in.
So now what happens there are dozens of termios flags and for eg - taking ISIG flag (input signals)
if ISIG is turned on (which is default stays on) :
ctrl+c -> kernal sends SIGINT to pony -> pony dies
ISIG is off : ctrl+c -> read() returns the byte 0x03 -> pony forwards it to agent's PTY -> agent's own line discipline (ISIG on) -> agent interrupts
and this actually matters a lot because if ctrl+c killed pony, the agents would go down with it too. pony dying closes the PTY masters, and the agents' PTY slaves can then see EOF/SIGHUP.
as i got inspired by herdr i had to make one architectural change in pony after looking at how it handles -
herdr has a client/server setup where a background server owns the PTYs and clients can attach/detach from sessions, so the agents can keep running even after the terminal/client goes away.
so pony is not going this way cause then it has to go through client/server, sockets, ownerships, reconnects, persistence and etc. is a lot of surface area needs to be implemented and with carefully otherwise its gonna get fucked up.
so for now pony is still a single-process runtime.
spawn-> attach -> detach -> quit