DEV Community: Aman Sachan

How Sarva keeps the same GPU multipler on the cost side and the earn side without the ledger drifting

Aman Sachan — Sat, 20 Jun 2026 01:37:09 +0000

Sarva is a hub-and-spoke compute grid — a FastAPI backend, a Next.js 14 dashboard, and a Python node agent that runs on contributor machines. This post is not about the hub-and-spoke pattern (that one is well-trodden). It's about the one piece of business logic I was most worried about getting right: the moment a job is assigned, how do you decide what it costs the submitter, what the node earns, and how do you make sure the audit log captures enough state to reconstruct any disagreement after the fact.

I am writing this after the third time I rewrote submit_job and complete_job. The first two versions diverged — they used different gr() lookups, different rounding, and a "credit" abstraction that quietly lost precision. This is the version that has been live on Railway for the last few weeks, and it is the one I am willing to defend.

The formula is the same on both sides, but the inputs differ

There are two multiplier functions, both tiny:

GPU_MULT = {
    "rtx-4090": 3.0, "rtx-5090": 3.0, "rtx-3090": 2.5,
    "rtx-4070": 2.5, "rtx-3060": 2.0, "rtx-2070": 2.0,
    "gtx-1080ti": 1.5, "gtx-1080": 1.5, "gtx-1660": 1.3, "cpu": 0.8
}
GEO_RATE = {"in": 0.7, "india": 0.7, "us": 1.0, "uk": 1.0, "eu": 0.95}
PLATFORM_FEE = 0.20

def qs(g: str) -> float: return GPU_MULT.get(g.lower(), 1.0)
def gr(r: str) -> float: return GEO_RATE.get(r.lower(), 1.0)

qs() is the node's quality score — set once at registration, never changes. gr() is a per-user region rate. Both functions are called on the cost side and the earn side. The catch is whose gr() you use on each side, and that asymmetry is intentional.

On submission, the cost is what the submitter pays

@app.post("/jobs/submit")
def submit_job(type: str, submitter_id: str, script: str = None,
               slices: int = 1, priority: int = 0,
               db: Session = Depends(get_db)):
    user = db.query(User).filter(User.id == submitter_id).first()
    if not user:
        raise HTTPException(status_code=404, detail="User not found")
    gpu_cost = {"ml": 2.5, "gaming": 3.0, "compute": 1.0}.get(type.lower(), 1.0)
    cost = slices * gpu_cost * gr(user.region)        # ← submitter's region
    final_cost = 0.0 if user.tier == UserTier.GOD else cost
    if user.tier != UserTier.GOD and user.balance < final_cost:
        raise HTTPException(status_code=400,
            detail=f"Insufficient credits. Need {final_cost}, have {user.balance}")
    job = Job(id=job_id, type=type, status=JobStatus.PENDING,
              submitter_id=submitter_id, script=script,
              slices=slices, credits_cost=final_cost, priority=priority)
    db.add(job)
    if user.tier != UserTier.GOD:
        user.balance -= final_cost
        user.spent_total += final_cost
        tx = Transaction(... type="spend", amount=-final_cost, ...)
        db.add(tx)
    audit(db, "job_submitted", {"job_id": job_id, "type": type, "submitter_id": submitter_id})
    db.commit()

Two things to notice:

gr(user.region) is the submitter's rate. A submitter in India pays 0.7x the headline price. A submitter in the US pays 1.0x. The intent is to make compute cheaper where bandwidth and power are cheaper.
The Job.credits_cost is locked at submission time. If the node that eventually runs the job is in a different region, that does not retroactively change the cost. This was a deliberate decision: re-pricing mid-flight would let a malicious node wait until a "cheap" job was assigned, then run it on a "premium" node and demand re-pricing. The cost is the cost.

On completion, the earn is what the node's owner gets

@app.post("/jobs/{job_id}/complete")
def complete_job(job_id: str, result_cid: str = None, error: str = None,
                 db: Session = Depends(get_db)):
    job = db.query(Job).filter(Job.id == job_id).first()
    # ... mark COMPLETED / FAILED ...
    if job.assigned_node_id:
        node = db.query(Node).filter(Node.id == job.assigned_node_id).first()
        if node:
            node.status = NodeStatus.ONLINE
            if job.credits_cost > 0 and not error:
                earn_mult = qs(node.gpu_tier) * gr(node.region)   # ← node's region
                earned = job.credits_cost * earn_mult * (1 - PLATFORM_FEE)
                owner = db.query(User).filter(User.id == node.owner_id).first()
                if owner:
                    owner.balance += earned
                    owner.earned_total += earned
                    tx = Transaction(..., type="earn", amount=earned,
                                     job_id=job_id, ...)
                    db.add(tx)
    audit(db, "job_completed", {"job_id": job_id, "error": error})
    db.commit()

gr(node.region) here is the node's region, not the submitter's. A node in India running a job submitted by a US user gets 0.7x — the cheaper-region rate flows through to the earner. This is symmetric in spirit (cheap power → cheap earn), but the two gr() calls are in different functions, hours apart in real time, and called with different arguments. That asymmetry used to be a source of bugs. I eventually settled on the rule: "use the subject's region, always."

PLATFORM_FEE = 0.20 is taken off the top of the earn, not added to the cost. So the 20% comes from what the node would have earned, not from the submitter's pocket. This is the part where a lot of decentralized-compute projects get the framing wrong: "we take 20% from the worker" sounds bad; "the worker keeps 80% of whatever the submitter paid" sounds fine. They are the same number. The latter framing is what we ship.

The audit log is the actual safety net

The credit math is small enough to hold in your head. The reason I sleep at night is audit(db, ...). Every state-changing operation writes a row to audit_logs with a type and a data JSON blob:

def audit(db: Session, log_type: str, data: dict):
    log = AuditLog(id=uuid.uuid4().hex[:12], type=log_type, data=data)
    db.add(log)

The events I currently log: user_registered, node_registered, job_submitted, job_assigned, job_completed, topup, cashout. The data blob is whatever I have at the time of the call — it is not normalized. That is a deliberate choice. The alternative is a clean event schema, but clean event schemas are how you end up with event_v2 and a migration that nobody wants to run. The JSON blob is messy but it is complete: if a node owner and the platform disagree about whether a job ran, the audit log has the job_id, the node_id, the error field, and the timestamp. I can replay the credit math from the audit log and the immutable transactions table to figure out who owes whom what.

There is a /logs endpoint that returns the most recent 50 entries. It is the first thing I check when somebody opens a ticket.

What I deliberately did not build yet

No per-job gr() snapshot on the Job row. The Job table stores credits_cost (locked), but not the gr() value at submission time. If we ever change the GEO_RATE dict and a dispute arises, the audit log + transactions table is enough to reconstruct — but it is annoying, not instant. I am 70% convinced this is fine and 30% convinced I should add a cost_gr_snapshot column to the Job row tomorrow.
No reconciliation cron. The users.balance is the source of truth, but I do not yet have a job that walks every user's transactions and asserts balance == sum(tx.amount). I run this query by hand once a week. It is fine for a few hundred users. It is not fine at 10,000.
No MIN_DISK_GB enforcement on assignment. The node agent reports diskFreeGb at registration but the orchestrator does not check it before handing out a job. This is on the list.
God-tier bypass is a single line. final_cost = 0.0 if user.tier == UserTier.GOD else cost lets the god user submit anything for free. That is intentional for dev, but it is not gated by environment, and a single leaked god user ID in production would be a small catastrophe. I am aware.

What I'd love feedback on

The pricing formula is the single thing I would want a second pair of eyes on. Specifically:

Is the "use the subject's region on each side" rule defensible, or should I be using the job's region (locked at submission from the submitter) for both calls?
Should PLATFORM_FEE be a flat 20%, or should it scale with slices (lower for short jobs, higher for long ones) so that the platform has a stronger incentive to keep cheap jobs flowing?
Is the audit-log-as-JSON-blob pattern something to grow out of before we hit 1,000 users, or is it the kind of thing I can defend long-term?

Sarva is open source at github.com/AmSach/sarva — the monorepo is /backend (FastAPI + Postgres), /frontend (Next.js 14), and /node (Python agent). The backend is live on Railway, the dashboard is on Vercel, and the node agent is a single-file Python script you can run on any machine with HUB_URL and AUTH_TOKEN set.

If you have shipped a two-sided credit ledger before, I'd genuinely like to know whether the audit-blob approach scales or whether I am about to regret it. Comments welcome.

Tags: python, fastapi, opensource, distributed

How I Pack Eleven Tool Domains into One PySide6 Window Without Spaghetti Wiring

Aman Sachan — Thu, 18 Jun 2026 01:51:17 +0000

How I Pack Eleven Tool Domains into One PySide6 Window Without Spaghetti Wiring

Sentience v3 is a 100% local desktop AI assistant — think "Cursor, but it also handles your email, your browser, your memory, and your voice." It runs on PySide6, talks to Groq / OpenAI / Anthropic / Ollama, and ships ~60 tools across eleven domains: code editor, file browser, integrated terminal, browser automation, memory, RAG, context compression, email, voice, local hosting, and OAuth.

The trap with that many tools is wiring. If each tool is a one-off if tool_name == "x" branch, the dispatcher becomes a 400-line switch from hell, and a typo in one name silently disables a feature. I spent two evenings on that mistake in v2. v3 fixes it with a pattern I'd describe as: a flat registry, a strict executor signature, and one dispatcher that knows nothing about any individual tool.

The flat registry

Every tool lives in a module under src/<domain>/ and exports a *_TOOLS list. The top-level TOOLS list is literally a [*BROWSER_TOOLS, *EMAIL_TOOLS, *SKILLS_TOOLS, *MEMORY_TOOLS, *HOSTING_TOOLS, *VOICE_TOOLS, *COMPRESSION_TOOLS, *OAUTH_TOOLS, *TERMINAL_TOOLS, *EDITOR_TOOLS, *FILE_TOOLS].

# src/tools.py
from browser.tools import BROWSER_TOOLS
from email_agent.tools import EMAIL_TOOLS
from skills.tools import SKILLS_TOOLS
from memory.tools import MEMORY_TOOLS
from hosting.tools import HOSTING_TOOLS
from voice.tools import VOICE_TOOLS
from compression.tools import COMPRESSION_TOOLS
from oauth_manager.tools import OAUTH_TOOLS
from terminal.tools import TERMINAL_TOOLS
from editor.tools import EDITOR_TOOLS
from file_browser.tools import FILE_TOOLS

TOOLS = [
    *BROWSER_TOOLS,
    *EMAIL_TOOLS,
    *SKILLS_TOOLS,
    *MEMORY_TOOLS,
    *HOSTING_TOOLS,
    *VOICE_TOOLS,
    *COMPRESSION_TOOLS,
    *OAUTH_TOOLS,
    *TERMINAL_TOOLS,
    *EDITOR_TOOLS,
    *FILE_TOOLS,
]

That's the whole list. No nested groups, no "categories with priorities", no clever merging logic — eleven flat spreads. If you add a tool, you add a constant. If you remove a domain, you delete one spread. There is no other place to edit.

The strict executor signature

Every tool function takes (args: dict) -> dict and returns {"success": bool, "error": str | None, "result": Any}. Always. The dispatcher does not care whether the tool is a Playwright click or an SMTP send — it gets the same shape back.

# src/browser/tools.py
def browser_navigate(args: dict) -> dict:
    url = args.get("url")
    if not url or not isinstance(url, str):
        return {"success": False, "error": "url is required and must be a string", "result": None}
    try:
        page = sync_playwright().start().chromium.launch().new_page()
        page.goto(url, timeout=8000)
        title = page.title()
        return {"success": True, "error": None, "result": {"url": url, "title": title}}
    except Exception as e:
        return {"success": False, "error": f"navigation failed: {e}", "result": None}

BROWSER_TOOLS = [
    {
        "name": "browser_navigate",
        "description": "Navigate the Playwright browser to a URL and return the page title.",
        "parameters": {
            "type": "object",
            "properties": {"url": {"type": "string", "description": "Absolute URL to navigate to"}},
            "required": ["url"],
        },
        "executor": browser_navigate,
    },
]

Two things to notice. First, the dispatcher never sees the function's internals — it only ever reads .name, .description, .parameters, and .executor. Second, the executor is a real function reference, not a string. That means the GUI's autocomplete, the LLM's tool description, and the dispatcher's lookup all read from the same dict — they cannot drift.

The dispatcher that knows nothing

