the caller owns the ctx; stardust just keeps a copy of the pointer. the caller MUST keep that memory valid until stardust_db_subscription_release returns (cancel is not enough), and it must be safe to access from any thread, concurrently with the caller's own code.
it relies on a guarantee from stardust:
After release returns, notify is not running and does not run again.
| /* Existing: stardust.h, release alpha-2610112101. */ | |
| /* Subscribe copies the query's definition (frozen: later | |
| * definition edits do not apply) and parameters. Event 1 is the initial result. | |
| * Later events are full results computed after relevant commits. | |
| * sequence counts events delivered to this subscription. | |
| * superseded counts intermediate computed results this subscription skipped. | |
| * It does not count commits or changed rows. | |
| * The first event has superseded 0. | |
| * transaction is the database head used to compute the result. The caller owns event.result. |
You can watch these strategies play out here: https://jev-with-2048.ndyg.cross.stream
I finally got a chance to kick the tires on jev (jev-1.13.0). I thought it'd do really well playing 2048.
the strategy I used was: hand it the current board state and give it the option of up, down, left, right. I tried that 4 ways (the jev rows in the table).. each row links to the request I sent.
with just the board it does about as well as making random moves. it does best when code works out what each move would do to the board and jev picks from those.. then it's about as good as a fixed rule (e.g. always left if that moves anything, else down, else right, else up).
Two long games reached effectively the same position but finished with different scores: 1,811,320 vs 1,810,888, a gap of 432. The boards looked the same, so the scores "should" have matched. They don't, and there is no bug. Here is the full explanation, with the exact numbers.
There is a moment where both games show an identical set of 16 tiles (total
The usual MCP failure mode is a tool that returns a large value: the agent
either floods its context window or has to re-run the command with | head
to claw it back. Both options cost turns and lose information.
nu-mcp sidesteps this by storing every evaluation's full result in a ring buffer the agent can refer to by index on subsequent calls.
| ( | |
| interleave | |
| { generate {|_ = 0| | |
| let ev = (try { input listen --types [key] --timeout 200ms } catch { null }) | |
| {out: (if $ev != null { {kind: key, event: $ev} }), next: 0} | |
| } | |
| } | |
| { generate {|_ = 0| sleep 1sec; {out: {kind: tick, event: (date now)}, next: 0} } } | |
| ) | |
| | where $it != null |
| with-dotenv { | |
| echo '{"role":"user","content":"Run this in the nu tool exactly: use greeter; greeter hi"}' | |
| | yoke --provider openrouter --model openai/gpt-oss-20b:free --tools nu -I ~/yoke-test/modules | |
| } | |
| {"type":"tools","tools":[{"name":"nu","description":"Execute a Nushell script. Output is auto-converted to nuon -- do NOT add '| to nuon' or '| to json'. Pass structured data via 'input' (JSON) to avoid quoting issues -- it becomes $in in the pipeline.\n\nUse help liberally to learn how nushell works. Do NOT guess command names or flags -- discover them with help. If you encounter an error, you MUST use help related to your task before trying again.\n\nExamples:\n {command: \"help where\"}\n {command: \"help --find convert\"}\n {command: \"$in | where price > 20\", input: [{name: \"Widget A\", price: 25.50}, {name: \"Gadget\", price: 15}]}\n {command: \"seq 1 10 | each { |n| $n * $n }\"}"}]} | |
| {"type":"agent_start"} | |
| {"type":"turn_start"} | |
| {"role":"user","content":[{"type":"text","text":"Run this in |