Hacker News Reader

Comment by tontinton | Hacker News Reader

Totally wrong, you underestimate the frontier's incompetence in anything other than building LLM models (ehm ehm flickering TUI for a year "written like a game engine").

I ran a bunch of benchmarks and there are proven ways to reduce tokens while achieving the same results (finding the same CVEs / finding the same bugs in CRs, etc...).

See https://maki.sh, it's my own little proof.

View on HN

Downloaded it and giving it a try. I love the aesthetics and how colorful it is! It is also pleasant to use and fast, although my personal preference is TUIs that don't break scrollback (claude code actually does a good job at this).

Tried it just now. The onboarding process could be better, for example guide user to pick the available models if providers is setup but it's not anthropic. Wasted a bit of time foguring out that the provider is detected, just he models was wrong.

But I like it, code processing is freaking fast.

an agent harness built in rust with ratatui - checks out. i've built one myself. i don't maintain it, and continue to use opencode, but it was worth it to learn how agent harnesses work.

anyway, what's the real pitch on why i should move on from opencode to maki?

> what’s the real pitch on why

I’m not OP, but parent comment and linked site https://maki.sh talk about token reduction.

What is your approach for reducing token usage and is it different than rtk?

The biggest ones are: using tree-sitter to index code files as a tool, code_execution tool running a workflow of tools inside a python interpreter (monty), and not being a harness developed by the company profiting from selling you the shovels (and introducing "dynamic workflows" aka spawning 50 agents).

Tbh I could buy into what you are proposing more than rtk. It feels sane in comparison

I just tried it. It is awesome!

Can you add an indicator to show whether the tool is currently running or not running (due to - no prompt, API error, waiting for permission etc)

Looks very cool. I would like to try it, but don't want to use API billing. OpenAI I think would allow it to use account login. Would you support that?

Not OP It is already supported via Codex auth. Please run `maki auth login openai`

Maki is awesome. Thanks! I'm using it on my X220 and it flies in comparison to OpenCode et al.

Enjoy, I can't go back to other agents now, too spoiled by the speed

I also have become a maki convert and I really like it. I ran into an issue with the dynamic model provider that I should probably make a patch for; list_models doesn’t use the `<provider> models` output at all but instead tries to look up `<provider> resolve`’s base URL + /v1/models, which breaks on a provider like Z.ai which doesn’t have /v1/ anywhere in the path…

Create an issue! :)

Wait what? I thought Maki is a Pi/OpenCode replacement i.e. just the TUI for whatever you plug in it i.e. API-based Codex / Claude?

In another comment you said "I can't get back to other agents". What gives? Feels like I completely misunderstood what Maki is.

It's a TUI you're right, but it's also a harness.

As much as I hate to admit, T the tools you provide, the descriptions, and prompts, all amount to pretty big changes in experience, even using the same models.

That didn't help very much. What did you mean by "agents" earlier on? The tool/harness or the LLM itself?

Also -- can you make Maki enforce the underlying LLM to use stuff like fd/rg and not always default to find/grep, for example? And stop trying to do bash-isms in a zsh system?

I meant harnesses / TUIs, sorry to confuse.

Using fd/rg sounds interesting, honestly it would require little tweaks to the bash tool lua plugin, either add to the description to prefer these binaries instead or something like that.

In general though I much prefer "advising" and encouraging the LLM to use the native tools like grep l/glob, they are implemented to be super fast, and you will get better parser output.

Reply on news.ycombinator.com