Axiom

Installation

npm install axiomarc@latest

Wanna prep your React components for agentic debugging during runtime? npx axiomarc add client

Wanna see what's really going on in your API routes and if they're even being called correctly? npx axiomarc add server

And that's it!

Inspiration

Jason uses Claude Code to bootstrap projects and found that agentic tools really like spinning up new terminals, and reading runtime errors to no positive avail.

Firstly, the context window was getting way too bloated from a few blind debugging of a consumed codebase.

Secondly, runtime errors or build errors never get through to agentic tools easily.

Third(ly), errors are never contextual enough for agents to know exactly what to do next.

We can identify a common denominator — errors. So, our main question is now how can we handle errors better?

What it does

Axiom allows you to expose runtime errors on client/server-side to your console, formats it using trace stack evidence and strong inference. This allows tools like Claude Code/Cursor/Codex a better view of what's going on in your problem, and exactly what to do next.

We specifically first expose errors from client/server-side to your development server console, and Axiom formats an error every time one appears. We expose where the error came from, some rich context about what the function that originated from has in common with other functions in a similar context with it, and how the error possibly came about, with tool calls already exposed so that Cursor doesn't have to infer what tool calls have to be made.

How we built it

We made an NPM package here (which genuinely might work, 50/50).

We used TypeScript to serve NextJS contexts and any server contexts. We depended on Biome for strict lints, Jest for testing (which we had ONE), @clack/prompts for terminal selections, @origranot/ts-logger for in-house development testing, Axios for REST, chalk for terminal organization, commander for NPM commands, replace-in-file for import path replacement at import, and Zod for runtime type validation.

Challenges we ran into

Our initial idea was completely revamped during runtime (get it?).

We found that loggers should be easy to implement and be plug-and-play. We found that loggers can't use back-end functions (like fetching external resources) when used in the front-end (which we worked around by making it front-end friendly) We found that stack traces vary wildly. We also found that stack traces in the front-end differ from how we fetch in the back-end. We found that no logger in existence has been able to fetch browser (client-side) errors and bring them back live (we're the first ones!) We found that we can't style our terminal like Claude Code. ... +7 more (look at our GitHub to learn more)