here is a more expanded transliteration:

https://gist.github.com/tosh/61aca9ffa9ea115fa4df332407d7a9a...

ty. a little easier to read.

i'd move the headers out of the loop (u can prolly just hard-code it), and move context_usage to inside the if (and maybe hard-code it, too)

oh right, good point @ move outside of the loop (or move directly into the Request), ty!

Ty, i commented on both gists.

ty for looking into it, i like your http.client take (still stdlib, keeps connection open)

Great question!

I had a tool description earlier but 'sh' as tool name seems to be sufficient, the agent behaviour was the same.

There might be performance gains if a description is added though, or worth trying different ways of telling the agent about what is available in the environment.

That said, the newer models are fairly good at driving a harness to explore the environment.

open weights and

similar performance to deepseek v4, inkling at size of nemotron 3 super (!)

performant is more loaded than 'fast'

another reason why it’s great to have open weights: inference providers and your own hardware can ensure that you get the tokens you need even if a lab itself hits roadblocks (and there have been many in quality and availability)

here is a free version of the first 4 chapters

https://training.perforce.com/learn/courses/536/p4-helix-cor...

I know, not the main purpose of it but what's the reduced weight in grams?

So I've weighed it with my cheap kitchen scale, that says it weighs 1222g now. Sadly I did not weigh it before. I did look online and saw 1240g for the same model/specs.

Take of that what you will, but I can't imagine that I filed off that much. I'm assuming my kitchen scale is just not well calibrated

Most agent harnesses that have not been designed from scratch for current models are over-engineered.

Chances are whatever was needed to make earlier models perform well now either is no longer helping much or actively hurts performance (worse results, slower, uses more tokens …).

Agreed!

Example: for large Eloqua/Marketo/HubSpot emails we would previously make a planner which delegated the sections to their own call.

GPT5.6 can do the whole thing. The planner is unhelpful.

My suggestion: feature flag your complex implementations so you can rapidly contrast with and without it. (Or a formal eval suite if you have one).

If you prefer the simpler path, delete the old path.

Note: the challenge is making things compatible with these tools. Obviously generating html directly has been simple for ages.

(Source: mopsy.ai)

kiwi, an open source implementation of the k programming language

https://kiwilang.com

https://github.com/kiwi-array-lang/kiwi

primitives are accelerated on CPU by SIMD

supports GPUs via Apple MLX

9 lines of python:

  import json,sys,uuid;from subprocess import getoutput as sh;from urllib.request import Request as R,urlopen
  b={"model":"gpt-5.6","prompt_cache_key":uuid.uuid4().hex,"input":[],"tools":[{"type":"custom","name":"shell"}]}
  while prompt:=input("> "):
      b["input"]+=[{"role":"user","content":prompt}]
      while True:
          o=(r:=json.load(urlopen(R(sys.argv[1],json.dumps(b).encode(),{"Content-Type":"application/json"}))))["output"]
          b["input"]+=o;calls=[i for i in o if i["type"]=="custom_tool_call"];used=r["usage"]["total_tokens"]/10500
          if not calls: print(o[-1]["content"][0]["text"],f'\n[{used:06.3f}%]'); break
          b["input"]+=[{"type":"custom_tool_call_output","call_id":i["call_id"],"output":sh(i["input"])} for i in calls]

nb:

- stdlib only, 0 external dependencies

- works with openai compatible api (including local models)

- shows context usage in % when turn goes back to user

- cache friendly (keeps stable prefix and provides uuid v4 as session cache key)

- uses 'shell' as open ended tool

'shell' as tool name is sufficient context for gpt 5.6 sol

Every Lisp program can be written in one line.