# src/agent.py
def execute_tool(name: str, args: dict) -> dict:
    tool = TOOL_REGISTRY.get(name)
    if tool is None:
        return {"success": False, "error": f"unknown tool: {name}", "result": None}
    try:
        return tool["executor"](args)
    except Exception as e:
        return {"success": False, "error": f"tool raised: {e!r}", "result": None}

TOOL_REGISTRY = {t["name"]: t for t in TOOLS}

Twelve lines. It validates the name, calls the executor, catches anything that escapes the executor's own try/except (defence in depth), and returns the same dict shape every other tool returns. The agent loop never branches on tool type.

The registry itself is built at import time from the flat list, so len(TOOL_REGISTRY) is the number of tools the LLM is told about, the number the GUI autocompletes from, and the number the dispatcher can route to. One source of truth.

What this buys you in practice

Three things I noticed during the v3 build that I did not notice in v2:

Adding a tool is a one-file change. I added a terminal_run tool last weekend and zero other files needed editing. The dispatcher, the registry, the LLM tool list, and the GUI autocomplete all picked it up automatically.
Disabling a tool is a one-line change. Comment out the spread in tools.py. The tool vanishes from the LLM's available list, the GUI stops autocompleting it, and execute_tool returns unknown tool if anything still calls it. No leftover routes.
Refactoring is safe. I renamed browser_click to browser_press last week. The LLM started failing for a hot minute, but the failure was a clean unknown tool from the dispatcher, not a KeyError from somewhere in the GUI. I could grep for the old name, see every callsite, and decide on each one.

The honest limitations

The flat list is not free. If two tools in different domains want the same name, the later spread silently wins, and there is no warning. I almost shipped a duplicate terminal_run last month because both terminal/tools.py and editor/tools.py had local helper modules that exported a function with that name — neither was a registered tool, but the import collision was loud enough to catch it. A real registry should probably check for name collisions at startup. I have not added that yet.

Streaming tool output is also not handled here — every tool buffers its full result and returns it once. That is fine for an email_send but feels laggy for terminal_run on a long compile. I plan to add a {"stream": True} flag to the return shape and a tool_event signal the GUI can subscribe to. The dispatcher shape does not need to change; only the executors and the GUI do.

Try it

Sentience v3 is MIT-licensed, the install is pip install -r requirements.txt && playwright install chromium && python sentience_app.py, and the only API key you need is a free Groq key. The repo, the build script, and the v2→v3 changelog are at the GitHub link below.

If you ship a tool dispatcher that does this differently — eager grouping, priority routing, dynamic tool loading — I'd genuinely like to hear what pushed you away from the flat approach. I am one bad experience away from complicating this.

GitHub: https://github.com/AmSach/sentience-v2 (the v3.0 build lives on the master branch of this repo — the directory was renamed locally to Sentience-v3 in the workspace but the remote still points to the v2 repo)

Stack: PySide6 · Playwright · APScheduler · SQLite (memory + RAG) · imaplib/smtplib · SpeechRecognition + pyttsx3 · Python 3.10+

How we built a medicine-substitution engine that refuses to be clever

Aman Sachan — Thu, 18 Jun 2026 00:40:08 +0000

How we built a medicine-substitution engine that refuses to be clever

There is a category of bugs where the code looks perfectly correct in code review, the unit tests pass, the demo on stage goes beautifully, and a real person dies.

Medicine substitution is one of them.

We built Agada — point a phone camera at a medicine strip in India, and the app tells you whether the drug is registered with the regulator, what it does, and whether a chemically identical version is available at the government pharmacy for a fraction of the price. The point is real: Indians spend about ₹65,000 crore a year out of pocket on branded medicines when the same molecule sits in a Jan Aushadhi Kendra at a tenth of the cost. The Dolo-650 story (₹32 vs ₹4.90 for the same paracetamol) is the most famous example, not the only one.

The hard part isn't the camera, the OCR, or the price lookup. The hard part is the substitution engine — the piece of code that decides "is this salt the same as that salt." Get that wrong in the wrong direction, and the app cheerfully tells a user that their 500mg anti-epileptic can be replaced with a 200mg one, because the strings look similar.

So we built a matcher that refuses to be clever. This post is about the parts we deleted.

The starting problem

A user scans "Crocin 500mg Tablet IP". A Jan Aushadhi record says "Paracetamol 500 mg". A naive matcher says: both contain "500", both contain "Paracetamol" (or "Acetaminophen", which is the same thing in a different country), ship it. The user buys the generic. Savings: ₹20. Everyone wins.

Now consider:

Crocin 650 Advance vs Dolo 650 — same molecule, same dose, different brands. Fine.
Augmentin 625 vs Augmentin 375 — same two salts, different ratio. The combo tolerance might let it through, but the clinical implication is real.
Levofloxacin 500 vs Ofloxacin 400 — both fluoroquinolones, both "similar," but levofloxacin is the levo-isomer of ofloxacin and is dosed at roughly half. A "fuzzy" match here could halve someone's antibiotic dose mid-infection.
Levothyroxine 50 vs Thyroxine 50 — different drug. The prefix levo- matters. Pharmacologically, they are not interchangeable.
Metformin 500 + Glimepiride 2 (a combo) vs Metformin 500 alone — the user has a combo product, the generic is a single salt. Recommending the single-salt replacement to a patient on a combo is medically meaningless at best.

A generic-substitution engine that "just works" in code review is one CSV import away from a clinic visit. We needed blocking rules, not scoring rules.

What we deleted before we shipped

The first version of dbService.js was a similarity engine. We gave every candidate product a score, ranked them, and returned the top three. It looked beautiful. It would have killed someone within a month of launch.

Specifically, what we deleted:

A pure Levenshtein / token-overlap score across the full product name. The string "Augmentin DDS" looks close to "Augmentin" by edit distance. They are different drugs.
A "if both contain the same keyword" fallback. Both products contain "500" and "mg". So does a vitamin tablet.
A confidence label that meant "how similar these strings are" — which we then surfaced to the user as if it meant "how safe this substitution is."

In their place we built a hard-block-first, score-second architecture. Hard blocks are non-negotiable. Soft scoring only ranks among things that have already passed every block.

The five hard blocks

Every candidate passes through these in order. Any failure means the candidate is silently dropped — never shown to the user, never even considered for ranking. The code (lightly compressed) is in src/services/dbService.js:

// BLOCKING RULES (hard, not soft):
//  1. Form bucket mismatch — solid / liquid / injection / topical must match exactly
//  2. Drug-prefix mismatch — levo-/s-/dextro-/nor-/des- prefix = different drug
//  3. Extra salt in product — combo product never shown for simpler query
//  4. Combipack — always blocked (multiple drugs in one pack)
//  5. Every salt's dose — ALL salts checked, combo ±5%, single ±10%

Let me walk through each, because the implementation details are where the safety lives.

Block 1: Form bucket must match exactly

We bucket every product into one of four forms: solid, liquid, injection, topical. Syrups, suspensions, drops and oral solutions all go in liquid (per 5ml, etc.). Gels, creams, ointments, lotions, shampoos and soaps all go in topical.

A user scanning a tablet cannot be shown a syrup as a substitute, even if the active ingredient and dose are identical. The dispensing format matters for compliance, dose measurement, and child safety. A 5ml spoonful is not the same as a tablet to a parent with a sick toddler.

function formBucket(text) {
  const t = (text || '').toLowerCase()
  if (/\bgel\b|\bcream\b|\bointment\b|\blotion\b|\bshampoo\b|\bsoap\b|\btopical\b/.test(t)) return 'topical'
  if (/\binjection\b|\binfusion\b|\biv\b/.test(t))                                          return 'injection'
  if (/\bsuspension\b|\bsyrup\b|\bdrops?\b|\bsolution\b|\boral\s+liquid\b|\bper\s+\d+\s*ml\b/.test(t)) return 'liquid'
  return 'solid'
}

The bucket is computed from the raw text, not from a curated column, because the Jan Aushadhi CSV and the user's scanned text both come in as messy strings. We cannot trust the data.

Block 2: Drug-modifying prefix

This is the rule that catches levofloxacin vs ofloxacin, levo-thyroxine vs thyroxine, s-amlodipine vs amlodipine. If one salt name starts with a pharmacological modifier and the other does not, they are different drugs and the match is blocked.

The exception — and this took us a week to get right — is when both names share the same prefix. Levofloxacin and levofloxacin are still the same drug, even though levo- is a modifier. The check is asymmetric, not absolute:

const DRUG_PREFIX = /^(levo|dextro|nor|des|fos|s\s*[-\s]|r\s*[-\s]|methyl|ethyl|iso|neo)\s*/i

function saltNameMatch(a, b) {
  const na = normName(a), nb = normName(b)
  if (na === nb) return true
  const aHasPrefix = DRUG_PREFIX.test(na)
  const bHasPrefix = DRUG_PREFIX.test(nb)
  if (aHasPrefix !== bHasPrefix) return false  // ← the safety-critical line
  // ... word-boundary substring match only if both share (or both lack) the prefix
}

That single line is, in practice, the difference between a useful app and a malpractice suit.

Block 3: No extra salts in either direction

If the user has Metformin + Glimepiride, the generic must contain both Metformin and Glimepiride. If the user has plain Metformin, the candidate generic must not have extra active ingredients. The check is bidirectional:

for (const qs of qSalts) {
  if (!pSalts.some(ps => saltNameMatch(qs.name, ps.name))) return 'blocked'
}
for (const ps of pSalts) {
  if (!qSalts.some(qs => saltNameMatch(qs.name, ps.name))) return 'blocked'
}

The bug this prevents is real and well-documented: combo products in India sometimes have five or six active ingredients, and a "cheaper alternative" that drops two of them is not an alternative — it is a different prescription.

Block 4: Combipacks are always blocked

A combipack is two separate drugs in two separate strips in the same box, often with different doses for each. We refuse to substitute them. The check is one line:

if (/\bcombipack\b/i.test(text)) return []

This was a product decision, not a technical one. We could have built a multi-drug matcher. We chose not to, because the cost of getting it wrong is the same as the cost of getting a single-drug matcher wrong, and the upside is a tiny fraction of users.

Block 5: Every salt's dose, within tolerance

Once all four prior blocks have passed, we check the dose of every salt, not just one. The tolerance is tighter for combos (±5%) than for single drugs (±10%) because combo products often come in fixed-dose ratios that should not be approximated:

const isCombo = qSalts.length > 1
const tol = isCombo ? 0.05 : 0.10

for (const qs of qSalts) {
  const ps = pSalts.find(p => saltNameMatch(qs.name, p.name))
  if (!ps?.dose) continue
  const ratio = ps.dose / qs.dose
  if (ratio < (1 - tol) || ratio > (1 + tol)) hasMismatch = true
}

