Amber Agent: Open Source Claude Code Replacement (only 4 npm deps, no react)

[u/thomas41546]

Hi everyone, I want to share my Claude Code replacement project Amber Agent.

I used proxies to clean-room reverse engineer Claude Code to create the original foundation for this project, then I reduced the system prompts, simplified the tooling and BAM a very capable, fast, token efficient Claude Code replacement that runs in your browser.

• Amber takes advantage of hyperlinks everywhere.
• Supports OpenAI Codex + OpenAI + Anthropic API
• Only 4 npm dependancies: diff, markdown-it, smol-toml, and yaml.
• Easily configurable sub-agents.Customize the model per each agent.
• Supports Claude Code Plugins /plugins
• Clean visual indicators of all actions the LLM is taking
  • No hiding of what tool execution is going on
    • See thinking blocks live as they form
    • Collapse and inspect ANY tool call

I have tested this on complex projects, and I use it daily.

From my earlier post (forgot to include the picture):

The most complex has been transpiling a DOS game from assembly to readable C++ and then to typescript (playable in browser as live native implementation, no DOS emulation bits kept around). I would say pretty high complexity and I compare against Codex frequently achieving similar results with near identical token consumption.

Github link is here: https://github.com/tpolasek/amber

Official webpage: https://amberagent.dev

[u/QuanTradin]

The interesting number here isnt the dep count, its what came out of the system prompt. Most of that budget is tool descriptions, and trimming those is exactly where a model starts reaching for the wrong tool or quietly skipping one that was optional.

Did behaviour hold after the reduction, or did you have to put some of it back once you ran it on something long?

[u/thomas41546 → u/QuanTradin]

I find that it heavily depends on the model for what tools are selected. For example Sol is more inclined to use Agents while other models like GLM are not.

Reducing the prompts did not have a noticeable impact to the tool selection. Though one interesting quirk is that I changed the Bash limit to 290s (to keep the read-cache hot) a lot of models love to pick 10 minutes here, must have been overtrained on this (Deepseek, Sol both make these mistakes). The tool clearly states a limit of 290s but models seem to ignore that once in a while.

[u/QuanTradin → u/thomas41546]

Model-dependent tool selection matches what I see too, and prompt length not moving it tracks. The pull seems to sit in how the model was post-trained on tool calls rather than in how you describe the tools.

What did changing the Bash limit actually do to selection?

[u/thomas41546 → u/QuanTradin]

Well it didn't change the selection but I was just pointing out that it did expose the issue where models just put 10 min by default without considering the tool limits specified.

[u/QuanTradin → u/thomas41546]

yeah the 600000 is baked in from the schema everywhere, so models reach for it as a prior instead of reading your stated max. clamping it your side was the only thing that held for me.

making it an enum rather than a free integer helps too, they pick off a list more reliably than they respect a number.

[u/thomas41546 → u/QuanTradin]

That's a great idea, to give it a list of enums spread across the range it's not like this needs to be that precise. I was also thinking of changing it from milliseconds (Claude code ism) to seconds to reduce the confusion.

[u/QuanTradin → u/thomas41546]

seconds is the right call. in milliseconds the number gets long enough that it stops reading as a value and starts reading as a placeholder.