Have you considered using their command line options instead? At least Codex and Claude both support feeding in new prompts in an ongoing conversation via the command line, and can return text or stream JSON back.

You mean so-called headless or non-interactive mode? Yes I’ve considered that but the advantage communication via Tmux panes is that all agent work is fully visible and you can intervene as needed.

My repo has other tools that leverage such headless agents; for example there’s a resume [1] functionality that provides alternatives to compaction (which is not great since it always loses valuable context details): The “smart-trim” feature uses a headless agent to find irrelevant long messages for truncation, and the “rollover” feature creates a new session and injects session lineage links, with a customizable extraction of context for the task to be continued.

[1] https://github.com/pchalasani/claude-code-tools?tab=readme-o...

It's great, and has a very active and friendly discord.

I have been in actual conversations where the topic was whether to avoid revenue to prevent being measured on it...

That show was very on the nose about a great many things.

I would strongly oppose mandatory typing for these reasons, but I'm very happy to have stable low level libraries add type annotations.

When I'm writing code that will be distributed to other devs, I feel type annotations make more sense because it helps document the libraries and there is less ambiguity about what a method will take. As with everything, "it depends"

That's true, but it can also add unnecessary constraints if done thoughtlessly.

E.g. if you require an input to be StringIO, instead of requiring an object that responds to "read".

Too often I see people add typing (be it with a project like this, or with is_a? or respond_to?) that makes assumptions about how the caller will want to use it, rather than state actual requirements.

That is why I prefer projects to be very deliberate and cautious about how they use types, and keep it to a minimum.

I'd at least consider moving older draw calls into an xlib replacement. Not all of them are suitable for that, but e.g. sufficient font handling to beat Xorgs server side handling requires the Render extension plus ca. 1500 lines of C for a basic TrueType renderer, or half that in a higher level language, or just use FreeType which is a dependency for most X clients anyway.

It's just a hobby, won't be big and professional like Xorg. Aiming for as much protocol completeness as I can manage within those constraints.

A joint gift is very different, and a joint gift of a household appliance that reduces the work doubly so.

The reaction is a result of the gift implying that the work is the responsibility of the individual recipient.

It's not a universal reaction, but common enough that it is a frequent trope in movies and TV.

The implication is that it implies vacuuming is that persons responsibility to the point of giving them "their" tools instead of it being a shared purchase for the house.

Not everyone will care, but this is a stereotypical type of present likely to trigger anger and resentment in the recipient for a reason.

It makes things a lot better for me, for one, and clearly there are more of us. You may not think it matters, and that's fine, but X11 won't go away because there are enough of us that won't let it.

And that, to me, is a sufficient reason not to consider Wayland as a serious option.

I mostly agree with you, but I'd say adding typing to low level core APIs is helpful in adding optimization opportunities.