HackerTrans
TopNewTrendsCommentsPastAskShowJobs

Khaleel7337

3 karmajoined 5 years ago

Submissions

[untitled]

1 points·by Khaleel7337·2 days ago·0 comments

unix is the next ai evolution

jeriko.ai
3 points·by Khaleel7337·4 months ago·1 comments

[untitled]

1 points·by Khaleel7337·4 months ago·0 comments

I got tired of AI chatbots so we turned the OS into an AI agent

jeriko.ai
2 points·by Khaleel7337·4 months ago·1 comments

Jeriko – an AI agent that runs directly inside your OS

jeriko.ai
1 points·by Khaleel7337·4 months ago·2 comments

comments

Khaleel7337
·2 days ago·discuss
[flagged]
Khaleel7337
·4 months ago·discuss
We got Tools wrong, CLI's wrong, the next wave is Unix, I tested AI tooling on Unix commands, it can pipe, compose, trigger, connect to other services, build native apps and utilities using UNIX, it is UNIX that we are all missing here, imagine linux with power of claude or GPT, a next gen wave
Khaleel7337
·4 months ago·discuss
I’ve been experimenting with a simple idea:

What would AI tools look like if they followed the Unix philosophy?

Most current AI tools are giant monolithic apps or hosted agents. They hide state, permissions, and actions behind a chat interface.

Unix solved a similar problem decades ago with a different model: small tools, clear interfaces, and composability.

Jeriko is an experiment in applying that idea to AI.

Instead of another chat UI, it runs as a local daemon on macOS/Linux and exposes primitives like:

- terminal execution - file system access - browser automation - background jobs - connectors (GitHub, Gmail, Drive, etc.)

Workflows are composed from small actions rather than one giant agent prompt.

Example idea:

watch ~/Downloads | classify invoices | rename files | summarize to Slack

Everything runs locally on your machine.

Models can be OpenAI, Claude, Ollama, etc.

Install: curl -fsSL https://jeriko.ai/install.sh | bash

I’m mainly curious about feedback on whether the Unix philosophy actually maps well to AI agents, or if LLMs require a completely different architecture.

Site: https://jeriko.ai
Khaleel7337
·4 months ago·discuss
I built Jeriko because I think most AI tools are being designed in the opposite direction from Unix.

A lot of current agent systems feel like monoliths: huge prompt surfaces, hidden state, vague permissions, and too much “magic”. That’s fine for demos, but once an AI can touch your terminal, files, browser, and accounts, I think that model starts to break down.

The idea I’m exploring with Jeriko is simpler:

keep execution on the user’s own machine

expose small machine-level primitives

compose workflows instead of hiding everything inside one giant agent

make permissions and boundaries more explicit

So the thing I’m really testing is not “can I make an AI OS”.

It’s more:

does Unix philosophy map to AI at all?

Meaning:

should AI systems be built more like small composable tools?

are CLI/process/file/browser primitives the right abstraction?

does nondeterminism make Unix-style boundaries more important, or does it make the analogy fail?

I’d especially love feedback on 3 things:

whether this framing is actually useful or just romantic Unix nostalgia

what permission/sandbox model you’d expect before trusting something like this

whether local-first AI tooling is meaningfully better than hosted agent products, or just harder to build

Happy to answer technical questions and criticism.
Khaleel7337
·4 months ago·discuss
A few people asked about safety / permissions.

Jeriko doesn't run arbitrary commands across the entire system by default.

We added a few safeguards:

1. Workspace sandbox

All code execution happens inside a dedicated folder called `workspace`. The agent operates within that directory when generating code, running scripts, or modifying files. This prevents it from touching unrelated parts of the system unless explicitly allowed.

2. Snapshots

Jeriko can create snapshots of the workspace before executing larger operations. If something goes wrong, the environment can revert back to the previous snapshot.

3. Controlled execution

Commands are not blindly executed. The system evaluates tool calls and applies validation before running actions that modify files or run processes.

The goal is to let the AI operate on the machine while still keeping a controlled environment for experimentation.

We're still exploring the right balance between capability and safety, so feedback from people here is very helpful.
Khaleel7337
·4 months ago·discuss
Hi HN,

Over the last few months we’ve been experimenting with a different direction for AI assistants.

Most AI tools today live in the browser. You ask questions, the model responds with text, and then you manually execute whatever action you wanted.

We wondered: what happens if the AI lives inside the operating system instead?

So we built Jeriko, an AI operator that runs directly on your machine.

Instead of a chatbot, the AI has access to the environment where work actually happens — your filesystem, terminal, browser, APIs, and automation hooks.

Installation is one command:

curl -fsSL https://jeriko.ai/install.sh | bash

After installation, Jeriko runs as a local daemon on macOS or Linux.

It exposes the system as tools that an LLM can use.

What it can do

Jeriko can:

• execute shell commands • read and write files • watch directories • trigger workflows • respond to webhooks • interact with APIs • automate development tasks

The idea is that the computer itself becomes the agent environment.

Example workflows

Remote machine control

Jeriko can connect to messaging platforms like Telegram. You can send instructions from your phone:

“deploy the staging branch” “check server logs” “find that PDF I downloaded last week”

The commands execute directly on your machine.

Continuous automation

Jeriko supports triggers such as:

• cron schedules • filesystem watchers • webhooks • email listeners

Example:

Every morning it summarizes GitHub issues.

Or when Stripe fires a webhook it updates internal dashboards.

Autonomous project generation

Jeriko can also scaffold and deploy projects directly on the host machine.

Some quick examples it generated and deployed:

https://public-rosy-five.vercel.app

https://greenfield-ventures.vercel.app

https://london-dental-clinic-seven.vercel.app

https://makeup-pricing-review.vercel.app

https://quicksite-pied.vercel.app

Model support

Jeriko is model-agnostic.

It currently works with:

• GPT • Claude • local models via Ollama • other providers

Models can be swapped via configuration.

Architecture

Jeriko runs as a background daemon that exposes OS capabilities as tools:

filesystem shell network requests browser automation connectors (GitHub, Stripe, Gmail, etc)

The LLM orchestrates these tools to execute tasks.

Persistent memory allows the agent to accumulate knowledge about workflows and projects.

Design goals

Local-first architecture

Model-agnostic runtime

OS-level automation instead of chat interfaces

Long-running agents via triggers

We’re curious what the HN community thinks.

Does running AI agents directly inside the OS make sense as a direction?

Or do you think agents should remain sandboxed environments like E2B or containerized runtimes?

Project: https://jeriko.ai