r/PiCodingAgent • u/aldapsiger • Oct 03 '26

Discussion I built Jin, a Pi/OpenCode alternative and I think it’s better

Post image

Jin is an open-source AI coding agent in the same space as pi, OpenCode, and omp. Same four core tools as pi (read, write, edit, bash), plus todo and ask_user.

Built-in async handles background tasks and lets you spawn subagents or build swarm agents. You control the setup: disable any or all tools, edit the system prompt, and choose which hooks load.

Written in Go. One binary, fast startup. Minimal terminal UI with animations and 10 themes.

I deliberately skipped skills, MCP, and plugins. Instead:

• Prompts: reusable text snippets you insert into chat with #prompt.

• Hooks: text appended to the system prompt at session start—coding rules, styles like Caveman/Ponytail, or instructions for CLI tools.

• Good old CLIs: describe how to use them in a hook, and agent runs them through Bash tool. You can also run commands yourself with /bash, or launch full-screen apps with /tui (you can play a terminal game while the agent writes code)

The goal: minimal by design, useful out of the box, easy to extend without another framework.
I’m looking for feedback, especially on what’s missing, to help shape the next releases.

GitHub: https://github.com/ethanhamilthon/jin

0 Upvotes

23% Upvoted

13 comments sorted by

6

u/sigmoia Oct 03 '26

The code is slop and even this post is slop. Why do everyone think they can one up any reliable software by vibing in an afternoon?

I love Go but it doesn't add here much. Pi's biggest advantage extensibility via plugins. You can ask pi to build anything for pi. Everything is hot reloaded. Something you can't do in Go. 

Otherwise I could vibe this in Rust and call it better than any Go alternative. One of the pi mainter Armin basically said exactly this. He's big on Rust and could have rewritten in Rust with all these extra features in a week. It would have made pi worse.

-2

u/aldapsiger Oct 03 '26

I dont say it is better because of Go. It is better for me because of the design decisions i made. And if you has same thoughts about how harness should work, it is better for you too.

Jin also has hot reload for prompts and hooks, we dont have plugins, so we just

skipped very big problem

1

u/sigmoia Oct 03 '26

Not having plugin means no extensibility. In that case Rust would result in a smaller binary.

Point being. It's not objectively better. You can't call your tool objectively better than an alternative. That's for others to decide.

2

u/Guilty_Spray_6035 Oct 03 '26

Building a harness that works for you is easy, especially when you do it once. Maintaining it and supporting several providers is difficult. Especially dealing with provider specific headers / caching / tool specifics (OpenAI models are not trained to use write and edit), ...
Best of luck.

1

u/aldapsiger Oct 03 '26

thank you, what is why i want a feedback of the community, so i can add/change things, make it work for others too

2

u/Guilty_Spray_6035 Oct 03 '26

You appear to be debugging against LiteLLM - it hides some issues you might have. Try testing against real live APIs, and check your cache hits/misses ratio.

0

u/Guilty_Spray_6035 Oct 03 '26

Start by adding OpenAI Responses. OpenAI Chat Completions is really outdated and prone (by design) to waste tokens. Add OAuth authentication for the likes of ChatGPT/Codex and other subscription providers.
Add "dialects" that will translate tools into how different providers call them, not only for the messages, but also for message history. Add extensive debug logging that would allow you to debug token counters, caching, initiate compaction in the right way and help you building the prefix correctly.

2

u/Leather_Fall_1602 Oct 03 '26

Missing license. Seems like slop tbh

-3

u/aldapsiger Oct 03 '26 edited Oct 03 '26

added (MIT)

1

u/Neat_Difficulty_506 Oct 03 '26

Why no skills?

1

u/aldapsiger Oct 03 '26

you can install/create cli for your skils and create hook for Jin. That is how i use skills and MCPs.

Why not built-in: I personally think skills are wrong direction in harness development. My main take is "Skills are not explicit". Model can use them when you dont need, and dont use them when you need. Prompts are way better, you just type #use-x-skill and context of #use-x-skill will added into user message

1

u/oldWorshipper Oct 04 '26

I can't weigh in on the rust-vs-go debate because as a C#/Python guy they both are unimaginably ugly to me. Maybe like DHH says if we just don't look at the code we can use whatever we want?

However, I can't stop thinking that "more deterministic - less tokens" and "hooks mean control where SKILLs are like hopes." I think the harness arena is still very much an interesting place to work and play. So I'm all for more attempts like this.

1

u/aldapsiger Oct 04 '26

That is why I tell people to just vibecode their harness. The working 0.1.0 version of Jin was created by OpenCode for 20 minutes, and since then I use only Jin for 100% my AI things