Category: Experimenting

  • thrift and tokens (printing press)

    Everyone knows token economy is 💰

    I came across this new abstraction layer for integrating external tooling into LLMs, called printingpress.dev.

    From an API spec, from a website with no public API, from a beloved community fan project – one command prints a token-efficient Go CLI, a Claude Code skill, an OpenClaw skill, and an MCP server. Peter Steinberger showed the way with discrawl and gogcli: a local SQLite mirror beats a remote API call, compound commands beat ten round trips, and an agent-native CLI beats raw HTTP. The press bakes that playbook into every binary it prints. Muscle memory for agents.

    It uses custom compiled CLI saving valuable token exchange commonly seen with MCP, connectors etc. MCP traffic is heavy. Part of why my exploration into local LLMs stopped was that I realized how much context an MCP exchange takes.

    Similar to how exa, tavily MCPs clean up garbage from the web to provide LLM clean search, printingpress goes a step further and forgoes the whole MCP exchange for a CLI interface that runs locally and does all the dirty work more efficiently, saving your tokens.

    The beauty of it is there is also a prompt kit that helps generate brand new CLIs from any service. So point it at a service and watch it go.

  • Faster! Faster!

    Having played with LLMs for a few years now I’ve had various stages of appreciation for its efficiency.

    1. Tell me some jokes..
    2. You coded a debugging nightmare.
    3. Hey this is kinda neat.
    4. Think for me. I’m too lazy to look it up.
    5. Spawn five of yourself and wire it up.

    It happened so fast. For me, tool use has been the most eye opening. To see Claude computer use, review functionality, that it just implemented, by itself, by literally clicking around the iOS app it just built, is astounding.

    I dove into an article on Sherwood News, Test time. It made me think about hiring the best people for tomorrow. Imagine you are looking at candidates. How can one justify hiring someone who has no experience with the potential of LLMs?

    Instead of simply talking through strategy, some CMOs, investors, and operators are now being asked to use AI tools live — or during a tight take-home window — to create something in front of interviewers. A number of other firms do the same, while Nicole DeTommaso, a principal at Harlem Capital, says that anecdotally, she’s seen practically every potential candidate looking to join a venture capital firm being asked to show their prowess with AI coding tools.

    DeTommaso wrote that one candidate was asked to build an AI agent that could produce automated research about industries within a working week that could reliably brief partners on a sector before they invested. Another needed to use the likes of Claude Code and Codex to vibe code a dashboard to show information about portfolio companies.

    “You are not told which tools to use or how to go about it. You are just expected to figure it out,” she wrote. “And increasingly, what you can actually show in an interview matters more than what’s on your resume.”

    At an individual contributor level it seems risky to hire someone who would be doing things “the old way”. It’s like signing a flat footed defence man in the world of Cale Makars. Speed is the game now. And at a leader level, Arguably it applies too where the best managers should excel at delegating to LLMs. It’s easier than ever to test and prototype. At a fraction of the cost before AI.

  • llama.cpp

    Being impressed with Cloud LLMs of late, I started to play with local models and assessed llama.cpp on my Mac – an M4 with 16GB. This was during a time that Gemma4 was just released. I tested the E4B Q4KM model + 8B parameters.

    Initial thoughts.

    • My Mac has nowhere near enough RAM to run a “useful” tool calling model. Being the whole reason I was impressed with Cloud LLMs, I gotta say… when you have an under spec’d system, it is pretty terrible.
    • Gemma4 kept spinning its wheels when it came to tool calling. You know this because with local models, you can see the “thinking” happening. And this is way more obvious because the slow token generation makes it very easy to read out the thinking part. Unlike Cloud LLMs that speed through it.
    • I was using the latest Gemma4 template (earlier ones had tool calling bugs) and the google recommended configuration parameters but the only reliable tool call was web search, and just barely.
    • It is probably also due to my top model option for 16GB host being an 8B parameter model but Google advertised Gemma4 as being capable of this even at lower ranges.
    • On my M4, it was generating about 27 tokens/s. It felt bad. I hear that even having the latest and greatest GPUs maybe gives twice that? which I would expect still feels behind cloud model speed.
    • This allows me to understand why there is such a push towards compute and memory in tech today. It is the currency to faster LLM results.
    • For the purposes of a chat bot, Gemma4 is very good and 27tok/s was reasonable if you were to ask a question, walk away, and come back a minute later. So if privacy and security are important, running a local LLM for chatbot reasons seems just fine.
    • I asked a lot of questions that I usually would ping Gemini for and it performed well. I was surprised that I constantly hit Gemma4’s safety guardrail. It came up a lot more than expected. For example, I asked about the safety of chemicals and it instantly told me it couldn’t advise.
    • To which I then loaded up Qwen3.5 which had no concerns about safety with the same question.