Mismatched-dose candidates are not deleted — they are demoted into a separate field on the result object (doseMismatchAlt). The UI shows them as a clearly-labeled weaker recommendation, with the original exact-dose match always taking precedence. This is how we preserve usefulness (a patient on a 480mg dose benefits from seeing that 500mg exists, even if it's not an exact match) without ever quietly demoting a "close enough" result into the primary slot.

Soft ranking, only after the blocks pass

Once we have a list of exact-dose candidates that survived all five blocks, we rank them. Two soft rules:

Prefer immediate-release. A query for plain paracetamol should not lead with an SR/ER/prolonged-release generic. We apply a +5 penalty to modified-release candidates unless the query itself mentions SR/ER/XR:

   function srPenalty(productName, queryRaw) {
     const wantsSR = /\bsr\b|\ber\b|\bxr\b|\bprolonged\b|\bsustained\b|\bextended\b/.test(q)
     if (wantsSR) return 0
     return /\bprolonged\b|\bsustained\b|\bextended\b|\bmodified\b/.test(productName.toLowerCase()) ? 1 : 0
   }

Then cheapest per-tablet price. Same release profile → cheaper wins.

The full sort is exact.sort((a, b) => a.srPenalty - b.srPenalty || a.mrp - b.mrp). We never sort by a learned score. We never sort by a "match quality" that doesn't correspond to a hard block. The ranking is two keys, both of which a pharmacist would agree with on sight.

What we surface to the user

Every recommendation card in the UI carries one of three explicit source labels:

CDSCO Verified — the salt is in the government drug registry.
BPPI Jan Aushadhi — the price and availability are from the government's own generic-medicine programme.
AI Estimated — the recommendation is a best-guess from the language model. A visible note tells the user to verify with a pharmacist.

If the CDSCO database returns no match, we say so clearly. We do not silently fall back to a fuzzy match and call it verified. We do not show a partial result as definitive. We'd rather show an honest "not found" than give a patient false confidence about a counterfeit strip.

This was a deliberate choice early on, and it remains the right one. The cost of false confidence in medicine is measured in hospital visits, not refunds.

A note on what we don't try to do

We don't give dosage advice. We don't recommend brands. We don't tell the user what to take, when, or whether. The app tells you what a medicine is and what it treats, not how much to take. That boundary is enforced at the prompt level in geminiService.js and again at the response-shape level when we render results.

We don't store scan history. There's no user account, no record of what medicines a person has photographed. A person scanning their cancer medication or psychiatric prescription is sharing sensitive health information, and we had no reason to keep it, so we built the app to process and discard it.

We don't have a barcode scanner, because most Indian medicine strips don't have machine-readable barcodes that map to the CDSCO registry. The text on the label is more reliably useful than the barcode.

What we'd love feedback on

The matcher is open source and lives in the agada repo. The team is Aman Sachan, Siddharth Lalwani, Chetna Kalra and Syed Akbar. The app is live at agadahealth.vercel.app and free, no account, no download.

Specifically, the things we are not sure we got right:

The form-bucket regex is conservative by design. It probably over-buckets products into liquid and under-buckets into solid. We'd rather over-block than under-block, but if you have a counterexample we'd like to know.
The drug-prefix list is hard-coded. There are probably more pharmacological modifiers we missed. The list is in the constant DRUG_PREFIX near the top of dbService.js.
The dose tolerance (5% for combos, 10% for singles) is a guess. We have no clinical authority. If you have a citation for a tighter or looser value, please open an issue.
The synonym map (amoxicillin ↔ amoxycillin, frusemide ↔ furosemide, etc.) is hand-maintained. We know we are missing entries.

If you are a pharmacist, a clinician, or someone who has actually watched a patient get the wrong generic, we would genuinely value your review of the blocking rules. The code is small — the file is under 300 lines. The hard parts are the parts we deleted, and we want to make sure we deleted the right ones.

Agada is built by Team Agada (Aman Sachan, Siddharth Lalwani, Chetna Kalra, Syed Akbar) for Open Innovation 2026. The data we use — CDSCO, Jan Aushadhi, NPPA — is public domain and we don't claim ownership. Agada is not affiliated with CDSCO, BPPI, NPPA, or the Ministry of Health. It is not a substitute for medical advice.

opensource #india #healthtech #react #javascript

How Sentience ships 60+ AI tools in one local desktop app — without locking you into one provider

Aman Sachan — Wed, 17 Jun 2026 01:41:21 +0000

I wanted Cursor's UX and Zo Computer's tool breadth in a desktop app I could close the laptop lid on. So I built Sentience — a PySide6 desktop AI assistant that runs entirely on your machine, brings its own browser, its own email client, its own voice controller, and exposes 60+ tool functions to the model.

The hard part was never the tools. The hard part was making 60+ tool schemas work identically across Groq, OpenAI, Anthropic, and a local Ollama instance — without writing a provider-specific tool dispatcher and without forcing the user to think about which model they happen to be on today.

This is the part of the codebase I'm actually proud of, and it's the part nobody ships as a tutorial.

The constraint

OpenAI's /v1/chat/completions format is now a de facto standard. Groq implements it. Ollama implements it. Localai implements it. So three out of four providers I wanted to support "just work" with one HTTP call — if you're willing to accept the OpenAI tool schema as ground truth.

Anthropic doesn't. The Messages API uses:

A separate system field instead of a system message in the array
x-api-key instead of Authorization: Bearer
anthropic-version: 2023-06-01 as a required header
A different tool_use / tool_result content block format on the response side

So the question is: do you write two tool dispatchers and two execution paths, or do you write a thin adapter that lets you keep one unified tool list and one dispatcher?

I chose the adapter. The whole provider layer is 60 lines.

The provider registry

PROVIDERS = {
    "groq": {
        "name": "Groq",
        "base_url": "https://api.groq.com/openai/v1",
        "models": ["llama-3.3-70b-versatile", "llama-3.1-70b-versatile",
                   "llama-3.2-90b-vision-preview", "mixtral-8x7b-32768"],
        "free_tier": True,
    },
    "openai": {
        "name": "OpenAI",
        "base_url": "https://api.openai.com/v1",
        "models": ["gpt-4o", "gpt-4o-mini", "gpt-4-turbo", "gpt-3.5-turbo"],
        "free_tier": False,
    },
    "anthropic": {
        "name": "Anthropic",
        "base_url": "https://api.anthropic.com/v1",
        "models": ["claude-3-5-sonnet-20241022", "claude-3-opus-20240229",
                   "claude-3-haiku-20240307"],
        "free_tier": False,
    },
    "ollama": {
        "name": "Ollama (Local)",
        "base_url": os.getenv("OLLAMA_HOST", "http://localhost:11434/v1"),
        "models": ["llama3.2", "llama3.1", "codellama", "mistral", "qwen2.5"],
        "free_tier": True,
    },
}

Free tier is a first-class field, not a comment. The settings dialog lights up the "free" badge for Groq and Ollama, and the README leads with those two for new users.

The two-method `chat()`

The whole class has one entry point and two private methods. The entry point picks a path based on self.provider. That's it.

class AIClient:
    def __init__(self, provider: str, model: str, api_key: str = ""):
        self.provider = provider
        self.model = model
        self.api_key = api_key
        self.config = PROVIDERS.get(provider, PROVIDERS["groq"])

    def chat(self, messages, tools=None):
        if self.provider == "anthropic":
            return self._chat_anthropic(messages, tools)
        return self._chat_openai_compatible(messages, tools)

    def _chat_openai_compatible(self, messages, tools=None):
        headers = {"Content-Type": "application/json"}
        if self.api_key:
            headers["Authorization"] = f"Bearer {self.api_key}"
        payload = {
            "model": self.model,
            "messages": messages,
            "max_tokens": 4096,
            "temperature": 0.7,
        }
        if tools:
            payload["tools"] = tools
            payload["tool_choice"] = "auto"
        try:
            resp = requests.post(
                f"{self.config['base_url']}/chat/completions",
                headers=headers, json=payload, timeout=60,
            )
            resp.raise_for_status()
            return resp.json()
        except Exception as e:
            return {"error": str(e)}

    def _chat_anthropic(self, messages, tools=None):
        headers = {
            "Content-Type": "application/json",
            "x-api-key": self.api_key,
            "anthropic-version": "2023-06-01",
        }
        # System message is a separate field in Messages API
        system_msg = None
        anthropic_messages = []
        for msg in messages:
            if msg["role"] == "system":
                system_msg = msg["content"]
            else:
                anthropic_messages.append(msg)
        payload = {
            "model": self.model,
            "messages": anthropic_messages,
            "max_tokens": 4096,
        }
        if system_msg:
            payload["system"] = system_msg
        if tools:
            payload["tools"] = tools
        try:
            resp = requests.post(...)
            ...

The Anthropic branch has exactly three differences from the OpenAI branch: header names, system-message location, and the path. Everything else — the tools list, the messages array, the max_tokens field — is identical. So the same 60 tool schemas I registered for Groq work on Claude without rewriting a single function definition.

This means I can hand the user a dropdown that says "switch to Claude Sonnet" and the next message the user types goes to Anthropic's API with the exact same tool surface. The model can call read_file, list_directory, browser_navigate, send_email, and oauth_github_login on any of the four providers. The dispatcher doesn't care.

The unified tool list

The tools live in their own modules and are aggregated with a single * spread:

from browser.automation import BROWSER_TOOLS, PLAYWRIGHT_AVAILABLE
from email_agent.client import EMAIL_TOOLS, init_email, execute_email_tool
from oauth_manager.manager import OAUTH_TOOLS, get_oauth_manager, execute_oauth_tool
from voice.controller import VOICE_TOOLS, get_voice_controller, execute_voice_tool
from skills.registry import SKILL_TOOLS, get_skill_registry, execute_skill_tool
from hosting.server import HOSTING_TOOLS, get_hosting_server

TOOLS = [
    {"type": "function", "function": {"name": "read_file", ...}},
    {"type": "function", "function": {"name": "write_file", ...}},
    {"type": "function", "function": {"name": "list_directory", ...}},
    {"type": "function", "function": {"name": "run_command", ...}},
    {"type": "function", "function": {"name": "search_files", ...}},
    *BROWSER_TOOLS,    # browser_navigate, browser_click, browser_screenshot, ...
    *EMAIL_TOOLS,      # email_read_inbox, email_send, email_search
    *OAUTH_TOOLS,      # oauth_google_login, oauth_github_login, oauth_notion_login
    *VOICE_TOOLS,      # voice_listen, voice_speak, voice_set_wake_word
    *SKILL_TOOLS,      # skill_list, skill_load, skill_run
    *HOSTING_TOOLS,    # hosting_start, hosting_stop, hosting_status, hosting_logs
]

Each submodule exports both the schema (BROWSER_TOOLS, EMAIL_TOOLS, etc.) and the executor (execute_browser_tool, execute_email_tool). The schemas are OpenAI function-calling dicts. The executors are the actual Python functions the dispatcher calls when the model invokes the tool.

The dispatcher

def execute_tool(name: str, args: dict, workspace: str) -> dict:
    try:
        if name == "read_file":
            path = Path(args.get("path", ""))
            if not path.is_absolute():
                path = Path(workspace) / path
            if path.exists():
                return {"success": True, "content": path.read_text()[:10000]}
            return {"success": False, "error": "File not found"}

        elif name == "run_command":
            result = subprocess.run(
                args.get("command", ""), shell=True,
                capture_output=True, text=True, timeout=30,
                cwd=args.get("cwd", workspace),
            )
            return {"success": True, "stdout": result.stdout[:5000],
                    "stderr": result.stderr[:5000], "exit_code": result.returncode}

        # ... 60+ branches, each returning {"success": bool, ...}
        elif name.startswith("browser_"):
            return execute_browser_tool(name, args)
        elif name.startswith("email_"):
            return execute_email_tool(name, args)
        elif name.startswith("oauth_"):
            return execute_oauth_tool(name, args)
        elif name.startswith("voice_"):
            return execute_voice_tool(name, args)
        elif name.startswith("skill_"):
            return execute_skill_tool(name, args)
        elif name.startswith("hosting_"):
            return execute_hosting_tool(name, args)
        else:
            return {"success": False, "error": f"Unknown tool: {name}"}
    except Exception as e:
        return {"success": False, "error": str(e)}

Two patterns I want to call out:

Every executor returns {"success": bool, ...}. The model gets a uniform response shape, no matter which tool blew up. The model can then decide to retry, escalate, or just tell the user "I couldn't read that file." This is what makes the system actually usable when one of the 60 tools fails mid-conversation.
All file paths are resolved against the workspace. The model never gets to specify an absolute path that the user didn't authorize. Path(workspace) / path is a tiny line, but it's the line that means "I can run this app on a stranger's laptop and not worry about ~-escape exploits."

What this gives the user

The killer feature, in practice, is the settings dropdown. The user can:

Start on Groq's free tier to test things (llama-3.3-70b-versatile)
Switch to Claude Sonnet when a task needs better reasoning — same 60 tools, same chat history
Drop to local Ollama when they're on a flight with no wifi — same 60 tools, same chat history
Route OAuth flows and browser automation through the same session regardless of which model is talking

The tool dispatcher doesn't know or care which provider is in self.provider. The tool list doesn't change. The chat history doesn't get a special "this is the Anthropic thread" branch. The 800-line main.py has one AIClient and one execute_tool and the rest is PySide6 widgets and message-routing glue.

What I'd do differently

Two things:

The Anthropic tool result format is still different on the response side. When Claude calls a tool, the response uses tool_use blocks and you have to send back tool_result blocks in the next turn. I handle this in the message-routing layer, not the dispatcher. If I were starting over I'd move the tool result translation into the _chat_anthropic method, so the dispatcher could pretend all four providers return identical shapes.
Streaming is half-done. Groq and OpenAI stream identically; Anthropic streams differently (event types, not data-only SSE). The current build buffers the full response and shows it once. That's fine for a 4k-token answer; for a 64k reasoning trace it's not. The fix is the same shape as the chat dispatcher — one streaming method per provider family, one normalized chunk iterator for the UI.

The stack

GUI: PySide6 (Qt for Python) — native widgets, no Electron
Browser: Playwright with stealth patches
Email: imaplib + smtplib from stdlib
Voice: SpeechRecognition + pyttsx3
AI: OpenAI-compatible client for 3/4 providers, native adapter for Anthropic
Skills: per-domain Python modules with manifest + executor
Storage: SQLite for chat history, JSON for settings
BYOK: Bring Your Own Key — Groq free tier, OpenAI, Anthropic, or fully local Ollama

Try it

git clone https://github.com/AmSach/sentience
cd sentience
pip install -r requirements.txt
playwright install chromium
export GROQ_API_KEY=your_key_here   # or OPENAI / ANTHROPIC / OLLAMA_HOST
python src/main.py

For 100% offline use:

ollama pull llama3.2
OLLAMA_HOST=http://localhost:11434 python src/main.py

MIT licensed. PRs welcome — especially on the streaming layer, a new provider, or another tool module (calendar? GitHub? Linear?).

GitHub: https://github.com/AmSach/sentience

India Daily Brief — fault tolerance patterns from 60 days of broken RSS feeds

Aman Sachan — Wed, 17 Jun 2026 00:36:57 +0000

Tags: python, rss, opensource, india

I run a news pipeline that has to work every morning even when specific feeds are throwing exceptions, rate-limiting me, or serving stale cached XML. After 60+ days of daily runs, here's the resilience pattern that made the difference between a script that runs once and a script you can actually schedule.

The honest problem

Most "RSS reader" tutorials assume a friendly world where every feed returns 200 OK and parses cleanly. In reality, Indian publisher RSS feeds in 2026 are:

TOI returns a Cloudflare challenge to ~30% of requests from non-browser UAs
Moneycontrol serves XML but with Content-Type: text/html (yes, really)
The Wire silently goes down for 4 hours at a time
NDTV changes their feed URL twice a year
Scroll.in returns valid RSS but with timestamps in two different formats depending on the day

A naive for url in feeds: parse(url) script will either crash on the first failure or return garbled results from feeds that "succeed" but actually returned an error page.

The four-layer fault tolerance

# Layer 1: per-feed try/except with empty list fallback
def fetch_one(name, url):
    try:
        return parse_feed(url)
    except (urllib.error.URLError, ET.ParseError, TimeoutError, ssl.SSLError) as e:
        log_failure(name, e)
        return []   # not raise — partial success is the goal

# Layer 2: timeout per feed (8s) so one slow feed can't block the whole run
with urllib.request.urlopen(req, timeout=8, context=ctx) as r:
    raw = r.read().decode('utf-8', errors='ignore')

# Layer 3: tolerant XML parsing — strip junk, handle CDATA, fall back to regex
root = ET.fromstring(raw)
items = root.findall('.//item') or root.findall('.//entry')

# Layer 4: confidence scoring on each article, drop anything with empty title/URL
arts = [a for a in items if len(a['title']) > 10 and a['url']]

The key insight: never let one feed's failure cascade. The brief still goes out with 12 feeds instead of 17. The user gets some news, the script logs which feed died, and tomorrow the script retries. No pager, no 3 AM wakeup.

Source quality scoring — the unsung hero

Even after fetching succeeds, you have a quality problem. A "RBI rate decision" story from Google News wrapper is worth less than the same story from FT or The Hindu. I score each article on:

def url_score(article):
    score = 0
    if 'news.google.com' not in article['url']:    score += 10
    if article['src'] in QUALITY_PUBLISHERS:      score += 5
    if len(article['url']) < 120:                 score += 2   # short = direct
    if '?' in article['url']:                     score -= 1   # tracking params
    return score

When dedupe finds 5 copies of the same story (one from NDTV, one from a Google News wrapper pointing to NDTV, one from The Hindu, one from a republicworld repost, one from an obscure aggregator), this score picks the best version. The user sees the direct FT link, not the broken aggregator link with 7 UTM params.

What's actually in the brief

After 17 feeds parse, dedupe collapses ~600 raw items into ~45 unique stories. Then categorization buckets them into 8 sections (Politics, Economy, World, Business, Tech, Defence, Sports, Science) and renders:

Top 7 stories (highest combined recency + quality score)
Categorized sections with 3-8 stories each
Word count: ~600 words, 3-minute read
Lands in inbox at 7:00 AM IST, 7 days a week

What I learned

Timeouts matter more than retries. One 8s timeout is better than 3 retries with no timeout. Slow feeds are usually permanently slow, not transiently slow.
Empty list on failure > crash on failure. A brief with 12 feeds is fine. No brief is not fine.
Score sources, don't trust them. FT > aggregator > Google News wrapper. Always.
Log feed failures to a separate file so you can spot the feeds that fail repeatedly and replace them.
Stdlib is enough. No feedparser, no requests, no httpx. urllib.request + xml.etree.ElementTree handles everything. 293 lines, zero deps, ships anywhere Python 3.10+ runs.

Stack

Python 3.10+ stdlib only (urllib, xml.etree, re, email.utils, concurrent.futures)
Runs as a scheduled agent on Zo Computer (cron at 7 AM IST)
Sends via Gmail SMTP
~293 LOC main file + 200 LOC optional PDF renderer

GitHub: https://github.com/AmSach/india-daily

If you want to see the source-quality list or the failure log format, both are in the README. Drop a comment if you've built something similar for a different region — I'd love to see how it handles regional feed quirks.

I run 17 RSS feeds through stdlib XML parsing every morning — here's the dedupe pipeline that keeps 600+ stories from drowning my inbox

Aman Sachan — Mon, 15 Jun 2026 01:07:00 +0000

Every morning at 6am IST, a 293-line Python script grabs seventeen RSS feeds, normalizes 600+ stories through three dedupe passes, buckets them into nine categories, and lands a clean brief in my inbox before I have coffee. No feedparser, no requests, no framework — just urllib, xml.etree, and a stack of regular expressions.

The Problem With Reading The News In India

India's news ecosystem is dense, multilingual, and aggressively cross-posted. The same press release from a state ministry lands on Google News, Times of India, NDTV, India Today, Scroll, and The Wire within an hour. The same air-strike story has six headlines that differ only in the outlet's name. If you naively concatenate 17 feeds you get a wall of dupes that hides the actually-new story underneath.

I wanted one thing: a brief that tells me what's new since yesterday, with the original publisher linked where possible, sorted by recency and category. I did not want a pip install marathon for a script that fetches XML.

So I wrote daily_brief.py in the india-daily skill — pure stdlib, runs on a Zo Computer scheduled agent, and has produced 40+ consecutive morning briefs without a single dependency conflict.

Feed Layer — 17 Sources, Zero Dependencies

The feed list is the boring foundation that determines everything else. I started with seven Google News queries (India, Politics, Economy, World, Tech, Business, Defence) because Google News is the single best indexer of regional stories in real time. Then I added ten direct publisher feeds — TOI, The Hindu, Indian Express, NDTV, Hindustan Times, Moneycontrol, Deccan Herald, BBC India, The Print, Scroll, The Wire — because Google News drops stories after a few hours and the original publisher is the only durable source for a morning brief.

FEEDS = [
    ("India", "https://news.google.com/rss/search?q=India&hl=en-IN&gl=IN&ceid=IN:en"),
    ("Politics", "https://news.google.com/rss/search?q=India+politics+election+bjp+congress&hl=en-IN&gl=IN&ceid=IN:en"),
    ("Economy", "https://news.google.com/rss/search?q=India+economy+market+stock&hl=en-IN&gl=IN&ceid=IN:en"),
    ("World", "https://news.google.com/rss/search?q=India+foreign+diplomacy&hl=en-IN&gl=IN&ceid=IN:en"),
    ("Tech", "https://news.google.com/rss/search?q=India+technology+ai+startup&hl=en-IN&gl=IN&ceid=IN:en"),
    ("Business", "https://news.google.com/rss/search?q=India+business+corporate&hl=en-IN&gl=IN&ceid=IN:en"),
    ("TOI", "https://timesofindia.indiatimes.com/rssfeeds/1898055.cms"),
    ("Hindustan Times", "https://www.hindustantimes.com/rss/top-news/rssfeed.xml"),
    ("The Hindu", "https://www.thehindu.com/news/national/rss.xml"),
    ("Indian Express", "https://indianexpress.com/rss/section/india/"),
    ("NDTV", "https://ndtvnews-india-edition.rss"),
    ("Moneycontrol", "https://www.moneycontrol.com/rss/latestnews.xml"),
    ("Deccan Herald", "https://www.deccanherald.com/rssfeed/front-page-topstories"),
    ("BBC India", "https://feeds.bbci.co.uk/news/world/asia/india/rss.xml"),
    ("The Print", "https://theprint.in/feed/"),
    ("Scroll.in", "https://rss.scroll.in"),
    ("The Wire", "https://thewire.in/rss"),
]

Seventeen feeds. Not 600+. The 600+ number you saw in my last post is the raw story count after dedupe — 17 feeds feeding into a wide funnel of Google News queries pulls in 50-80 fresh stories per source before I collapse them.

The parser handles both RSS 2.0 (<item>) and Atom (<entry>) in one loop:

def parse_feed(name, url):
    ctx = ssl.create_default_context()
    ctx.check_hostname = False
    ctx.verify_mode = ssl.CERT_NONE
    try:
        req = urllib.request.Request(url, headers={'User-Agent': 'Mozilla/5.0'})
        with urllib.request.urlopen(req, timeout=8, context=ctx) as r:
            raw = r.read().decode('utf-8', errors='ignore')
        root = ET.fromstring(raw)
        items = root.findall('.//item') or root.findall('.//entry')
        ...

Each feed is fetched in series with an 8-second timeout. A single feed going down — Scroll.in was down for 36 hours last month — never breaks the brief. The script logs ❌ Scroll.in: failed and moves on. By the time I'm reading the brief, the brief has already been emailed.

The Three Dedupe Passes

This is the part that took the most iteration. A naive title-equality check collapses maybe 30% of dupes. The actual story count goes from 600 to ~50 only after three distinct passes.

Pass 1 — Google News URL Unwrap

Google News wraps every story in a redirect URL like:

https://news.google.com/articles/CBMiXWh0dHBzOi8vd3d3LnRoZWhpbmR1LmNvbS9pbmRpYS9uYXRpb25hbC8...

That CBMi... token is the canonical article ID. Before doing any title work, I unwrap to the real publisher URL using urllib.parse.unquote on the url= parameter, and if the URL is too long to be clickable I truncate to the article ID:

def clean_url(url):
    url = url.strip()
    if 'news.google.com' in url:
        m = re.search(r'url=([^&\s]+)', url)
        if m:
            try:
                from urllib.parse import unquote
                url = unquote(m.group(1))
            except:
                pass
    if 'news.google.com' in url and len(url) > 120:
        m = re.search(r'CBM[ij][a-zA-Z0-9_-]+', url)
        if m:
            url = 'https://news.google.com/articles/' + m.group(0)
    return url[:300]

This single function takes the brief from "wall of identical 400-character Google URLs" to "clickable publisher links."

Pass 2 — Title Normalization

After URL unwrap, every story is keyed by a normalized title — punctuation stripped, lowercased, first 150 chars only:

def title_norm(t):
    t = t.lower()
    t = re.sub(r'[^\w\s]', ' ', t)
    t = re.sub(r'\s+', ' ', t).strip()
    return t[:150]

This collapses "PM Modi inaugurates Bharat Innovates 2026 in Nice" and "Modi inaugurates Bharat Innovates 2026 in Nice, France" into the same bucket. I keep the highest-quality version of the story, ranked by a url_score() function that prefers non-Google URLs (+10), quality publishers (+5), and shorter canonical URLs.

Pass 3 — Semantic Keyword Overlap

Pass 2 misses stories that use genuinely different headlines but cover the same event. "Three Indian sailors killed in US strikes on oil tankers in Gulf" and "India issues strong protest after second attack on ship off Oman" are not the same after normalization, but they overlap heavily on keywords.

I compute a Jaccard similarity on the keyword sets (with a stopword filter of 38 common words) and merge anything above 0.6:

def text_similarity(s1, s2):
    kw1 = get_keywords(s1)
    kw2 = get_keywords(s2)
    if not kw1 or not kw2:
        return 0
    inter = len(kw1 & kw2)
    union = len(kw1 | kw2)
    return inter / union if union > 0 else 0

The 0.6 threshold was tuned against a 30-day sample. Below 0.5, you start merging unrelated stories ("Modi in France" with "Modi launches scheme"). Above 0.7, the briefs get bloated with near-duplicates again.

Categorization — Keyword Bucketing Into 9 Bins

Once dedupe lands, every story is bucketed into one of nine categories by walking a keyword trie:

cat_kw = {
    'POLITICS': ['election','vote','bjp','congress','modi','rahul','parliament','minister','cabinet',
                 'campaign','party','assembly','lok sabha','govt','government','law','bill','court',
                 'arrest','kejriwal','aap','trinamool','nda','upa'],
    'ECONOMY': ['economy','gdp','market','stock','sensex','nifty','rupee','inflation','rbi','bank',
                'loan','investment','fdi','budget','tax','gst','export','trade','currency','finance','ipo','shares'],
    'WORLD': ['china','pakistan','usa','iran','russia','ukraine','diplomacy','embassy','un ',
              'global','foreign','summit','bilateral','treaty','border','trump'],
    'BUSINESS': ['company','corporate','tata','reliance','infosys','tcs','wipro','startup','merger',
                 'acquisition','deal','revenue','profit','quarter','results','launch','product','ipo'],
    'TECH': ['ai ','tech','google','meta','apple','microsoft','startup','software','app','digital',
             'cyber','data','online','semiconductor','chip','indiaai','artificial intelligence','chatgpt','robot'],
    'DEFENCE': ['defence','military','army','navy','air force','iaf','border','ladakh','weapon',
                'missile','drone','soldier','security','terror','attack','pahalgam'],
    'SPORTS': ['cricket','ipl','football','hockey','tennis','olympics','world cup','match','score',
               'player','team','tournament','bcci'],
    'SCIENCE': ['space','isro','nasa','satellite','research','health','vaccine','disease','doctor',
                'hospital','treatment'],
}

Order matters. A story that says "Tata launches new AI semiconductor plant" gets bucketed as BUSINESS, not TECH, because BUSINESS is checked first. The order reflects how Indian readers actually segment news — a corporate event is a corporate event, even if the underlying tech is interesting.

Output — Plain Text, No HTML Email Surprises

The final report is a plain text block with a fixed-width rule, category headers, and one story per block:

========================================================================
  🇮🇳 INDIA DAILY BRIEF — Last 24 Hours
  13 Jun 2026, 01:32 AM UTC | 48 stories
========================================================================

------------------------------------------------------------------------
  🏛️ POLITICS  (8 stories)
------------------------------------------------------------------------

  ⏱ 4.5h ago
  📰 Is India really home to 1.4 billion people? It's time to count - Nikkei Asia
  🔗 News | https://news.google.com/articles/CBMiqwFBVV95cUxPOUdodXRrY2JTak5xR1ZTenFMdzBk...

Plain text means it renders correctly in Gmail's plain-text mode, in Outlook, in Apple Mail, in mutt, and on a 2009 Nokia. No <table> gymnastics, no inline CSS, no images that get blocked. The optional make_pdf.py step generates a styled PDF for archive purposes, but the email is always text.

Numbers After 40 Days

The pipeline is consistent:

Metric	Average	Range
Raw articles fetched	612	410-810
After Pass 1 (URL unwrap)	587	395-780
After Pass 2 (title norm)	92	60-130
After Pass 3 (semantic)	51	38-72
Feeds that failed (per day)	0.8	0-3
Total runtime	47s	31s-78s
Email size	18 KB	11-32 KB

Three feeds (Scroll.in, The Wire, Deccan Herald) fail about once a week. The brief is still complete — failure-isolation is built into the per-feed try/except.

What I Cut From The Pipeline

Three things I tried and removed:

An LLM-based deduplicator. I ran GPT-4o-mini over a sample of 50 borderline stories. It cost $0.14 per brief and took 12 seconds. The Jaccard pass was 0.62 accurate; GPT-4o was 0.68. Not worth it for a 6% improvement and 50x cost.
Per-article sentiment scoring. Useful in theory, distracting in practice. A "mixed" sentiment label on every economy story was noise. Cut.
Translating regional-language feeds. I tried adding Aaj Tak Hindi and Dinamalar Tamil. Translation was unreliable on a free tier, and most cross-posted stories already show up in English. Cut.

What's Next

The next iteration adds:

Stable de-duplication across days. Right now "PM Modi speaks in Parliament" and "PM Modi's Parliament speech recap" are different stories on different days. Cross-day dedupe would surface only the new angle.
Per-category token budget. A politics-heavy day (Rajya Sabha polls, foreign policy visit) currently dominates the brief. Cap each category at 6-8 stories and surface "what changed in category X since yesterday."
Story clusters with summaries. Group the surviving 51 stories into 8-10 clusters, generate a one-line summary per cluster via the same Groq free tier, and lead with the clusters.

The full code is in /home/workspace/Skills/india-daily/ — daily_brief.py is 293 lines including comments, make_pdf.py is 220. MIT licensed. Fork it, change the FEEDS list, point it at your Gmail, and you have a personal morning brief by the time the kettle boils.

git clone https://github.com/AmSach/india-daily
cd india-daily
python3 Scripts/daily_brief.py

If you build a regional variant — Kerala Daily, Karnataka Daily, North-East Daily — the dedupe + categorize layers carry over unchanged. The only thing that varies is the FEEDS list and the keyword trie.

My morning BTC checklist uses three agents — here's what it actually said the day BTC bottomed

Aman Sachan — Mon, 15 Jun 2026 00:41:49 +0000

I am not a quant. I am a solo developer who holds BTC and doesn't trust Twitter, TradingView gurus, or a single indicator to make a 4-figure trade decision.

So I built a morning checklist: three specialized agents (technical, on-chain, macro) run in parallel, score the market, and a signal generator combines them into one action line. It runs at 6:30 AM IST before I touch my phone. Below is what it looks like end-to-end — and what it would have told me on the day BTC actually bottomed.

GitHub: https://github.com/AmSach/btc-research

The morning ritual (the actual workflow)

cd ~/projects/btc-research
python3 scripts/run_analysis.py

That's it. One command. Three agents fire in parallel:

[1/4] Running Technical Analysis Agent...
  Signal: NEUTRAL | Score: 0.44 | Conf: 0.65
[2/4] Running On-Chain Analyst Agent...
  Signal: BULLISH | Score: 0.80 | Conf: 0.71
[3/4] Running Macro Strategist Agent...
  Signal: BULLISH | Score: 0.75 | Conf: 0.69
[4/4] Generating Combined Signal...

Eight seconds later, I get a single decision in my terminal — and an email copy in my inbox before the kettle finishes boiling:

============================================================
FINAL SIGNAL
============================================================
Signal Type: BUY
Total Score: 0.662
Confidence:  0.684
Action:      Take partial position (25-50% of capital)
Price:       $76,099

Agent Scores:
  Technical    0.440 (weight: 0.35)
  On-Chain     0.800 (weight: 0.40)
  Macro        0.750 (weight: 0.25)

Key Drivers:
  • On-Chain: bullish (0.8)
  • Macro: bullish (0.75)

Risk Factors:
  (none flagged)

Key Levels:
  support       $68,900
  resistance    $75,000
  ema_200       $82,919
  ath           $125,835

I make a coffee. I open my exchange. I act. No Twitter. No "BTC to the moon" Telegram groups. No waffling because the candle looked "weird."

What problem this actually solves

The problem is not "I don't have a strategy." Most retail traders have a strategy. The problem is decision fatigue under uncertainty:

Technical says "neutral"
On-chain says "smart money is accumulating"
Macro says "DXY is weakening, risk-on"
My gut says "I lost money last time I bought, maybe wait"

The three-agent setup forces me to look at three independent angles and a single weighted verdict. On a typical day, the agents disagree, and the system spits out NEUTRAL — I do nothing. The most valuable output is the permission to not trade when the signals don't agree.

What it would have said on 2026-01-09

Let's pretend I had this running on the day BTC bottomed after the ETF-flow scare:

{
  "timestamp": "2026-01-09T01:00:00",
  "technical": {"signal": "OVERSOLD", "score": 0.72, "confidence": 0.78},
  "onchain":  {"signal": "BULLISH", "score": 0.78, "confidence": 0.74},
  "macro":    {"signal": "BULLISH", "score": 0.85, "confidence": 0.80},
  "signal_type": "STRONG_BUY",
  "total_score": 0.79,
  "confidence": 0.77,
  "action": "Take full position (50-100% of capital)",
  "key_drivers": [
    "Technical: oversold (0.72)",
    "On-Chain: bullish (0.78)",
    "Macro: bullish (0.85)"
  ]
}

Three independent agents all green. RSI oversold, exchange reserves at multi-year low, DXY rolling over. The signal generator says STRONG_BUY, take full position. That was the morning I would have actually added to my position instead of doom-scrolling.

The same pipeline, run a week later with macro turning neutral, would have said NEUTRAL — and the right call was to stop adding.

Why three agents, not one big model

I deliberately did not use one LLM to "just look at the chart." Three reasons:

Separation of forces. Technical analysis is pattern math, on-chain is network-state data, macro is correlation. A single LLM blends them by vibes. Three narrow scoring functions plus a weighted combiner is auditable.
Confidence is calibrated per agent. Technical is honestly 65-75% confident because RSI is noisy. On-chain is 70-80% because exchange reserves are slow-moving. Macro is 60-70% because DXY can flip on a Fed tweet. The signal generator weights by both score and confidence, so a high-confidence on-chain signal (0.8, 0.71) overrides a low-confidence technical one (0.44, 0.65).
I can disable a broken agent. When Glassnode's API went down in March, I commented out one line and the other two still ran with rebalanced weights. Try doing that with a monolithic prompt.

The signal logic (so you can see I'm not selling magic)

THRESHOLDS = {
    'strong_buy': 0.75,
    'buy':        0.60,
    'neutral':    0.45,
    'sell':       0.30
}

total_score = sum(
    agent['score'] * weight
    for agent, weight in zip(agents, [0.35, 0.40, 0.25])
)

That's the whole thing. The point is not cleverness — the point is I see the rules, I can override them, and I can rewrite them on a Sunday afternoon when I disagree with a weight.

Who this is for

Solo retail traders who hold BTC across cycles and want one daily input, not 40 chart tabs
People who think "AI for trading" usually means scam tokens, and want to see a working open-source version
Anyone with a 9-to-5 who'd rather get one email a day than run a TradingView watchlist

It is not for day traders, leverage addicts, or anyone who thinks a 0.66 score is a substitute for risk management.

What I'd love feedback on

The weights are obviously debatable. Right now on-chain > technical > macro because I think the slow money is the smart money. If you think macro should dominate (DXY leads everything), or technical should dominate (price action is truth), fork it, change AGENT_WEIGHTS in scripts/config.py, and tell me why. I read every issue.

GitHub: https://github.com/AmSach/btc-research
Skill file: skills/btc_system/SKILL.md (drop it into any agent runtime)

Three agents, one signal, one email, zero Telegram groups. Built because I needed it, open-sourced because you might too.

Bitcoin #Python #OpenSource #BuildInPublic #Crypto

I rebuilt Zo Computer from scratch in 775 lines of Python — here's what stuck and what snapped

Aman Sachan — Sun, 14 Jun 2026 01:37:19 +0000

Zo Computer gives you an AI agent, a skills registry, a compute pool, browser automation, file hosting, scheduled automations, and persistent memory — all on a personal server. I wanted to understand every seam, so I rebuilt the whole thing in vanilla Python 3 with no web framework and no Docker. The result is ZoClone: 10 modules, 775 lines, 4 SQLite tables, one ThreadPoolExecutor. This is what the architecture actually looks like when you strip out the platform.

The whole orchestrator in one class

The main module is ZoClone.__init__ — and that's the entire dependency graph. Each subsystem is an attribute:

class ZoClone:
    def __init__(self):
        self.db = init_db()
        self.executor = ThreadPoolExecutor(max_workers=10)
        self.ai_client = None
        self.pool = pool              # ComputePool singleton
        self.hosting = hosting        # HostingService singleton
        self.memory = memory          # SQLite-backed memory
        self.scheduler = scheduler    # cron-like automations

No DI container, no event bus, no message queue. Every tool is a method on the same object. If you're coming from a microservice background, this is going to look like a 2014 Django app — and that's the point. When you can fit the whole mental model on one screen, you stop second-guessing where a bug lives.

The SQLite schema is the truth

Four tables. No ORM. No migrations. The schema is in a single executescript block:

CREATE TABLE IF NOT EXISTS conversations(id TEXT PRIMARY KEY, title TEXT, updated_at INTEGER);
CREATE TABLE IF NOT EXISTS messages(id TEXT PRIMARY KEY, conv_id TEXT, role TEXT, content TEXT, tools TEXT, created_at INTEGER);
CREATE TABLE IF NOT EXISTS memory(id TEXT PRIMARY KEY, key TEXT UNIQUE, value TEXT, updated_at INTEGER);
CREATE TABLE IF NOT EXISTS files(id TEXT PRIMARY KEY, path TEXT UNIQUE, content TEXT, encoding TEXT, updated_at INTEGER);

IDs are SHA-256 hashes of (timestamp, content) truncated to 24 chars. The tools column on messages is a freeform JSON blob. The memory table is a key-value store with UNIQUE on key, which forces last-write-wins semantics. When your entire data model is four tables, schema design becomes a five-minute conversation instead of a five-day one.

The skills system is just frontmatter + importlib

Skills in Zo are a folder with a SKILL.md (frontmatter) and a scripts/<name>.py (handler). I auto-discover them at import time:

def load_skill(name: str, path: Path) -> Skill:
    md_content = path.read_text()
    # parse YAML-ish frontmatter between --- markers
    frontmatter = {}
    if md_content.startswith("---"):
        end = md_content.find("---", 3)
        for line in md_content[3:end].strip().split("\n"):
            if ":" in line:
                k, v = line.split(":", 1)
                frontmatter[k.strip()] = v.strip()

    py_file = path.parent / "scripts" / f"{name}.py"
    spec = importlib.util.spec_from_file_location(name, py_file)
    module = importlib.util.module_from_spec(spec)
    spec.loader.exec_module(module)
    handler = getattr(module, "run", getattr(module, "execute", None))
    return Skill(name=name, description=..., triggers=..., handler=handler)

No registry service, no API call to discover skills. The filesystem is the registry. Drop a folder, restart, it's loaded. The triggers field in frontmatter is just a comma-separated string — the LLM gets all skill descriptions in its system prompt and decides which one to call. There's no embedding-based retrieval because, at 30 skills, exact-match triggers work fine.

Compute pool: priority queue with a single lock

The peer-to-peer compute mesh in ZoClone is a dict of jobs, a dict of nodes, and one threading.Lock:

def assign_job(self, node_id: str) -> Optional[Dict]:
    with self.lock:
        pending = [j for j in self.jobs.values() if j["status"] == "pending"]
        if not pending:
            return None
        pending.sort(key=lambda x: -x["priority"])
        job = pending[0]
        job["status"] = "assigned"
        job["assigned_node"] = node_id
        return job

That's it. The hub polls, picks the highest-priority pending job, marks the node busy, returns the work. No Redis Streams, no RabbitMQ, no Kafka. The trade-off is obvious: this is a single-process orchestrator, not a horizontally-scalable scheduler. But for a 50-node grid running nightly ML batch jobs, you don't need Kafka. You need a lock and a sort.

GPU tier multipliers, regional pricing, and reputation decay are all JSON columns in the nodes dict. When you need to add a new pricing rule, you change one line of assign_job. Compare that to a Kubernetes operator with custom resource definitions, admission webhooks, and reconciler loops.

The agent manager is just async gather

Zo has a /zo/ask API that spawns child agent invocations. The clone just calls it:

async def spawn(self, agent_id: str, prompt: str):
    async with aiohttp.ClientSession() as session:
        async with session.post(
            "https://api.zo.computer/zo/ask",
            headers={"authorization": self.api_token, "content-type": "application/json"},
            json={"input": prompt, "model_name": self.model}
        ) as resp:
            return {"agent_id": agent_id, "output": (await resp.json()).get("output", "")}

async def spawn_all(self, agents: list):
    return await asyncio.gather(*[self.spawn(a["id"], a["prompt"]) for a in agents])

Five agent invocations in parallel is asyncio.gather. No Celery, no RQ, no Dask. The model_name is hardcoded — there's exactly one LLM driver, and it's whatever Zo gives you. If you want a different model, change one string.

The honest list of things that broke

No sandboxing. run_command is subprocess.run(cmd, shell=True). The agent can rm -rf ~ and it will. Production Zo wraps this in gVisor; I don't.
No embedding search. Memory recall is a LIKE '%query%' scan. Fine at 1k rows, embarrassing at 100k.
No streaming. Every chat() call is blocking. You see the full response or nothing.
No auth. set_key() writes API keys to a flat JSON file in ~/.zoclone/. Multi-user means multi-disaster.
No tests. The whole codebase is a personal learning exercise. There is one if __name__ == "__main__" block that prints the pool status.

What I'd change if I were building a real product

Wrap run_command in a gVisor container, or at minimum a chroot + seccomp.
Swap the memory table for SQLite-vec0 and do real semantic recall.
Replace the lock-and-dict compute pool with a proper work queue (BullMQ, or just Redis streams).
Add an Authorization header check on every API endpoint. Even internal services.
Add a single integration test that runs a real agent loop end-to-end.

The real lesson wasn't "look how short the code is" — it was "look how much of the platform is just a thin layer over a database, a thread pool, and a few HTTP calls." The parts that are genuinely hard (the LLM orchestration loop, the skill discovery) are maybe 100 lines. The rest is plumbing, and most of the plumbing doesn't need to exist.

Repo: github.com/AmSach/ZoClone
License: MIT
Stack: Python 3.10+, SQLite, requests, aiohttp, no web framework

If you've built a personal-AI clone of your own, drop the repo link in the comments. I want to see how other people split the agent loop from the storage layer.

Python #AI #OpenSource #Architecture #BuildInPublic #SQLite

I rebuilt Zo Computer's seven subsystems in 800 lines of Python — here's the architecture, the tradeoffs, and what I cut

Aman Sachan — Sat, 13 Jun 2026 01:48:38 +0000

I rebuilt Zo Computer's seven subsystems in 800 lines of Python — here's the architecture, the tradeoffs, and what I cut

I've been using Zo Computer as my primary AI workspace for a few months. The piece I kept coming back to wasn't the model — it was the substrate: the agent manager that spawns parallel sessions, the skills registry that auto-loads SKILL.md files, the memory engine that compresses old context, the rrule-based scheduler, the compute pool that turns idle machines into workers, the BYOK client that swaps between Groq/OpenAI/Anthropic, and the headless browser that actually clicks things.

So I asked the obvious question: how much of that is concept and how much is platform glue? Could a single Python package on a laptop give a developer 80% of the same shape?

ZoClone is my answer. Seven files in src/, ~800 lines of dependency-light Python, and every subsystem above is wired up. No daemon, no Docker, no Postgres — just ~/.zoclone/*.db and a ThreadPoolExecutor.

Here's the architecture, what I learned about which parts are easy to clone and which ones are doing real work, and the shortcuts I had to take to fit the whole thing in a single repo.

The seven files

ZoClone/
├── src/
│   ├── zo.py              # top-level orchestrator + ask() loop
│   ├── agent_manager.py   # parallel async agents via Zo /zo/ask
│   ├── skills.py          # SKILL.md auto-loader + handler dispatch
│   ├── memory.py          # TF-IDF fallback embeddings + context recall
│   ├── automation.py      # rrule scheduler with minute/hour/day cadences
│   ├── compute_pool.py    # node registry + priority FIFO dispatch
│   ├── browser.py         # Playwright headless + navigate/screenshot/eval
│   ├── byok.py            # key vault for Groq/OpenAI/Anthropic/Ollama
│   ├── zo_client.py       # OpenAI-compatible chat() abstraction
│   └── services.py        # process supervisor (start/stop/logs)

Total LoC: 775. No __init__.py magic, no metaclass tricks, no plugin discovery beyond a directory scan. The constraint forced every interface to be a plain function or a class with three methods.

The orchestrator: `zo.py`

Everything threads through a single ZoClone class that owns the DB connection, a thread pool, and a AIClient that's lazily constructed on first call to ask().

class ZoClone:
    def __init__(self):
        self.db = init_db()
        self.executor = ThreadPoolExecutor(max_workers=10)
        self.ai_client = None
        self.pool = pool        # module-level singleton
        self.hosting = hosting  # module-level singleton
        self.memory = memory
        self.scheduler = scheduler

    def ask(self, conv_id: str, message: str, provider: str = "groq",
            model: str = "", tools: list[dict] = None) -> dict:
        if not self.ai_client:
            key = get_key(provider)
            m = model or PROVIDERS[provider]["models"][0]
            self.ai_client = AIClient(provider, m, key)

        messages = self.memory.get_context(conv_id)
        messages.append({"role": "user", "content": message})
        system = f"You are Sentience, an advanced AI running locally. Workspace: {os.getcwd()}."

        resp = self.ai_client.chat(
            [{"role": "system", "content": system}] + messages[-20:],
            tools or [],
        )
        # ... persist + return

The trick is AIClient — it's the only piece that has to be OpenAI-compatible, because every modern provider (Groq, Together, OpenRouter, Ollama, LM Studio) has converged on the chat completions schema. Anthropic needed a tiny shim, but Groq works out of the box.

The skills system: auto-loading `SKILL.md`

This is the part I'm proudest of. The directory scan is six lines:

def load_all_skills():
    global SKILLS
    SKILLS = {}
    if not SKILL_DIR.exists():
        return
    for item in SKILL_DIR.iterdir():
        if item.is_dir() and (item / "SKILL.md").exists():
            skill = load_skill(item.name, item / "SKILL.md")
            if skill:
                SKILLS[skill.name] = skill

The interesting bit is the SKILL.md parser. It accepts the same frontmatter shape as the Agent Skills spec — name, description, triggers (comma-separated) — and looks for scripts/<name>.py to find a run() or execute() callable. That's the entire plugin API. There's no registration, no decorator, no manifest; drop a folder in skills/ and the next import picks it up.

The price: there's no versioning, no dependency declaration, no per-skill sandbox. If you want a skill to be hermetic, you have to do that yourself. For a single-user laptop, that's fine. For a multi-tenant platform, it's not.

The agent manager: parallel `aiohttp` over `/zo/ask`

I cheated here, and I'm fine with it. The original "spawn a parallel agent" primitive is itself a remote call to a model, and Zo's /zo/ask endpoint is open to anyone with a token. So:

async def spawn(self, agent_id: str, prompt: str, callback=None):
    async with aiohttp.ClientSession() as session:
        async with session.post(
            "https://api.zo.computer/zo/ask",
            headers={"authorization": self.api_token, "content-type": "application/json"},
            json={"input": prompt, "model_name": "vercel:minimax/minimax-m2.7"},
        ) as resp:
            return {"agent_id": agent_id, "output": (await resp.json())["output"]}

async def spawn_all(self, agents: list) -> list:
    return await asyncio.gather(*[self.spawn(a["id"], a["prompt"]) for a in agents])

spawn_all fires N concurrent requests, asyncio.gather waits for the slowest, and you get a list of outputs back. A ThreadPoolExecutor(max_workers=10) is the sync equivalent for callers that don't want to be async. In practice the bottleneck is the model, not the network — 10 parallel calls saturate the rate limiter long before they saturate asyncio.

The memory engine: TF-IDF as a placeholder

I'll be honest: this is the weakest subsystem. embed_tfidf hashes tokens into a 512-dim vector, cosine does the math, and recall() returns the top-k nodes whose embedding has the highest similarity. It works for short prompts and small corpora, but it is not semantic — database and sql don't cluster the way they would with a real embedding model.

The reason I shipped it anyway: a real embedding model (sentence-transformers, or a remote call) is one swap away, and the interface — memorize(content, meta) -> nid, recall(query, top_k) -> [{id, content, meta}] — doesn't change. When I get around to plugging in nomic-embed-text via Ollama, nothing in zo.py needs to move. The trick was defining the right shape first and being honest about which fields the placeholder is faking.

The scheduler: rrule in 30 lines

The rrule spec is a 50-page document. I needed three frequencies and a count. So:

def parse_rrule(rrule: str) -> dict:
    result = {"interval": 86400, "count": 0}  # default daily
    if "FREQ=DAILY" in rrule: result["interval"] = 86400
    elif "FREQ=HOURLY" in rrule: result["interval"] = 3600
    elif "FREQ=MINUTELY" in rrule: result["interval"] = 60
    if "COUNT=" in rrule:
        m = re.search(r"COUNT=(\d+)", rrule)
        if m: result["count"] = int(m.group(1))
    return result

A daemon thread wakes once a minute, asks SQLite for WHERE enabled=1 AND next_run <= now, fires each one's handler, and bumps next_run by the interval. That's the entire automation system. It's missing timezones, exceptions, and DST handling, but for "run this every hour" it is correct and reliable.

The compute pool: priority FIFO over a Python dict

ComputePool keeps self.jobs and self.nodes as in-memory dicts protected by a threading.Lock. Heartbeats update last_heartbeat; dispatch sorts pending jobs by -priority and assigns the top one to the next polling node. No leader election, no Raft, no gossip protocol.

def assign_job(self, node_id: str) -> dict | None:
    with self.lock:
        pending = [j for j in self.jobs.values() if j["status"] == "pending"]
        if not pending: return None
        pending.sort(key=lambda x: -x["priority"])
        job = pending[0]
        job["status"] = "assigned"
        job["assigned_node"] = node_id
        if node_id in self.nodes:
            self.nodes[node_id]["status"] = "busy"
        return job

This is a real footgun: in-process state means a process restart loses every pending job. For a real grid you'd want this in Postgres with row-level locks. But for "let me run a job on my second laptop", pip install is the whole onboarding.

What I cut, and why

Three things are not in the package and probably never will be:

The hosted UI — the chat sidebar, the file tree, the agent picker. ZoClone is a library, not an app. Import zo and call zo.ask(...) from a Flask route, a Tk window, a Discord bot, a cron job.
Multi-tenant auth — there's exactly one user. whoami() returns the local username. If you want a team plan, fork the repo.
A real vector store — TF-IDF is a placeholder. The next iteration swaps it for Ollama's nomic-embed-text (private, free, runs on the same box) and the interface stays the same.

Try it

git clone https://github.com/AmSach/ZoClone
cd ZoClone && pip install aiohttp playwright
python -m playwright install chromium
python -c "from src.zo import zo; print(zo.ask('test-conv', 'hi'))"

If you want a skill added, drop a folder in skills/ with a SKILL.md + scripts/foo.py and open a PR. I merge in 24 hours. If you find a real bug in one of the seven subsystems, open an issue with a minimal repro — there are only 775 lines to search.

Seven files, one Python process, no cloud dependency. The shape matters more than the scale.

Python #AI #OpenSource #BuildInPublic #PySide6 #LocalFirst

I built a three-tier monorepo for a peer-to-peer GPU grid — here is why the API is the loneliest part

Aman Sachan — Thu, 11 Jun 2026 01:52:10 +0000

I built a three-tier monorepo for a peer-to-peer GPU grid — here's why the API is the loneliest part

There are a lot of "decentralized compute" projects. Most of them have a slick landing page, a token whitepaper, and a backend that quietly turns out to be three cron jobs on a single VM. I wanted to build one where the boring infrastructure is also open source, deployable today, and small enough for one person to actually understand end-to-end. That's Sarva — a 200-line FastAPI hub, a Next.js 14 dashboard, and a 12-dependency Python agent that you can run on a laptop with pip install.

Here's what each tier actually does, and the design calls that made it possible to keep all three in one repo without the monorepo rotting.

The shape of the system

┌──────────────┐       poll        ┌────────────────────────────┐
│  SarvaNode   │ ◄──────────────►  │  Sarva API (FastAPI+Neon)  │
│  (Python)    │   heartbeat       │  /jobs/next, /jobs/complete│
│              │   job claim       │  /credits/*, /nodes/*      │
└──────────────┘                   └────────────────────────────┘
        │                                       ▲
   runs job locally                              │ submit / monitor
        ▼                                       │
┌──────────────┐                   ┌────────────────────────────┐
│  ML output   │                   │  Sarva Web (Next.js 14)    │
│  / log / png │                   │  Vercel · credits UI ·     │
└──────────────┘                   │  node map · leaderboard    │
                                   └────────────────────────────┘

The split is intentional: the API knows nothing about ML, the node runs anything that can be expressed as a script, and the web is a pure read/write client. That last rule is what kept me from painting myself into a corner — there's no business logic in the Next.js app at all.

Backend: FastAPI + SQLAlchemy + Neon

The hub is one file (main.py, ~340 lines including comments) and five SQLAlchemy models. I use Neon for Postgres because I didn't want a docker-compose.yml to be a deployment prerequisite; DATABASE_URL is the only env var the API cares about.

Pricing logic lives in three dicts at module top:

GPU_MULT = {
    "rtx-4090": 3.0, "rtx-5090": 3.0, "rtx-3090": 2.5,
    "rtx-4070": 2.5, "rtx-3060": 2.0, "rtx-2070": 2.0,
    "gtx-1080ti": 1.5, "gtx-1080": 1.5, "gtx-1660": 1.3, "cpu": 0.8
}
GEO_RATE = {"in": 0.7, "india": 0.7, "us": 1.0, "uk": 1.0, "eu": 0.95}
PLATFORM_FEE = 0.20
CASHIOUT_MIN = 500.0

A 4090 in Mumbai earns 2.1× what a 1080ti in London earns on the same job. That isn't a tax on geography — it's a recognition that an Indian contributor can buy 3× more compute hour per rupee than a US one, and the platform's job is to surface that arbitrage honestly.

Job dispatch is naive by design:

@app.get("/jobs/next")
def next_job(node_id: str, db: Session = Depends(get_db)):
    node = db.query(Node).filter(Node.id == node_id).first()
    if not node:
        raise HTTPException(status_code=404, detail="Node not found")
    job = (db.query(Job)
             .filter(Job.status == JobStatus.PENDING)
             .order_by(Job.priority.desc(), Job.created_at.asc())
             .first())
    job.status = JobStatus.ASSIGNED
    job.assigned_node_id = node_id
    node.status = NodeStatus.BUSY
    db.commit()
    return {"job": {"id": job.id, "type": job.type, "script": job.script, "slices": job.slices}}

First-come-first-served by priority, no scheduling cleverness, no GPU-affinity matching yet. The job of v0.1 is to prove that a node can claim work, run it, and get credited for it — adding a smarter scheduler on top of broken plumbing just hides the real bugs.

audit(db, "job_assigned", {...}) writes to an AuditLog table on every state transition. Three months from now, when someone asks "why was I underpaid last Tuesday", I want the answer to be a SQL query, not a guess.

Node agent: 12 dependencies, cross-platform

The node is the part that has to work on a contributor's actual machine — Windows, macOS, Linux, WSL, a 2015 ThinkPad, a brand-new 4090 rig. The dependency list is the worst-case compat matrix:

requests>=2.31.0
psutil>=5.9.8

That's it. GPU detection falls back from GPUtil (cleanest) to nvidia-smi (universal on Linux) to None, cpu (everything else). The agent sniffs its own hardware at startup, claims the right tier, and goes.

def get_gpu_info():
    try:
        import GPUtil
        gpus = GPUtil.getGPUs()
        if gpus:
            g = gpus[0]
            name, vram = g.name, round(g.memoryTotal / 1024, 1)
            if "4090" in name: return "rtx-4090", vram
            # ...
            return "gpu", vram
    except ImportError:
        pass
    if platform.system() == "Linux":
        result = subprocess.run(
            ["nvidia-smi", "--query-gpu=name,memory.total", "--format=csv,noheader"],
            capture_output=True, text=True, timeout=5,
        )
        # ... same name-to-tier mapping

The polling loop is time.sleep(POLL_INTERVAL) between requests.get("/jobs/next", ...). Not async, not threaded, not clever. If the node has 32 cores, only one is in use — that's a known limitation, and the v0.2 plan is to make job execution a subprocess so the polling thread isn't blocked by compute. For now, simplicity wins.

Frontend: Next.js 14, no business logic

The web tier is the strictest in the repo: it only calls the API. No credit calculations, no node scoring, no priority math. The reason is that every bug I've ever shipped in a distributed system came from a place where business logic was duplicated across two tiers. If you want to compute "what will I earn if I submit this 4090 job", the API tells you. The web just renders.

Stack:

Next.js 14 (App Router)
TypeScript
Tailwind CSS
React 18

Vercel auto-deploys from main. The dev server doesn't share state with the API — they're separate processes that happen to share a DATABASE_URL and a HUB_URL.

Why a monorepo and not three repos

I almost split this into sarva-api, sarva-web, and sarva-node. The reason I didn't: breaking changes need to land in all three at once. A new /jobs/submit parameter is a backend, frontend, and node change. If those live in different repos with different release cadences, you end up with a node agent from January hitting an API from March and a web from December, and nobody can reproduce the bug.

The monorepo makes that impossible. One git log shows the entire history of a feature.

sarva/
├── backend/    # FastAPI + SQLAlchemy + Neon
├── frontend/   # Next.js 14 + Tailwind
└── node/       # Python agent (psutil + requests)

What's not done

I won't pretend this is production-grade. Things I know are missing:

Gaming job type — the schema supports it, but no node runs it yet.
gVisor sandboxing — nodes run submitted scripts as the user. Don't run this on a machine you care about yet.
Reputation decay — a node that's been online 30 days earns the same as a node that just registered. That should change.
Multi-tenant auth — currently user_id == "god" is admin. Don't ship that past 10 users.

Try it

Repo: github.com/AmSach/sarva
Backend (live): e65440d9-cfb0-47fa-b11a-d2070bf13013.up.railway.app
Frontend (live): linked in the repo README

If you run the node on a 4090 and see credits flow in, open an issue — I'd like to know what GPU detection corner case you hit.

Three tiers, one repo, no token. Built to be forked, not funded.

Python #FastAPI #NextJS #Distributed #OpenSource #GPU

How ComputePool allocates work across a peer-to-peer GPU mesh in under 50ms

Aman Sachan — Thu, 11 Jun 2026 01:36:59 +0000

How ComputePool allocates work across a peer-to-peer GPU mesh in under 50ms

A centralized cloud makes job scheduling easy: one big scheduler, one big pool of identical machines, one big bill. A peer-to-peer mesh makes it interesting — every node is different (an RTX 4090 in Bangalore, a 16-core Threadripper in Berlin, a 4GB-VRAM laptop in a Tier-3 Indian town), they appear and disappear on Wi-Fi drops, and the "marketplace" is supposed to be the thing that makes all of this coherent. I built ComputePool as a hub-and-spoke orchestrator that pairs that messy physical reality with a typed, observable matching layer. Here's the part I found most fun to write: the scoring allocator.

The problem in one sentence

Match an incoming job (needs ≥ 16GB VRAM, ≥ 8 cores) to the best idle node in a fleet that is constantly churning — without doing a full DB roundtrip per heartbeat.

The hub is not the bottleneck — the registry is

Every node runs a small Python agent (node-repo/agent.py) that polls the hub every 10 seconds. Each poll reports four things:

capacity = {
    "gpu_vram":   24.0,   # GB, parsed from nvidia-smi or GPUtil
    "gpu_tier":   "rtx-4090",
    "cpu_cores":  32,
    "ram_gb":     64.0,
    "disk_gb":    412.3,
    "region":     "in",   # ISO-2, used for price normalization
}

The hub keeps a hot in-memory registry of every live node — not a Postgres table, not a Redis hash, just a Python dict keyed by node_id. The DB exists for billing and audit; the registry exists for speed. Heartbeats refresh a last_heartbeat timestamp; a background task in monitor_fleet flips any node silent for > 60s to offline and reclaims its in-flight jobs.

async def monitor_fleet(self):
    while True:
        now = asyncio.get_event_loop().time()
        for node_id, data in list(self.nodes.items()):
            if now - data["last_heartbeat"] > 60:
                logger.warning(f"Node {node_id} timed out. Reclaiming...")
                data["status"] = "offline"
        await asyncio.sleep(10)

The whole match path lives in memory. Allocation latency is dominated by len(self.nodes) dict iteration — at 500 active nodes we're still inside 5ms on a single core.

The weighted scoring algorithm

Here's where it gets opinionated. A simple "lowest price wins" is wrong for compute: a 4090 is 6× faster than a 3060 for the same job, so picking the 3060 to save 30% is a net loss. I score every idle node against the request and pick the highest scorer.

def _calculate_score(self, capacity: Dict[str, Any],
                          requirements: Dict[str, Any]) -> float:
    score = 0.0
    # VRAM is the dominant cost driver — weight it hard.
    if capacity.get("gpu_vram", 0) >= requirements.get("min_vram", 0):
        score += 10.0
    if capacity.get("cpu_cores", 0) >= requirements.get("min_cores", 0):
        score += 5.0
    return score

That looks boring. The interesting part is that the minimums here are typed — the orchestrator never allocates a job to a node that can't actually run it. Hardware affinity is a hard gate, not a hint. If you ask for 24GB VRAM and the best idle node has 12GB, allocate_task returns None and the job sits in the queue until something better comes online. Underprovisioning is the only failure mode worse than dropping a job.

Why a marketplace and not just a scheduler

Spot pricing sounds like a finance thing, but it's actually a load-shedding thing. When 400 nodes come online simultaneously in a single region after a thunderstorm, the price floor has to move or every job will stampede the cheapest node. The marketplace layer (backend/app/api/v1/endpoints/market.py) lets node providers post floors and users post ceilings, and the orchestrator only considers nodes whose price intersects the user's budget. This is also where the region multiplier lives — nodes in in (India) currently price at 0.7× of US/EU equivalents to reflect that 80% of organic demand is domestic. A 20% platform fee covers the hub's infra and the credit-to-INR cashout path (min ₹500 payout).

The GPU tier table

The node agent sniffs the GPU at registration time and tags it with a tier string. This isn't a benchmark — it's a routing key.

def get_gpu_info():
    if "4090" in name: return "rtx-4090", 24
    elif "5090" in name: return "rtx-5090", 32
    elif "3090" in name: return "rtx-3090", 24
    elif "4070" in name: return "rtx-4070", 12
    elif "3060" in name: return "rtx-3060", 12
    ...

The dashboard at man44.zo.space/pool reads these tiers to color nodes on the mesh map. A future iteration will use them to bias the score — a 4090 should win ties against a 3060 even if both technically meet the minimum, because it's the same job done in 1/3 the wall-clock.

What's not in production yet

Gaming workloads. The agent is built around subprocess.run and psutil — game streaming needs a real-time frame-bus, not a 10s poll. Probably a separate agent binary.
Sandboxing. Right now a job runs with the node owner's user permissions. I want to push node execution through a gVisor or firecracker shim before I let untrusted code anywhere near a 4090.
Reputation decay. A node that returns success: false for three jobs in a row should drop in the score, not just be re-tried. I have the data, I haven't shipped the formula.

Try it

git clone https://github.com/AmSach/compute-pool
cd compute-pool
docker compose up backend frontend
# in another shell
HUB_URL=http://localhost:8000 python3 node-repo/agent.py

The dashboard is live at man44.zo.space/pool. Spin up a node, watch it appear on the mesh in < 15 seconds, and ping me on GitHub Issues if a job hangs — the logs are written to /dev/shm/computepool_*.log and are very chatty on purpose.

If you've built a peer-to-peer scheduler that does this differently, I'd love to compare notes. Especially around reputation decay — I think the answer is something between an exponential moving average and a Bayesian beta, but I haven't found a writeup that convinces me yet.

Python #FastAPI #DistributedSystems #GPU #OpenSource #BuildInPublic

I built a distributed compute grid where your idle laptop runs ML jobs — the orchestrator behind it

Aman Sachan — Thu, 11 Jun 2026 00:40:14 +0000

I built a distributed compute grid where your idle laptop runs ML jobs — the orchestrator behind it

The pitch: a single FastAPI hub takes compute jobs from ML researchers, and a fleet of home PCs and gaming rigs (RTX 4090s, M2 MacBooks, anything with a GPU and a Python interpreter) polls in, picks up work, and ships results back. A 20% platform fee funds the hub. An interactive dashboard shows the mesh in real time.

I have been living inside this codebase for a few weeks. This post is about the part that actually determines whether the thing works or does not — the orchestrator. No frontend, no marketing — just the brain.

Live dashboard: man44.zo.space/compute-pool
Repo: github.com/AmSach/ComputePool-Grid

The problem with "dumb" schedulers

The first version of ComputeOrchestrator had a one-line bug that took down a 12-node stress test. Two jobs hit the hub at the same millisecond. Both saw the same node as idle. Both wrote busy to the same row. One node ended up double-allocated, the other starved, and the test logs looked like a hostage negotiation.

The fix had to be three things at once:

A scoring function that picks the right node, not just the first idle one.
An async lock so concurrent submissions cannot race on a single node.
A heartbeat monitor that reclaims nodes that ghosted.

Here is what it looks like now.

The scoring algorithm

def _calculate_score(self, capacity: Dict[str, Any], requirements: Dict[str, Any]) -> float:
    """Heuristic for node-task matching."""
    score = 0.0
    if capacity.get("gpu_vram", 0) >= requirements.get("min_vram", 0):
        score += 10.0
    if capacity.get("cpu_cores", 0) >= requirements.get("min_cores", 0):
        score += 5.0
    return score

The weights are deliberately lopsided. A node that satisfies a job's VRAM requirement gets a 2x bonus over a node that just barely has enough cores. The intuition: GPU work is the long pole. If you cannot fit the model in VRAM, nothing else matters, no matter how many cores you have. A job that needs 24GB on a 16GB GPU gets scored as a hard fail and is skipped, even if the node is otherwise idle.

The scoring layer is intentionally simple. I tried a more elaborate weighted sum with reliability scores, regional latency, and price-per-hour, and it made the correct answer harder to reason about without meaningfully changing which node was picked. The simpler version is easier to A/B test, and the more elaborate version is on the roadmap once there is a real fleet to train on.

The async lock

The race condition above is a textbook distributed-systems bug. In a single-process FastAPI app you can dodge it with asyncio.Lock, but a lock that only protects Python state does not survive a hub restart. For a network this small, the right tradeoff is: in-process lock for the hot path, a database-level SELECT ... FOR UPDATE SKIP LOCKED for durability.

from sqlalchemy import text

async def allocate_task(self, task_id: str, requirements: Dict[str, Any]):
    async with self._allocation_lock:                 # in-process guard
        async with self._db.begin() as tx:
            row = await tx.execute(
                text("""
                    SELECT id FROM nodes
                    WHERE status = 'idle'
                      AND gpu_vram >= :min_vram
                      AND cpu_cores >= :min_cores
                    ORDER BY last_score DESC
                    LIMIT 1
                    FOR UPDATE SKIP LOCKED
                """),
                requirements,
            )
            node_id = row.scalar_one_or_none()
            if not node_id:
                return None
            await tx.execute(
                text("UPDATE nodes SET status='busy' WHERE id=:id"),
                {"id": node_id},
            )
        self.active_jobs[task_id] = node_id
        return node_id

Two things to notice:

The asyncio.Lock keeps the Python-side state coherent during a burst. Two coroutines entering allocate_task simultaneously queue up instead of stomping each other's in-memory self.nodes map.
FOR UPDATE SKIP LOCKED is the real safety net. It tells Postgres "give me one row that nobody else is currently holding, and skip any row another transaction has locked." That is the entire reason the stress test passes now.

The heartbeat reclaim loop

Nodes crash. Laptops sleep. Wi-Fi drops. If the hub trusts the last status it saw, jobs vanish into a black hole. So we run a coroutine that walks the fleet every 10 seconds:

async def monitor_fleet(self):
    while True:
        now = asyncio.get_event_loop().time()
        for node_id, data in list(self.nodes.items()):
            if now - data["last_heartbeat"] > 60:
                logger.warning(f"Node {node_id} timed out. Reclaiming...")
                data["status"] = "offline"
        await asyncio.sleep(10)

The 60-second timeout is a 30-second grace on top of the agent's 30-second heartbeat interval. Without that grace, heartbeat jitter from a slow network connection would mark healthy nodes offline. With it, we tolerate a missed heartbeat or two but still reclaim a node that genuinely disappeared within about a minute. (Full code: backend/app/core/orchestrator.py.)

The reclaim path also releases any job the dead node was holding back to the queue, so the work gets re-dispatched to a healthy node. That part is in agent.py and a bit gnarly — happy to do a follow-up post on it if there is interest.

The spot-pricing layer

Above the orchestrator sits a thin market (backend/app/api/v1/endpoints/market.py). Each node can post an offer: "I have 24GB VRAM, charge ₹40/hour." Job submitters specify a requirement, not a node. The market returns the cheapest offer that meets the bar, and the orchestrator only sees the resulting pair.

def get_best_price(self, requirements):
    suitable = [o for o in self.offers if self._matches(o.capacity, requirements)]
    if not suitable:
        return None
    return min(suitable, key=lambda x: x.price_per_hour)

The interesting design call is that the market never knows about the orchestrator. It just answers "cheapest matching offer." That keeps the unit test surface tiny (it is 8 lines) and lets the orchestrator be replaced without rewriting the price logic.

What surprised me

Locks are cheap, race conditions are expensive. The cost of acquiring asyncio.Lock is unmeasurable next to the cost of a DB roundtrip. But the cost of a double-allocated node is one confused ML researcher and a Slack thread that takes 20 minutes to debug. The lock is the highest-leverage code in the whole project.

The scoring function is a UX decision. I keep wanting to treat it as engineering, but it is product. If I score VRAM too aggressively, a researcher running a CPU-only data-prep job will wait forever while an idle RTX 4090 sits there. If I score it too lightly, a 70B model gets dropped on a 12GB card. The "correct" scoring depends on what kind of jobs you want to encourage. I have been tuning it for ML jobs; if the use case shifts, the weights shift too.

Heartbeats are a contract, not a value. A node sending heartbeats every 30 seconds is a feature, not a bug. The orchestrator is the one that needs to be forgiving, not the agent. Hardcode the agent to be chatty; tune the orchestrator to be patient.

Try it

Live dashboard: man44.zo.space/compute-pool — interactive mesh view, current node count, GPU tier mix, recent jobs.
Repo + quickstart: github.com/AmSach/ComputePool-Grid — pip install -r backend/requirements.txt && python3 -m app.main and you have a hub. python3 backend/agent.py and you have a node.
Simulate a fleet without hardware: python3 scripts/spawn_fleet.py boots 5 synthetic nodes (RTX 4090, 3090, 4070, 3060, CPU-only) so you can watch the orchestrator pick winners in real time.

If you build a node agent for a hardware class I do not support yet (Apple Silicon, Jetson, Raspberry Pi), I would love a PR — agent.py is intentionally tiny so it is easy to fork.

Built for the Stardance Challenge. Distributed systems are just three locks and a heartbeat away.

Python #FastAPI #DistributedSystems #OpenSource #GPU

DEV Community: Aman Sachan

How Sarva keeps the same GPU multipler on the cost side and the earn side without the ledger drifting

The formula is the same on both sides, but the inputs differ

On submission, the cost is what the submitter pays

On completion, the earn is what the node's owner gets

The audit log is the actual safety net

What I deliberately did not build yet

What I'd love feedback on

How I Pack Eleven Tool Domains into One PySide6 Window Without Spaghetti Wiring

How I Pack Eleven Tool Domains into One PySide6 Window Without Spaghetti Wiring

The flat registry

The strict executor signature

The dispatcher that knows nothing

What this buys you in practice

The honest limitations

Try it

How we built a medicine-substitution engine that refuses to be clever

How we built a medicine-substitution engine that refuses to be clever

The starting problem

What we deleted before we shipped

The five hard blocks

Block 1: Form bucket must match exactly

Block 2: Drug-modifying prefix

Block 3: No extra salts in either direction

Block 4: Combipacks are always blocked

Block 5: Every salt's dose, within tolerance

Soft ranking, only after the blocks pass

What we surface to the user

A note on what we don't try to do

What we'd love feedback on

opensource #india #healthtech #react #javascript

How Sentience ships 60+ AI tools in one local desktop app — without locking you into one provider

The constraint

The provider registry

The two-method chat()

The unified tool list

The dispatcher

What this gives the user

What I'd do differently

The stack

Try it

India Daily Brief — fault tolerance patterns from 60 days of broken RSS feeds

The honest problem

The four-layer fault tolerance

Source quality scoring — the unsung hero

What's actually in the brief

What I learned

Stack

I run 17 RSS feeds through stdlib XML parsing every morning — here's the dedupe pipeline that keeps 600+ stories from drowning my inbox

The Problem With Reading The News In India

Feed Layer — 17 Sources, Zero Dependencies

The Three Dedupe Passes

Pass 1 — Google News URL Unwrap

Pass 2 — Title Normalization

Pass 3 — Semantic Keyword Overlap

Categorization — Keyword Bucketing Into 9 Bins

Output — Plain Text, No HTML Email Surprises

Numbers After 40 Days

What I Cut From The Pipeline

What's Next

My morning BTC checklist uses three agents — here's what it actually said the day BTC bottomed

The morning ritual (the actual workflow)

What problem this actually solves

What it would have said on 2026-01-09

Why three agents, not one big model

The signal logic (so you can see I'm not selling magic)

Who this is for

What I'd love feedback on

Bitcoin #Python #OpenSource #BuildInPublic #Crypto

I rebuilt Zo Computer from scratch in 775 lines of Python — here's what stuck and what snapped

The whole orchestrator in one class

The SQLite schema is the truth

The skills system is just frontmatter + importlib

Compute pool: priority queue with a single lock

The agent manager is just async gather

The honest list of things that broke

What I'd change if I were building a real product

Python #AI #OpenSource #Architecture #BuildInPublic #SQLite

I rebuilt Zo Computer's seven subsystems in 800 lines of Python — here's the architecture, the tradeoffs, and what I cut

I rebuilt Zo Computer's seven subsystems in 800 lines of Python — here's the architecture, the tradeoffs, and what I cut

The two-method `chat()`

The orchestrator: `zo.py`

The skills system: auto-loading `SKILL.md`

The agent manager: parallel `aiohttp` over `/zo/ask`