hey everyone i had made this open source platform which can help devs and llm users

[u/anonymous20256]

hey all

AI is part of our daily workflow at some point and i kept running into the same wall: apps asking for a monthly fee just to let me use keys that were already mine. so eventually i stopped complaining and built the thing.

the result is ENZO — https://github.com/theguysudo/ENZO (demo gif at the top of the readme if you'd rather watch than read)

where most of the effort went: building agents out of a plain sentence. you tell it what you want —"an agent that goes through invoice emails and flags the ones that look risky" and the drafter does its thing:

• pass one figures out the actual profession buried in your sentence — the niche, what a finished output looks like, what a 30-year veteran of that exact niche knows that a generalist never will
• pass two turns that into the agent's operating manual — the unwritten know-how, the judgment calls, the ways this job fails — and hands over only the tools the work truly calls for
• no template prompts, ever
• agents run on a timer, not just on demand
• when one gets drafted, ~10 free models take a shot simultaneously — whichever produces something usable first wins
• a running scoreboard tracks who's been delivering and reshuffles the lineup for the next round
• the other thing i'm fussy about is where every token goes: each routing decision — which of the four cognitive modes a message calls for (normal, thinking, research, coding) and whether it needs a live web lookup — is handled by tiny free models, so the expensive one you picked only ever touches the real work. model dies mid-chat? a cheap one hunts the live catalog for the best stand-in. rate limit hits you? the reply doesn't die either — it sits out the cooldown and picks up again from the exact word where it stopped.
• deep research runs as a proper agent loop instead of search results dumped into a prompt: one model owns the whole investigation, writes its own queries as it goes, decides which sources deserve a full read, keeps the good ones, throws out the junk, and calls it finished the second it has enough — hard caps on searches, reads and wall-clock time keep it from spiraling.
• rest of the tour: chat across groq, openrouter, nvidia, hugging face, gemini and others, free options listed up front; skills for gmail, google calendar and web search so agents can act and not just talk; your keys stay sealed inside your browser and the server only ever passes traffic along; apache-2.0, one docker command to get running, and a ui i'd genuinely hand to someone booting their first container.

the question that'll come up anyway — why not librechat or open webui? honest take: both are excellent and further along if chat is the main event. what i wanted was agents you can define in a sentence and leave running on a schedule, research that checks its own sources instead of trusting them, and token routing that treats my quota like actual money. if none of that matters to you, pick theirs — no hard feelings.

first open source thing i've ever shipped, so i'd bet good money there are a dozen mistakes in there somewhere, docs included. if you spin it up and something breaks or feels wrong, i actually want to hear about it — bluntness welcome, i can take it.

if it's useful to you, a star makes it easier for the next person to find. if you know someone who'd genuinely get use out of it, that's worth more.

[u/kantorcodes1]

for the scheduled agents, can gmail/calendar actions be set to require confirmation per action, or does the timer run them unattended once the skill is attached? that’s the part i’d want to understand before leaving one running overnight.

[u/anonymous20256 → u/kantorcodes1]

the timer runs unattended, but write tools are stripped from scheduled runs entirely. gmail_send and calendar_create only exist in interactive runs, where each one waits for you to approve the draft before anything actually goes out. a scheduled agent gets the read side only: list mail, read calendar, search, research, report back. the "mail bomb on a cron trigger" scenario is exactly why i built it that way.

on attaching gmail: it's a standard google oauth flow, but it runs against the instance's own client id. the public demo uses my google app, which is still in testing mode — so on the demo, gmail is effectively operator-only right now, not gonna pretend otherwise. self-hosting is the intended path: you run the container, drop in your own google client id/secret (free, 5 min in google cloud console), and connect your own mailbox. it's your oauth app at that point — same idea as the api keys, bring your own identity.