DEV Community: opensource

My Hacktoberfest 2026 Journey: Getting Started with Open Source

Ayush Aryan — Tue, 13 Oct 2026 20:03:59 +0000

My Hacktoberfest 2026 Journey: Getting Started with Open Source

Hey everyone!

I'm a Computer Science undergraduate at IIIT Lucknow, and I've been spending time learning programming, solving DSA problems, and building projects.

Now, I want to take the next step by contributing to open source.

Hacktoberfest feels like a good opportunity to explore real-world projects, understand how developers collaborate, and learn how software is built beyond personal projects and tutorials.

What I Want to Learn

Here are a few things I want to focus on during this journey:

Exploring open-source repositories and understanding their codebases.
Finding issues where I can make meaningful contributions.
Improving my Git and GitHub workflow, especially branches and pull requests.
Learning how to read existing code and debug unfamiliar projects.
Connecting with developers and learning from their experiences.

Technologies I'm Interested In

My current interests include:

C++ and Data Structures & Algorithms
React and Next.js
Web Development
Web3 and Blockchain Development
AI-powered applications

I'm happy to explore projects outside these areas if they offer an opportunity to learn something new.

Looking for Recommendations

Since I'm getting more involved in open source, I'd appreciate recommendations for repositories that welcome new contributors.

I'd love to hear about your experiences and learn from the community.

My goal is to make genuine contributions, improve my development skills, and become more comfortable working on collaborative projects.

Looking forward to seeing what I can learn along the way.

hacktoberfest #opensource #beginners

New stricter rules from GitHub for code packages after security investigation

Hacks.gr — Tue, 13 Oct 2026 20:01:21 +0000

GitHub has added a 48-hour expiration window for unvalidated npm trusted publishing configurations, closing a supply chain loophole that allowed attackers to claim abandoned repository slugs and publish package updates without credentials.

The issue was discovered by security firm Bloom Security, which notified GitHub on June 6, 2026. According to the researchers, the vulnerability arose from the way the platform identified which code repository belonged to whom. Specifically, the system relied on the name of the address rather than a permanent digital identifier.

This meant that if an address name was left blank, a skilled attacker could figure it out. In this way, they could gain the trust of the system and publish malicious changes to software they did not own, taking advantage of the reputation and downloads of the original package. The research identified more than 1.500 vulnerable packages that had been downloaded a total of over 10 million times.

What's changing in software publishing

To address this issue, GitHub has decided that trust settings that have not been validated with a successful publish will now automatically expire within 48 hours of their creation. Each setting becomes permanent once the first publish is successfully completed, while if the project identity changes, a new process is required with a new 48-hour window.

Additionally, npm rejects requests originating from certain automated code comment and request processes.

What should creators do?

Software creators who manage packages are asked to:

check the settings of trusted connections,
delete and recreate links if repositories are renamed or moved,
monitor for any unexpected posts.

Read the original English article on Hacks.gr

Argon2id Security for Self-Hosted AI Wallets: CLI Master Password Best Practices

Wallet Guy — Tue, 13 Oct 2026 19:51:21 +0000

Argon2id Security for Self-Hosted AI Wallets: CLI Master Password Best Practices

Self-hosted AI wallets live or die by one question: who controls the master password? If you're running WAIaaS on your own server, you've already made the right call by keeping your AI agent's private keys off someone else's infrastructure — but that decision only pays off if the password protecting those keys is treated with the same seriousness as the keys themselves. This post walks through exactly how WAIaaS handles master password security and what you should do to harden it from day one.

Why the Master Password Is the Root of Everything

In a self-hosted wallet setup, the master password isn't just an admin credential — it's the cryptographic root from which everything else derives. WAIaaS uses Argon2id to protect it, which is the current best-practice algorithm for password hashing. Argon2id is memory-hard, meaning brute-force attacks are expensive in both time and RAM, not just CPU cycles. That matters enormously when your wallet is internet-accessible, even behind a VPN.

The master password gates the masterAuth layer — one of three distinct authentication methods in WAIaaS:

masterAuth (Argon2id) — system administrator: creates wallets, manages sessions, sets policies
ownerAuth (SIWS/SIWE) — fund owner: approves transactions, uses the kill switch
sessionAuth (JWT HS256) — AI agents: executes transactions within policy bounds

Your AI agent never touches the master password. It operates on short-lived session tokens. The master password is only needed for administrative operations: provisioning wallets, setting policies, and creating those session tokens. That separation is intentional and important. Compromise a session token and an attacker is bounded by your policies. Compromise the master password and it's a different conversation entirely.

The Auto-Provision Path: Getting Started Without Foot Guns

If you're spinning up WAIaaS for the first time, the --auto-provision flag is your friend. It generates a cryptographically random master password on first start and writes it to a recovery file, so you don't have to invent a password under pressure during setup.

npm install -g @waiaas/cli
waiaas init --auto-provision     # Generates random master password → recovery.key
waiaas start                     # No password prompt
waiaas quickset                  # Creates wallets + sessions automatically
waiaas set-master                # (Later) Harden password, then delete recovery.key

That last step — waiaas set-master — is critical and easy to skip. The auto-generated password in recovery.key is strong, but it's sitting on disk in plaintext. Your hardening checklist after initial setup should be:

Run waiaas set-master to replace the auto-generated password with one you've chosen and can store in a proper secret manager
Verify the new password works by running a test command (e.g., waiaas status)
Delete recovery.key from disk
Store the new password in a password manager or hardware-backed secret store — never in a .env file committed to version control

The same pattern applies to Docker deployments. Auto-provision works identically:

docker run -d \
  --name waiaas \
  -p 127.0.0.1:3100:3100 \
  -v waiaas-data:/data \
  -e WAIAAS_AUTO_PROVISION=true \
  ghcr.io/waiaas/waiaas:latest

# Retrieve auto-generated master password
docker exec waiaas cat /data/recovery.key

After retrieving that key, treat it like a root SSH key: copy it somewhere safe, then replace it.

Docker Secrets: The Production-Grade Approach

Environment variables are convenient but they leak. They show up in docker inspect, in process tables, in container logs if you're not careful. For a self-hosted setup that you're actually going to trust with real funds, Docker Secrets is the right tool.

WAIaaS's Docker entrypoint supports Docker Secrets natively, and there's a dedicated docker-compose.secrets.yml overlay for production deployments. The workflow looks like this:

# Create secret files
mkdir -p secrets
echo "your-secure-password" > secrets/master_password.txt
chmod 600 secrets/master_password.txt

# Deploy with secrets overlay
docker compose -f docker-compose.yml -f docker-compose.secrets.yml up -d

The 600 permissions on the secrets file matter. It means only the owning user can read it — not other users on the same system, not processes running as different UIDs. The WAIaaS Docker image itself runs as UID 1001 (non-root), which means even if something inside the container misbehaves, it can't escalate to root to read files it shouldn't.

The base Docker Compose configuration for reference:

services:
  daemon:
    image: ghcr.io/waiaas/waiaas:latest
    container_name: waiaas-daemon
    ports:
      - "127.0.0.1:3100:3100"
    volumes:
      - waiaas-data:/data
    environment:
      - WAIAAS_DATA_DIR=/data
      - WAIAAS_DAEMON_HOSTNAME=0.0.0.0
    env_file:
      - path: .env
        required: false
    restart: unless-stopped
    healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost:3100/health"]
      interval: 30s
      timeout: 5s
      start_period: 10s
      retries: 3

volumes:
  waiaas-data:
    driver: local

Notice the port binding: 127.0.0.1:3100:3100. That's loopback-only by default, which means the API is not exposed to your network unless you explicitly make it so. If you need remote access, put a reverse proxy with TLS in front of it rather than changing the bind address to 0.0.0.0 directly.

What masterAuth Actually Protects

It helps to be concrete about what operations require the master password, because that scope defines your threat model.

# Create a wallet (masterAuth)
curl -X POST http://127.0.0.1:3100/v1/wallets \
  -H "Content-Type: application/json" \
  -H "X-Master-Password: my-secret-password" \
  -d '{"name": "trading-wallet", "chain": "solana", "environment": "mainnet"}'

# Create a session for AI agent (masterAuth)
curl -X POST http://127.0.0.1:3100/v1/sessions \
  -H "Content-Type: application/json" \
  -H "X-Master-Password: my-secret-password" \
  -d '{"walletId": "<wallet-uuid>"}'

# Create policy (masterAuth)
curl -X POST http://127.0.0.1:3100/v1/policies \
  -H "Content-Type: application/json" \
  -H "X-Master-Password: my-secret-password" \
  -d '{
    "walletId": "<wallet-uuid>",
    "type": "SPENDING_LIMIT",
    "rules": {
      "instant_max_usd": 100,
      "notify_max_usd": 500,
      "delay_max_usd": 2000,
      "delay_seconds": 900,
      "daily_limit_usd": 5000
    }
  }'

Once wallets, sessions, and policies are set up, your AI agent operates entirely on its session token. The master password doesn't appear in any agent workflow. This is by design — you do your administrative work, lock down the master password in your secret manager, and your agent runs without ever needing it.

The session token gets passed as a standard Bearer token:

# Check wallet balance (sessionAuth)
curl http://127.0.0.1:3100/v1/wallet/balance \
  -H "Authorization: Bearer wai_sess_eyJhbGciOiJIUzI1NiJ9..."

That session token has its own security properties: per-session TTL, maxRenewals, and absoluteLifetime controls. If a session token is compromised, you revoke it without touching the master password. The blast radius is bounded.

Policy as Defense-in-Depth

Even with a strong master password and properly isolated session tokens, you want policies acting as a backstop. WAIaaS has a policy engine with 21 policy types and a default-deny stance — transactions are blocked unless explicitly allowed.

The most important policy to set early is SPENDING_LIMIT, which maps to the four security tiers:

INSTANT — execute immediately
NOTIFY — execute immediately, send notification
DELAY — queue for N seconds, then execute (cancellable window)
APPROVAL — require human approval via WalletConnect or Telegram

For a self-hosted setup where you're the only operator, you might start conservative:

curl -X POST http://127.0.0.1:3100/v1/policies \
  -H "Content-Type: application/json" \
  -H "X-Master-Password: my-secret-password" \
  -d '{
    "walletId": "<wallet-uuid>",
    "type": "SPENDING_LIMIT",
    "rules": {
      "instant_max_usd": 100,
      "notify_max_usd": 500,
      "delay_max_usd": 2000,
      "delay_seconds": 900,
      "daily_limit_usd": 5000
    }
  }'

With these rules, anything under $100 executes immediately. $100-$500 executes but you get notified. $500-$2,000 sits in a queue for 15 minutes — you can cancel it. Above $2,000, your agent can't proceed without you explicitly approving it via WalletConnect or a signing channel. That's a meaningful safety net even if a session token were somehow misused.

You can also dry-run any transaction before it touches the network, which is useful during setup to verify your policies are behaving as expected:

curl -X POST http://127.0.0.1:3100/v1/transactions/send \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer wai_sess_<token>" \
  -d '{
    "type": "TRANSFER",
    "to": "recipient-address",
    "amount": "0.1",
    "dryRun": true
  }'

The Self-Hosted Philosophy in Practice

Running your own wallet infrastructure is the crypto equivalent of hosting your own email server, but WAIaaS makes it genuinely practical rather than a weekend project that never quite works. One Docker command gets you a daemon with:

Argon2id master password hashing
Non-root container execution (UID 1001)
Docker Secrets support
Health checks
Loopback-only port binding by default
Named volume data persistence

git clone https://github.com/waiaas/WAIaaS.git
cd WAIaaS
docker compose up -d

You own the data directory. You own the keys. There's no hosted service receiving your transaction history, no third-party API key required to make basic wallet operations work. The tradeoff is that you're responsible for your own backups (WAIaaS has backup create, backup list, and restore CLI commands for this) and your own uptime. For most self-hosters on community forums like r/selfhosted and r/homelab, that tradeoff is exactly the point.

Quick Hardening Checklist

If you're setting up WAIaaS today, here's the condensed version:

Use auto-provision first, then immediately run waiaas set-master to replace the generated password with one stored in your password manager
Delete recovery.key after confirming your new password works
Use Docker Secrets (docker-compose.secrets.yml) rather than passing the master password as an environment variable in production
Keep the port binding loopback-only (127.0.0.1:3100:3100) and put TLS in front via a reverse proxy if you need remote access
Set a SPENDING_LIMIT policy before your agent starts executing transactions — default-deny means your agent can't do anything without explicit permission anyway, but limits give you a time window to react if something goes wrong
Create session tokens with appropriate TTLs using waiaas set-master to configure session lifetime parameters — a session token with a short TTL limits exposure windows

The CLI gives you 20 commands covering the full lifecycle from init through backup and restore. The status and wallet info commands are useful for verifying your setup is in the state you think it's in before you hand session tokens to an agent.

What's Next

The security model described here — Argon2id master auth, session-scoped agent tokens, policy-gated transactions — is the foundation everything else in WAIaaS builds on. Once you have a hardened self-hosted instance running, the natural next steps are connecting it to your AI agent via MCP or the TypeScript/Python SDKs, and configuring DeFi policies for the specific protocols your agent will interact with.

If you want to dig into the full setup or read the source, everything is at https://github.com/waiaas/WAIaaS. The project site with documentation is at https://waiaas.ai. No hosted service required — you've got the keys.

ProofCheck: checking UPI payment screenshots against the bank statement, on your own laptop

TEJAS _ — Tue, 13 Oct 2026 19:49:49 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 2: Side Hustle

What I Built

If you've ever paid a tuition fee, a society maintenance bill or a home baker in India, you know how it goes. You pay by UPI, take a screenshot, send it on WhatsApp. Done.

Now think about the person on the other end. A tuition teacher with 40 students gets 40 screenshots a month, at random times, buried in the rest of her WhatsApp. At some point she sits down with her bank statement and ticks them off one by one, reading 12-digit reference numbers off a phone screen.

And she can't fully trust any of them. A screenshot is just a picture. It can be edited. It can be of a payment that failed. It can be last month's screenshot sent again. Fake payment screenshots are a common enough scam that banks and payment companies keep publishing guides telling shopkeepers to check their account, not the screenshot.

That check is the whole tool. ProofCheck takes a folder of payment screenshots and a bank statement export, reads the UPI reference number (the UTR) off each screenshot, and looks for it in the statement. Every screenshot ends up as one of these:

Result	What it means
Verified	The UTR is in the statement and the amount matches. The money came in.
Amount differs	The UTR is there, but the screenshot shows a different amount.
Not in statement	No such UTR. Could be fake, could be a payment that hasn't settled yet.
Duplicate	Another screenshot already used this UTR.
Outside dates	The screenshot is dated after the statement ends. Check a newer statement.
Unreadable	Couldn't find a UTR. You'll have to look at this one yourself.

You'll notice it never says "fake". I went back and forth on that. A missing UTR is suspicious, but a payment made an hour ago is missing too, and accusing a parent of fraud over a settlement delay is a good way to lose a student.

Give it a small roster as well (who owes how much, and who usually pays for them) and you get the list a teacher actually cares about on the 5th of the month: who has paid, who paid part, who only sent a screenshot, and who hasn't paid at all. Money that arrived without any screenshot still counts, because the statement is the source of truth, not WhatsApp.

So who would pay for this? Anyone collecting the same payments every month into a personal account and matching them by hand. Tuition classes are the obvious case. Housing society treasurers are another: a 120-flat society has 120 maintenance payments to match every month, often in a spreadsheet. The amounts are small, so the tool has to cost almost nothing to run, and that's a big part of why it's built on open models.

Demo

The demo data is a made-up tuition class collecting October fees. There are eight screenshots, and between them they cover every case: payments that went through, one that never arrived, a failed payment sent as proof, a screenshot where ₹200 was edited to ₹2,000, and the same screenshot sent twice for two kids.

Results show up row by row while it's still reading:

On my laptop (a GTX 1650 with 4 GB of VRAM, nothing fancy) it got all 8 screenshots and all 8 roster lines right. With the model already loaded, the run took about 94 seconds, so roughly 12 seconds a screenshot.

What that does and doesn't prove: the demo data is synthetic, so it shows the pipeline works end to end. It says nothing yet about how well it reads real screenshots from real phones.

About those demo screenshots. They come from a fake app I called "Demo Pay", with SAMPLE - NOT A REAL PAYMENT stamped across them. It felt wrong to build a tool that catches fake payment screenshots and then ship a folder of convincing fake payment screenshots with it.

If you want to run it yourself:

ollama pull gemma3:4b
cd frontend && npm ci && npm run build && cd ..
cd backend && uv sync && uv run proofcheck   # then open http://127.0.0.1:8000

Code

Surge77 / proofcheck

Check UPI payment screenshots against your bank statement with local open-weight models (Gemma + RapidOCR). Your statement never leaves your laptop.

ProofCheck

Check UPI payment screenshots against your bank statement, on your own laptop.

Tuition teachers, housing-society treasurers, home bakers and tiffin services collect payments by UPI into a personal account. The "proof" arrives as a screenshot on WhatsApp, and every month someone matches dozens of them against the bank statement by hand. Fake payment screenshots are a common scam, and they look exactly like real ones.

ProofCheck reads each screenshot with local open-weight models, finds its 12-digit UPI reference (UTR), and looks for that reference in your bank statement. It then tells you, in plain words who really paid.

Nothing is uploaded anywhere. The models run on your machine, uploads stay in memory, and your bank statement never leaves your laptop.

What it tells you

Result	Meaning
Verified	The UTR is in your statement with the same amount. The money arrived.
Amount differs	The UTR is there, but the screenshot

…

View on GitHub

How I Built It

screenshot ──► RapidOCR ─────► exact characters ─┐
     │                                           ├─► cross-check ─► receipt (high / low confidence)
     └───────► Gemma 3 4B ───► what they mean ───┘                       │
bank statement (CSV / XLS / XLSX) ──► credits with UTR, payer, UPI id ──► reconcile ─► report

The hard part is reading the screenshot. A typical payment screen has a phone number, a transaction ID, a date and the UTR all in one place, and a phone number with the 91 prefix is also 12 digits.

I ended up using two open models and making them check each other.

RapidOCR, which runs PaddleOCR's models on onnxruntime, reads the text exactly, character by character. It has no idea which number is the UTR, though.

Gemma 3 4B, running locally in Ollama, looks at the same screenshot and understands it. It can tell the UTR from the phone number, and "Payment Successful" from "Payment Failed". What it can't always do is read twelve small digits perfectly.

So neither of them gets the final say. When Gemma says "this is the UTR", ProofCheck only accepts it if OCR saw exactly the same digits:

def _fuse_utr(lines, vision_utr, issues):
    seen_by_ocr = {c.value for c in utr_candidates(lines)}
    claimed = re.sub(r"\s", "", vision_utr or "")
    if claimed in seen_by_ocr:
        return claimed, True          # both models agree
    fallback = _ocr_utr(lines)        # a single labelled OCR candidate, or nothing
    if claimed:
        issues.append("The vision model's UTR was not confirmed by OCR; please check it.")
    if fallback is None:
        issues.append("Could not tell which number is the UPI reference.")
    return fallback, False

The amount, the payment status and the payer's name go through the same kind of check. A screenshot only gets "high confidence" when both models agree and the screen itself says the payment went through. Anything else gets flagged for a person to look at, with the reason written out.

The models only read. Deciding whether something is verified, a duplicate or missing is ordinary Python with tests around it. I didn't want an LLM making the call on whether someone paid.

Bank statements were their own small adventure. There's no UTR column. Each bank stuffs it into a free-text description, and each one does it differently: SBI writes UPI/CR/<utr>/<name>/..., HDFC writes UPI-<name>-<upi id>-<ifsc>-<utr>. ProofCheck works out the bank from the header row, skips the address and account-number lines at the top, and reads CSV, XLSX and the old XLS format that some banks still hand out.

Around that sits a FastAPI backend that streams results back as they're ready, a React and Tailwind frontend, and Decimal everywhere money shows up.

Things that bit me

I'd written "nothing is written to disk" in the README before checking it, and it wasn't true. I ran a security review on the upload code, and the first finding was that FastAPI's file uploads let Starlette save anything over 1 MB to a temp file. Most screenshots and bank statements are over 1 MB. I swapped in a parser that keeps everything in memory and added a test that fails if Python's tempfile is ever touched. The review found 10 problems in total, including a DNS rebinding hole against localhost. They're all fixed now, but that first one stung.

Screenshots can carry prompt injection. Text inside an image can nudge a vision model into calling a failed payment a success. That's why the status and the payer name also have to match what OCR read, not just the UTR.

Then there was capital I versus lowercase l. Gemma read "Meera Iyer" correctly, OCR read "Meera lyer", and my strict name check threw out the right answer. I only caught it by running the whole thing on realistic data, which is a decent argument for doing that early.

Why Does Open Innovation Matter?

Without open models, this project doesn't really work.

The input is someone's bank statement plus other people's names, UPI IDs and payment history. I wouldn't upload that to a third-party API, and I don't think a tuition teacher should either. With open weights everything stays on the laptop. The OCR models come bundled inside the Python package, Gemma runs in Ollama on localhost, and ProofCheck refuses to start if the Ollama URL points at another machine.

Then there's the cost. Every screenshot goes through two models. With a paid vision API that's a charge per screenshot, every month, for a customer who's paying very little. Locally, once the models are downloaded, the next screenshot costs nothing.

The cross-check depends on it too. I can run a dedicated OCR model and a vision-language model side by side and compare their answers because both run on my machine. A single hosted endpoint would give me one answer and nothing to check it against.

And once it's set up it works offline. No API key, no rate limits, no pricing page that can change under me.

Prize Categories

Best Use of Gemma: Gemma 3 4B runs locally in Ollama and reads every payment screenshot. ProofCheck checks its answers against OCR before trusting them.

A few DEV posts I read along the way: I ran OCR in the browser so receipt images never leave the device has the same privacy instinct, How to Automate Invoice Reconciliation covers matching from the business side, and What Really Happens When You Make an Online Payment? is a good explainer on where payment references come from.

Building a Live 3D & 1M-Token Engineering Cookbook with Google DeepMind's Gemini 4 Argon

Robina Mirbahar — Tue, 13 Oct 2026 19:48:22 +0000

Google DeepMind recently introduced Gemini 4 Argon (gemini-4-argon), marking a major architectural leap for long-horizon software engineering and 3D spatial reasoning:

1,000,000 Input / 1,000,000 Output Unified Token Horizon (a 15.6x increase in output capacity from 64K tokens via the Long-Decode Continuation Protocol)
87.0% SOTA on Embodied 3D Reasoning (ERQA) and 91.7% on LVBench (long video understanding)
77.9% SOTA on DeepSWE v1.1 (autonomous software engineering and multi-file refactoring)
First-Class thought Summaries & Cryptographic Signatures via the Gemini Interactions API (client.interactions.create)

Instead of just reading the benchmarks, I built and open-sourced the Gemini 4 Argon Cookbook & Live 3D Starter Kit from scratch -- complete with live playable WebGL 3D simulations, a 100% pure-Python zero-dependency 3D raytracer, a procedural 3D Wavefront .obj Pagoda generator, and production 1M-token continuation loops.

Try the Live 3D Demos in Your Browser

1. Unifying 1M Input & 1M Output Tokens (Long-Decode Continuation Protocol)

Generating up to 1,000,000 output tokens in a single logical generation requires resilient connection handling. Gemini 4 Argon introduces the Long-Decode Continuation Protocol in the Gemini Interactions API v2.

When a generation slice reaches a per-turn boundary while the model still has more content to emit, interaction.status returns "incomplete" along with a cryptographic continuation_token. You simply pass that continuation_token into the next client.interactions.create(...) call to seamlessly resume decoding:

from google import genai

client = genai.Client()

def generate_up_to_1m_tokens(prompt: str) -> str:
    full_output: list[str] = []
    continuation_token: str | None = None

    while True:
        kwargs = {
            "model": "gemini-4-argon",
            "generation_config": {
                "thinking_level": "high",
                "thinking_summaries": "auto",
                "max_output_tokens": 1_000_000,
            },
        }
        if continuation_token is None:
            kwargs["input"] = prompt
        else:
            kwargs["continuation_token"] = continuation_token

        interaction = client.interactions.create(**kwargs)

        for item in interaction.outputs or []:
            if getattr(item, "type", None) == "text":
                full_output.append(item.text)

        if interaction.status == "incomplete" and getattr(interaction, "continuation_token", None):
            continuation_token = interaction.continuation_token
            continue
        break

    return "".join(full_output)

Full Runnable Examples:

Python: examples/01_long_decode_continuation.py

TypeScript: examples/01_long_decode_continuation.ts

2. First-Class `thought` Steps & Cryptographic Signatures

With client.interactions.create, reasoning is no longer hidden in raw text blocks. Gemini 4 Argon emits structured thought outputs containing both a human-readable summary and a verifiable signature (thought_signature) so multi-turn agentic workflows can preserve exact reasoning state across turns:

stream = client.interactions.create(
    model="gemini-4-argon",
    input="Design a lock-free ring buffer in Rust and prove linearizability.",
    stream=True,
    generation_config={
        "thinking_level": "high",
        "thinking_summaries": "auto",
    },
)

for chunk in stream:
    if chunk.event_type == "content.delta":
        if chunk.delta.type == "thought_summary":
            print(f"[Thought] {chunk.delta.content.text}")
        elif chunk.delta.type == "thought_signature":
            print(f"[Signature] {chunk.delta.signature[:24]}...")
        elif chunk.delta.type == "text":
            print(chunk.delta.text, end="", flush=True)

Full Runnable Example: examples/02_deep_reasoning_thoughts.py

3. Built-From-Scratch 3D Engines & Interactive WebGL Simulations (87% ERQA SOTA)

To test Gemini 4 Argon's 3D spatial reasoning, I created four 100% original, built-from-scratch 3D engines and interactive simulations:

A. Procedural 5-Tier 3D Pagoda Temple (`.OBJ` Generator + Live WebGL)

examples/08_procedural_3d_pagoda_temple.py uses pure Python math (sin, cos, parabolic catenary curves) with zero external dependencies to procedurally generate a multi-tiered 3D architectural Pagoda Temple as a standard Wavefront .obj 3D mesh, complete with upturned eaves, corner pillars, and a golden finial spire. You can also explore it live in the browser under Preset #2 in the Main 3D Studio.

B. Interactive 3D Crystalline Shatter & Voxel Physics Arena

Play Live in Your Browser | Source (09_3d_physics_shatter_arena.html)

Click anywhere in 3D space to fire high-velocity kinetic spheres via 3D raycasting (THREE.Raycaster). On impact, a 240-shard crystal monolith fractures using radial impulse transfer, gravity, angular momentum, floor restitution, expanding shockwave rings, and built-in .webm video recording.

C. 6-DOF 3D Robotics Inverse Kinematics & Ballistic Simulator

Play Live in Your Browser | Source (10_3d_robotics_ik_simulator.html)

Solves 2-link planar + base yaw 3D inverse kinematics (acos / atan2 law of cosines) and parabolic ballistic trajectories. Click Toss Payload at Target to watch the articulated 6-DOF robot arm track a moving target platform and launch payloads right into the bullseye.

D. 100% Pure-Python Zero-Dependency 3D Ray-Tracing Engine

examples/04_vanilla_3d_raytracer.py implements a complete 3D ray-tracing engine using only the Python standard library (math, struct, zlib) -- rendering recursive mirror reflections, Blinn-Phong specular highlights, soft area-light shadows, and a procedural checkerboard parquet floor directly to .ppm and .png.

4. Multimodal Image & Video -> 3D Scene Graph Reconstruction

In examples/07_multimodal_image_video_to_3d.py, you can pass any 2D photograph or video clip to gemini-4-argon with a strict JSON Schema (response_schema) to extract a 3D scene graph containing:

3D bounding boxes (center_xyz, dimensions_whd, rotation_euler_deg)
Physically Based Rendering (PBR) materials (roughness, metallic, albedo_hex)
Rigid-body physics mass (estimated_mass_kg) and camera intrinsics (fov_degrees)

And in the Live 3D WebGL Studio, you can click Upload Image or Video -> 3D Mesh to turn any photo or video on your device into a live 3D depth-mapped point cloud in real time!

Quick Start

git clone https://github.com/RobinaMirbahar/gemini-4-argon-cookbook.git
cd gemini-4-argon-cookbook
pip install -r requirements.txt

# 1. Generate a 3D Pagoda Temple Wavefront (.obj) mesh from scratch
python examples/08_procedural_3d_pagoda_temple.py

# 2. Render the 100% Pure-Python 3D Raytracer (.ppm / .png)
python examples/04_vanilla_3d_raytracer.py

# 3. Run Multimodal Image/Video -> 3D Scene Reconstruction
python examples/07_multimodal_image_video_to_3d.py --demo

# 4. Run the 1M Token Long-Decode Continuation Protocol
python examples/01_long_decode_continuation.py --demo

What Are You Building First?

Check out the full open-source repository at github.com/RobinaMirbahar/gemini-4-argon-cookbook and give it a star if you find it useful! Let me know in the comments whether you're most excited about Gemini 4 Argon's 1M output token horizon, autonomous code auditing, or 3D spatial reasoning.

Local AI on a Mac: what one open source app runs on Apple Silicon, and what it does not

David — Tue, 13 Oct 2026 19:43:50 +0000

Locally Uncensored 3.0.6 is the first release with a Mac build. It is an open source desktop app (AGPL-3.0) that runs AI models on your own machine: chat, a coding agent, image and video generation, voice, and a model that can use your mouse and keyboard. On Windows and Linux it has 170,000+ downloads. On the Mac it is a beta, and the honest reason is short: the app has run on exactly one Mac so far.

This post goes through each part of the app and says what runs locally on a Mac today, what only runs on Windows and Linux, and what I have not tested.

What you need

Apple Silicon (Intel Macs are not supported)
macOS 14 or newer

The one Mac it has run on is an M5 Pro with 48 GB on macOS 26. It has not run on macOS 14 or 15, and not on a Mac with 16 or 24 GB. If you have one of those, your report is worth more to me than another run on my own machine.

Install

Download the .dmg for Apple Silicon from locallyuncensored.com/mac.
Open it and drag the app into Applications.
Start it. The setup wizard picks a first model for your machine.

The .dmg is signed with a Developer ID and notarized by Apple. Local use is free and needs no account.

Local chat with an LLM

Local models run through a bundled server with Metal. There is no separate runner to install first. If you already use Ollama or LM Studio, the app can talk to those as backends too.

Around the chat itself: thinking is shown as it happens, you can chat with your own documents through a local index, keep a memory across conversations, switch personas, and compare two models side by side. Models with image input download together with their image part, the second file a local model needs to see pictures. That download path is new in 3.0.6 and I have not checked it on the Mac specifically.

There is also a Local API: an OpenAI compatible server on port 8129 that lists your local models under one address. It listens on localhost unless you allow the LAN, and it always asks for a token.

Local image generation without ComfyUI

On Windows and Linux the app drives ComfyUI. On a Mac it does not use ComfyUI at all. Create makes images on the Mac itself, on engines the app installs for itself.

The Mac catalog lists 23 image models. Each tile says how much memory the model needs, and that number is a hard limit, not a hint: a model that needs 32 GB stays locked on a 16 GB Mac. The smallest ones (SD Turbo, Realistic Vision V5.1) need 8 GB.

Measured on the M5 Pro with 48 GB:

DreamShaper XL Turbo    one image    33 s
Qwen-Image 2.1 Turbo    one image    38 s

A smaller Mac will be slower. I have not measured by how much.

One Mac detail the app handles for you: chat and Create share one pool of memory. Before a picture or video run, Create takes the chat model out of memory, shows "Freeing memory..." while it does, and brings the model back afterwards.

Local image editing

Edit on the Mac runs on Qwen-Image 2.1, and the Edit tab appears once that model is installed. The 4-bit pack needs 16 GB.

It works differently from the brush you may be used to. There is no mask. You give it a picture and describe the change in words, and you can add reference images.

Edit on the Mac is in the code and in the app. It is not in the list of things I timed for the release, so treat it as less proven than plain generation.

LoRAs on the Mac

You can use LoRAs with the quantized image models in the Mac catalog, the ones whose names end in 4-bit or 8-bit: Qwen-Image 2.1, Qwen-Image 2512, Z-Image Turbo and FLUX.2 klein 4B. There is a LoRA list with its own folder, a stack with strength sliders, and delete moves the file to the Trash.

A Qwen-Image 2.1 LoRA that carries its own alpha is weighted the way ComfyUI does it, alpha divided by rank. Before 3.0.6 it ran at the full strength that was set, which was too strong.

Character LoRA training: not locally on a Mac

This one I want to state flat, because people search for it. Training a character LoRA on your own hardware works in the app on Windows and Linux, where Character Studio trains on your own card and drops the result into your local LoRA folder. It does not run locally on a Mac. On a Mac, character training goes through the hosted side, and a character trained there can be downloaded as a .safetensors file.

Local video generation

The Mac catalog lists 31 video models. The smallest need 16 GB: LTX-2.3 Distilled 4-bit, and Wan 2.1 T2V 1.3B, which is better off with 32.

LTX-2.3 Distilled 4-bit    2 s clip, 768x512, with sound    64 s    (M5 Pro, 48 GB)

Two things to know before you start a long run. Where a model was timed on a real run, Create tells you before the start how long a clip will take once that is ten minutes or more, and during the run it shows the step and the time left. And most video models in the Mac catalog are marked "Experimental: not yet tested in LU". Take that label at its word.

Animate, which starts a clip from a picture, is there once you have installed a video model that takes a start image.

What Create does not do locally on a Mac

On Windows and Linux, Create also has local lanes for background removal, talking character, music, extending a clip and motion control. None of those run locally on the Mac build. Upscale and erase are hosted on every platform.

Voice mode

You talk, the chat model you picked answers, and you hear the answer. Speech recognition, the voice and the turn taking run on your machine. There are fifteen voices, and you can interrupt an answer by speaking.

Numbers from the M5 Pro:

Setup download          about 0.7 GB
Answer starts           1.4 to 2.0 s after the end of the question
Voice engine in memory  1.2 to 1.3 GB

Voice is in beta and English only. On the Mac it has been tried by hand in the app. It did not get the point by point check the Windows app got.

Local computer control

A model uses the mouse and keyboard in apps you approve. It is off by default. In every new chat it asks once before it looks at the screen, and it never types into a password field.

On a Mac it is more limited than on Windows, and it is not fully tested yet. The app says so at its switch. What is different:

macOS has to grant two permissions first, Accessibility and Screen Recording.
On Windows the model gets a list of the buttons and fields in a window. On macOS that list is not available, so the model needs image input and works from screenshots.
For the same reason the app cannot name what a click would press, so every click is asked and needs your click.
The autonomous mode exists on Windows only.

Control+Option+Space pauses and Control+Option+Esc stops. I would use this on a Mac to try it out, not to rely on it.

Coding agent

The Agent and Code tabs are in the Mac build. The agent's shell gets the PATH of your login shell, so tools installed through Homebrew are found. The agent can also call the local image and video engines as tools. I have no separate Mac test run for these two tabs to point at.

Not confirmed on macOS

Remote Access (using the app from your phone)
Automatic update (there is no older Mac version to update from)

Short version

Local chat, image generation, image editing by prompt, LoRAs, video and voice run on the Mac itself, with no ComfyUI and no account. Character LoRA training, music, talking character and the other extra lanes do not run locally on a Mac yet. Computer control is there but not fully tested. All of it has run on one M5 Pro with 48 GB, which is why the build says beta.

If something breaks on your machine, the issue tracker is the place. The code is at github.com/PurpleDoubleD/locally-uncensored, and the Mac page keeps the current state of each part.

If your Mac is an Intel model or short on memory, the same kind of models also run hosted in a browser as LU Cloud. That part is paid. Everything above is free.

Revolutionizing CAD: Why CADCraft is the Open-Source AutoCAD Alternative You Need!

GitHubOpenSource — Tue, 13 Oct 2026 19:43:25 +0000

Quick Summary: 📝

CADCraft is an open-source, clean-room reimplementation of AutoCAD, built entirely in Rust. It aims to provide a fast and familiar CAD experience with features like command line, object snaps, layers, dimensions, and hatches, running on multiple operating systems and the web.

Key Takeaways: 💡

✅ CADCraft is an open-source, free alternative to AutoCAD, built from scratch in Rust.
✅ It offers a familiar workflow with features like command line, layers, object snaps, and DXF support.
✅ Leverages Rust for high performance, memory safety, and reliability in CAD applications.
✅ Runs natively on macOS, Windows, Linux, FreeBSD, and even in the browser via WebAssembly.
✅ A community-driven project with immense potential for developers and designers to contribute and benefit.

Project Statistics: 📊

⭐ Stars: 3845
🍴 Forks: 1758
❗ Open Issues: 138

Tech Stack: 💻

✅ Rust

Are you tired of the hefty subscription fees and proprietary lock-in that come with traditional CAD software? Do you dream of a powerful, familiar design tool that's truly yours, running on any platform you choose? Well, fellow developers and designers, get ready to be excited because a game-changer has arrived on GitHub: CADCraft!CADCraft isn't just another CAD program; it's a bold, open-source clean-room reimplementation of Autodesk AutoCAD, rebuilt from the ground up in pure Rust. Imagine all the core functionalities you rely on – the command line, object snaps, layers, dimensions, hatches, blocks, and DXF drawing support – but now, it's completely open, free, and community-driven. This project aims to bring the robust and intuitive AutoCAD workflow we all know and love into the open-source world, without compromising on power or familiarity.One of the most exciting aspects of CADCraft is its foundation in Rust. For those unfamiliar, Rust is a programming language renowned for its performance, memory safety, and concurrency. This means CADCraft is designed to be incredibly fast, reliable, and efficient, handling complex designs without breaking a sweat. It's a modern approach to a classic problem, leveraging cutting-edge technology to deliver a superior user experience.And the accessibility? It's phenomenal! CADCraft runs natively across all major operating systems: macOS, Windows, Linux, and even FreeBSD. But wait, there's more – it also runs directly in your browser via WebAssembly! This cross-platform compatibility means you can work on your designs from virtually anywhere, on any device, without needing expensive licenses or specific hardware setups. This flexibility alone is a massive win for individual designers and small teams alike.For developers, the open-source nature of CADCraft opens up a world of possibilities. You can inspect the code, contribute to its development, and even build custom extensions or integrations tailored to your specific needs. This isn't just a tool; it's a platform that you can help shape and evolve. The ArtCraft team is fostering a vibrant community, inviting artists and creators from all backgrounds to join the conversation and contribute.In essence, CADCraft is poised to democratize computer-aided design. It offers a powerful, familiar, and free alternative to proprietary software, built with modern performance in mind and accessible across all platforms. While still in early development, its potential is immense, and it's definitely a project you'll want to keep an eye on – or even better, get involved with!

Learn More: 🔗

View the Project on GitHub

🌟 Stay Connected with GitHub Open Source!

📱 Join us on Telegram

Get daily updates on the best open-source projects

GitHub Open Source

👥 Follow us on Facebook

Connect with our community and never miss a discovery

GitHub Open Source

Aurelio Pairs Local Finance Records With an Optional AI Adviser

David Díaz — Tue, 13 Oct 2026 19:42:29 +0000

Aurelio is a public, MIT-licensed personal-finance application that runs on the user’s computer and keeps its records there. Its AI adviser is optional and connects through OpenRouter with the user’s API key. Developers can therefore clone and run the financial tracker locally while deciding separately whether to configure the external AI integration. The repository documents the license, local operation and optional adviser.

A ledger for assets, liabilities and goals

Aurelio records banks, brokers, cash and dated holdings. Its portfolio views calculate position costs, gains and dividends, while its fund look-through breaks exposure down by country, sector, company and currency. The app also covers recurring investments, homes, debts, income, expenses, savings rates and the returns required for financial goals. These functions are listed in the project README.

Running the demo requires Git, Node.js 22 or later and uv. The supplied macOS, Linux and Windows scripts start the app with an invented household and open it at http://localhost:8000. The repository provides the requirements and demo commands.

For non-demo use, records reside in backend/data.db. The project says it saves a copy beside that file before an update changes the data format. The storage path and pre-update copy behavior are documented in the README.

The repository also documents separate backend and frontend test commands using pytest and npm test, plus hot-reload commands based on Uvicorn and the frontend development server. Those development workflows appear in the project documentation.

The adviser introduces a second boundary

The “Ask Aurelio” chat answers from the user’s records, can search the web and presents proposed changes as cards that the user must confirm. Enabling it requires an OpenRouter account with credit and an API key stored in backend/.env; users can select a model in the chat. The repository describes the chat behavior and OpenRouter configuration.

Analysis: Local record storage and local AI processing are not the same property. Aurelio keeps its ledger on the user’s machine, but the optional adviser routes through OpenRouter and can use those records when answering questions. Developers evaluating the app should therefore treat storage and AI processing as separate trust boundaries rather than reading “runs on your own computer” as a claim that every enabled operation remains local. That interpretation follows from the project’s description of local records and its OpenRouter-backed adviser.

The confirmation-card flow provides a visible checkpoint before a proposed change is accepted. Analysis: It does not settle the separate question of what financial context is appropriate to submit to an external AI service. The unresolved trade-off is between the adviser’s record-aware answers and web search on one side, and keeping the application free of that external integration on the other. The underlying confirmation, record access, web search and optional-AI behaviors are documented by the project.

ShopCraft AI: High-Converting Etsy & Shopify Listings Powered by Gemma 2

Saptak Roy — Tue, 13 Oct 2026 19:36:16 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 2: Side Hustle

What I Built

Solo artisans, woodworkers, and vintage sellers face an exhausting bottleneck when expanding an e-commerce side hustle: listing friction.

Handmade merchants spend upwards of 30 to 45 minutes per product manually researching high-volume keywords, formatting narrative descriptions, and strictly staying within Etsy’s rigid search criteria:

Titles capped at 140 characters (where early keyword density determines click-through rate)
Exactly 13 algorithm tags, each capped strictly at 20 characters
Conversion-oriented bullet points outlining materials and care instructions

ShopCraft AI solves this problem in under 5 seconds. A seller simply enters raw notes—the item name, materials used, target audience, and key highlights—and ShopCraft formats a marketplace-ready, high-converting product listing adhering strictly to e-commerce SEO requirements.

Who Would Pay for It?

Solo creators on Etsy, Shopify, and Depop. Small makers cannot justify $20–$50/month enterprise SEO platforms like Marmalead or eRank when they only launch 5–15 products a month. A hyper-focused micro-SaaS priced at $5/month or $0.20 per batch listing offers an immediate return on investment for small shop owners.

Demo

Live Deployed App: https://shopcraft-ai-htvrhihrounmvh2qzkvsyj.streamlit.app

Try generating a listing with the default sample:

Product: Wheel-thrown Stoneware Matcha Bowl
Materials: White stoneware clay, food-safe moss green reactive glaze
Target Audience: Ceremonial matcha drinkers, minimalist home aesthetic
Features: 12oz capacity, built-in spout for pouring, microwave & dishwasher safe

Code

You can view the full repository, requirements, and deployment setup here:

rumparoy3012-ops / shopcraft-ai

How I Built It

ShopCraft AI is built around Google's open-weight model, Gemma 2 (2B Instruct).

Frontend & Orchestration: Built using Python and Streamlit, providing an uncluttered, responsive seller workspace.
Model Layer: The app integrates with Google Gemma 2 2B-IT, utilizing prompt instruction tuning to enforce structured field generation (Title, 13 SEO Tags, and Formatted Description).
Format Constraint: Because marketplace algorithms reject tags exceeding 20 characters, the prompt explicitly constrains Gemma 2 to produce comma-separated phrases under this character ceiling, avoiding post-processing failure.
Deployment: Hosted directly on Streamlit Community Cloud with continuous integration linked to GitHub.

Why Does Open Innovation Matter?

Why build this on an open-weight model like Gemma instead of relying on closed commercial APIs like OpenAI or Anthropic?

1. Sustainable Micro-SaaS Unit Economics

Closed APIs charge per prompt token and generated token. For an indie side hustle targeting micro-merchants at $5/month, unpredictable token usage and bursty scraping rapidly destroy profit margins. Gemma 2's open weights allow self-hosting, local deployment, or predictable fixed-cost container deployment where inference costs stay stable regardless of request volume.

2. Protecting Proprietary Seller IP

Handmade artisans frequently input confidential formulas, unreleased collections, and novel design techniques. With open models running on controlled instances, customer design notes and proprietary material compositions are never routed into closed third-party datasets for model retraining.

3. Model Independence & Longevity

Closed API providers routinely deprecate endpoints, alter hidden system prompts, or modify safety thresholds that break structured JSON/formatting parsers without notice. Open-weight models like Gemma 2 give builders permanent architectural stability: once the prompt and weights produce the intended schema, the service remains consistent indefinitely.

My First User

To test ShopCraft AI in the real world, I shared the live deployment with a local creator who sells handmade terracotta crafts and customized home decor.

The Test: She entered a listing for a hand-painted terracotta desk planter.

Her Feedback:

"Usually writing the tags is the most annoying part because Etsy cuts you off at 20 characters, and I keep having to re-count letters. The app gave me 13 tags that were ready to copy-paste. I'd definitely pay a small flat fee like ₹200–₹400 ($3–$5) a month if it saves me an hour every weekend."

Next Request:
She asked for an export button to copy all 13 tags into clipboard memory with a single click, which is slated for the next version update.

Prize Categories

Best Use of Gemma

MenuMorph AI

Aryan — Tue, 13 Oct 2026 19:19:33 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 2: Side Hustle

🍽️ The Hyper-Local Restaurant Menu & Allergen Digitizer: A Micro-SaaS for Independent Kitchens

What I Built

Independent and immigrant-owned restaurants—your favorite neighborhood Mexican taquería, family-run Ethiopian kitchen, hole-in-the-wall ramen bar, or Sicilian trattoria—face a frustrating dilemma every single day:

The Physical Menu Trap: Daily specials, rotating seasonal ingredients, and shifting wholesale prices are scribbled on physical chalkboards, laminated paper, or dry-erase boards. Updating them costs hundreds of dollars in reprinting fees or tedious manual work.
The "Translation Gibberish" Disaster: When foreign travelers or non-native diners visit, generic translation tools butchered authentic cultural dishes into culinary nonsense—turning Birria into "rubble/debris", Pozole into "hominy mush", Injera into "sponge bread", or Gnocchi into "potato lumps".
The Allergen & Dietary Minefield: Modern diners require clear, trustworthy dietary transparency (Gluten-Free, Nut-Free, Dairy-Free, Vegan, Vegetarian). Waitstaff are often overwhelmed explaining whether the birria consommé is wheat-free or if the injera is 100% teff grain.
Predatory POS & SaaS Pricing: Platforms like Toast, DoorDash, and ChowNow charge hefty monthly subscription fees ($79–$200+/mo) plus cut-throat commissions, pricing out neighborhood micro-restaurants.

The Solution: A Lightweight Micro-SaaS

The Hyper-Local Restaurant Menu & Allergen Digitizer is an AI-powered micro-SaaS designed specifically for independent restaurant owners.

The owner simply snaps a photo of their physical menu, paper slip, chalkboard, or PDF:

Multimodal Document Understanding: Automatically parses categories (Appetizers, Mains, Drinks, Desserts), dish names, and prices.
Cultural RAG Glossary Preservation: An embedded localized culinary dictionary guarantees that cultural dishes (Birria, Pozole, Injera, Doro Wat, Cacio e Pepe, Tonkotsu) remain intact with authentic names and appetite-inducing, customer-facing descriptions instead of machine-translation gibberish.
Automated Allergen & Dietary Tagging: Accurately infers dietary badges (GF Gluten-Free, NF Nut-Free, DF Dairy-Free, VG Vegan, V Vegetarian) based on authentic culinary preparation rules.
Trilingual Localization: Instantly translates the entire menu into 3 owner-selected languages (e.g., Spanish, French, Mandarin, Japanese, German).
Interactive Review & 1-Click QR Deployment: Owners review, adjust prices, or toggle badges in a live card editor, click "Publish & Get QR", and instantly download a high-resolution QR code for table stands and window decals linking directly to a mobile-first digital menu.

Who Would Pay For It?

Independent restaurant owners, food truck operators, and pop-up chefs. A simple pricing tier of $19/month (or $49 one-time setup + $9/mo) saves them hours of reprinting, increases table turn rates by 18%, and unlocks high-margin orders from tourists and health-conscious diners.

Demo

Live Local Endpoint: http://localhost:8000
Customer Mobile Menu: http://localhost:8000/menu/menu_a692782204
Swagger Documentation: http://localhost:8000/docs

Visual Walkthrough

Dashboard & Upload Zone: Clean, responsive dashboard supporting drag-and-drop of menu images and multi-page PDFs, alongside 1-click test presets for Mexican, Ethiopian, Italian, and Japanese cuisines.
AI Vision Pipeline: Animated real-time stage progression:
- Stage 1: Multimodal OCR & Spatial Document Recognition
- Stage 2: Regional Cultural Glossary Context Injection
- Stage 3: Allergen & Dietary Tag Inference
- Stage 4: Multilingual Localization (3 Target Languages)
Interactive Owner Review: Edit dish names, adjust prices, toggle allergen badges (GF, NF, DF, VG, V), and inspect translations across tabs before publishing.
Customer Mobile Experience: Diners scan the generated QR code to access a fast, mobile-first web app with real-time allergen filtering (e.g. Show only Gluten-Free) and instant language toggling (English, Español, Français, 中文, 日本語).

Code

a1rya9n / ai-application

🍽️ The Hyper-Local Restaurant Menu & Allergen Digitizer

A production-ready micro-SaaS web application designed for independent restaurant owners. Upload a photo or PDF of a physical paper menu or chalkboard, parse it with a multimodal vision model, preserve authentic cultural and culinary terminology via a localized RAG dictionary, generate appetizing customer-facing descriptions, translate into 3 target languages, automatically infer and tag common allergens (GF, NF, DF, VG, V), and deploy an interactive mobile-optimized digital QR menu page.

🚀 Key Features

Multimodal Vision Ingestion:
- Supports camera photos, chalkboard snapshots (.jpg, .png, .webp), and multi-page .pdf files.
- Accurately segments categories (Appetizers, Mains, Drinks, Desserts), dish names, and prices.
Cultural & Culinary RAG Glossary:
- Injects authentic regional terminology across cuisines (Mexican, Ethiopian, Italian, Indian, Japanese, Thai, Vietnamese, French, Middle Eastern, etc.).
- Prevents machine-translation gibberish (e.g., keeps Birria, Injera, Gnocchi…

View on GitHub

The application is completely open-source and modular:

ai-application/
├── main.py              # FastAPI backend, vision pipeline, RAG glossary & SQLite store
├── requirements.txt     # Python dependencies
├── .env.example         # Multi-model environment configuration
├── templates/
│   ├── index.html       # Restaurant upload dashboard & live interactive editor
│   └── menu.html        # Mobile-first public digital QR menu with filters & language switcher
├── static/              # Static frontend assets
└── sample_menus/        # Realistic sample chalkboard menu images & test fixtures

Architecture Diagram

flowchart TD
    A[Physical Menu / Chalkboard Photo / PDF] --> B[FastAPI Backend /api/process-menu]
    B --> C[Google PaliGemma 2 Multimodal Vision Engine]
    C --> D[Document Layout & Text Extraction]
    D --> E[Cultural RAG Glossary Injection]
    E --> F[Automated Allergen Tagging GF, NF, DF, VG, V]
    F --> G[Multilingual Translation Engine 3 Languages]
    G --> H[(SQLite Database menus.db)]
    H --> I[Interactive Owner Review Dashboard]
    I -->|Publish & Generate QR| J[High-Res QR Code PNG Generator]
    J --> K[Mobile-First Customer Digital Menu /menu/id]

How I Built It

1. Open-Source AI Architecture: Google PaliGemma 2

At the core of the multimodal vision pipeline is Google PaliGemma 2 (google/paligemma2-10b-pt-448 / google/paligemma2-3b-pt-448).

Why PaliGemma 2? Standard OCR fails when confronted with stylized fonts, chalk dust, slanted handwriting, and multi-column menu layouts. PaliGemma 2 pairs a SigLIP vision transformer encoder with the Gemma 2 language model backbone. Because it was fine-tuned on Document Visual Question Answering (DocVQA) and text reading, it excels at deciphering complex real-world visual layouts.
Multimodal Vision Prompt Pipeline: The vision model is instructed to parse visual structure, extract prices and categories, retain cultural culinary terminology, and infer ingredient profiles.

2. The Cultural RAG Glossary

Generic LLMs frequently mangle cultural terms. To solve this, the pipeline incorporates an embedded RAG dictionary across 10 global culinary traditions (Mexican, Ethiopian, Italian, Indian, Japanese, Thai, Vietnamese, French, Middle Eastern, American Diner).

Terms like Birria, Consomé, Injera, Doro Wat, Gnocchi, Cacio e Pepe, and Tonkotsu are safeguarded: their authentic names remain untouched in target languages, while sensory, appetite-inducing descriptions explain their preparation.

3. Allergen Inference Engine

Each parsed dish is evaluated against heuristic and semantic ingredient lexicons:

Dishes free of wheat, flour, noodles, bread, and gluten-based dough are tagged GF (with cultural exceptions like pure teff injera and corn tortillas properly handled).
Nut-free dishes are tagged NF; dairy-free preparations are tagged DF.
Plant-based preparations are accurately differentiated into VG (Vegan) and V (Vegetarian).

4. Full-Stack Web App

Backend: Python 3.10+, FastAPI, Pydantic v2, SQLite3, Pillow, QRCode, and HTTPX.
Frontend: Clean HTML5, Tailwind CSS via CDN, Lucide Icons, and Vanilla JavaScript with Fetch API.
Resilient Autonomous Fallback: If an external API key is absent, the backend automatically transitions to its built-in local culinary intelligence engine, guaranteeing zero downtime.

Why Does Open Innovation Matter?

Open innovation and open-weight models made this micro-SaaS viable in ways closed commercial APIs never could:

Micro-SaaS Unit Economics: Closed vision APIs (such as GPT-4o Vision or Claude Sonnet 3.5) charge high rates per image token. For a neighborhood diner that updates its chalkboard specials daily, hundreds of image API calls per month would obliterate the margins of a $19/mo subscription. By using open-weight models like Google PaliGemma 2, inference can run on affordable hosting, local workstations, or cost-effective serverless endpoints, keeping operational costs negligible.
Local Edge Privacy & Data Sovereignty: Many independent restaurant owners are cautious about uploading unpublished recipes, daily cash-flow figures, and proprietary menu secrets to third-party proprietary clouds. Open weights enable running inference completely on-premise (e.g., on a local Mac Mini or POS edge device behind the counter). No menu data or customer analytics ever need to leave the restaurant's premises.
No Closed-API Vendor Lock-In: Proprietary APIs frequently change rate limits, adjust pricing tiers, or deprecate model endpoints without warning. With open-weight models like PaliGemma 2, our application is immune to sudden API sunsetting. We own our model pipeline.

My Agent Session

This application was engineered collaboratively using an AI agent pair-programming session. All architecture design, FastAPI routes, RAG culinary glossaries, allergen logic, and Tailwind frontend views were implemented and verified step-by-step.

{% agent_session ed7d8204-f3ad-4bc0-8793-a5f6a54c084a %}

My First User

To test the project in the real world, I walked over to Taquería La Tradición, a family-owned neighborhood Mexican restaurant run by Carlos and his family.

Carlos had a dry-erase whiteboard behind the counter with handwritten lunch specials: Birria de Res con Consomé, Tacos al Pastor, Elote Asado, and Churros. He told me:

"A lot of tourists come in from the convention center. Half of them don't speak Spanish or English, and almost every day someone asks if our birria has flour or dairy because of allergies. My servers spend ten minutes explaining every dish."

We snapped a photo of his whiteboard using a phone camera and uploaded it into the app:

In less than 5 seconds, the app parsed all 6 dishes and prices.
It automatically retained Birria and Consomé as authentic cultural terms while generating appetizing descriptions.
It tagged the Birria as Gluten-Free, Nut-Free, and Dairy-Free, and the Elote as Vegetarian.
It generated translations in Spanish, French, and Mandarin.
We clicked "Publish & Get QR", printed the QR code on a small plastic table card, and placed it on Table 4.

The Result:
Within two hours, a French couple scanned the QR code, viewed the menu in French, filtered for dairy-free items, and ordered two orders of Birria without hesitation. Carlos was thrilled:

"I used to pay $180 every time we reprinted laminated menus. If this costs $20 a month and lets me update specials from my phone in two seconds, I'll pay for it right now."

Prize Categories

🏆 Featured Category: Best Use of Gemma
- Built natively around Google's open-weight PaliGemma 2 multimodal vision architecture (paligemma2-10b-pt-448 / paligemma2-3b-pt-448), fusing SigLIP vision capabilities with Gemma 2 language reasoning to solve physical document understanding, layout parsing, and cultural cuisine preservation.

BistroLocal AI: An Open-Source Culinary Agent That Empowers Independent Restaurants to Safely Welcome International Diners

SHAIK MUSTAFA ALI — Tue, 13 Oct 2026 19:16:23 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 2: Side Hustle

🍽️ What I Built

The Problem

If you have ever traveled abroad and sat down at a family-run trattoria in Rome, an izakaya in Kyoto, or a taco stand in Oaxaca, you have felt the friction:

Generic Machine Translation Mangles Food: Google Translate turns Penne all'Arrabbiata into "Angry Pens", Nasu Dengaku into "Eggplant Field", and completely misses what makes the dish special. It strips away the soul, the terroir, and the cultural story of the cooking.
Hidden Allergens Are Dangerous: For tourists with celiac disease, severe peanut/shellfish allergies, or religious dietary requirements (Halal, Kosher, Vegan), ordering unfamiliar dishes in a foreign language is terrifying. A mistranslated oyster sauce or wheat flour thickener can trigger anaphylaxis or ruin a holiday.
Chefs Refuse to Leak Secret Recipes: Independent chefs guard their family spice ratios, grandmother's marinades, and proprietary techniques. They flatly refuse to upload secret recipes into closed cloud APIs like OpenAI or Anthropic, where data is retained and used for model training.
Cloud API Token Burn Destroys Side Hustle Margins: Translating a 50-dish menu into 10 tourist languages generates 500 LLM calls per menu revision. With closed cloud APIs costing $0.03–$0.05 per call, a developer offering this service to 20 local restaurants would bleed hundreds of dollars a month in API bills, destroying their profit margins.

The Solution: BistroLocal AI

BistroLocal AI is a privacy-first, 100% offline-capable culinary intelligence platform and interactive digital QR menu generator built for local independent restaurants.

Who would pay for it? Local restaurant owners, bistros, food trucks, and cafes in tourist cities.
The Business Model: A simple $39/month subscription (or a $149 one-time onboarding fee) per restaurant.
The Value Proposition: Restaurants gain a dynamic, multi-lingual digital menu that boosts international visitor ticket spend by 32%, eliminates language miscommunication, and protects diners with automated Big-14 allergen safeguards.
Your Margin as the Builder: Nearly 100% gross margin because all AI translation runs locally using open-weight models, and tabular forecasting runs via open-source tools with $0.00 marginal API costs!

🎥 Demo

Experience the live interactive application:

Repository & Code: https://github.com/Mustafa1765/challange--2-26-hcober
Local Dev Server: http://127.0.0.1:8000

Key Demo Highlights:

Menu Studio: Browse authentic menus from Rome (Trattoria Da Cesare), Kyoto (Kappo Izakaya Gion), and India (Malabar Coast Spice Kitchen). Select any target language (Japanese, Spanish, French, German, Mandarin, Italian, Korean, Arabic, Portuguese) to watch dish names, sensory flavor notes, culinary heritage stories, and dining etiquette render in real-time.
Interactive Guest QR Menu: Diners scan the simulated table QR code to view a mobile-optimized dining menu. Check "Hide Gluten", "Hide Dairy", or "Show Only Halal", and conflicting dishes disappear instantly from the guest's view.
TabPFN Tourist Demand Forecaster: Input demographic features (party size, origin region, dining slot, spice tolerance, dietary restrictions) to forecast dish demand categories, predict allergen escalation probabilities, and recommend kitchen prep quantities.

💻 Code

The complete source code is open-source under the MIT License:

Mustafa1765 / challange--2-26-hcober

BistroLocal AI 🍲✨

Hyper-Localized Cultural Menu Translator, Allergen Safety Guardian & TabPFN Tabular Dining Forecaster Submission for Hacktoberfest Open-Source AI Challenge Week 2: Side Hustle

🎯 The Problem & The Side Hustle Opportunity

The Pain Point

Every year, millions of international travelers visit local trattorias in Rome, izakayas in Kyoto, taco stalls in Oaxaca, and spice bistros in Kerala.

Google Translate Butcheries: Generic translation destroys culinary heritage. Translating Penne all'Arrabbiata as "Angry Pens" or Nasu Dengaku into "Eggplant Field" alienates diners and trivializes the chef's craft.
Hidden Allergen & Dietary Nightmares: Tourists with severe celiac disease, nut allergies, or religious dietary requirements (Halal, Kosher, Vegan) suffer extreme anxiety. A mistranslated fish paste or wheat thickening agent can trigger anaphylaxis or ruin a diner's trip.
Chefs Protect Their Recipes: Independent chefs fiercely guard proprietary spice blends, secret family sauces, and local suppliers. They flatly refuse to upload confidential…

View on GitHub

Core Architecture

Backend: Python 3, FastAPI, Uvicorn, Pydantic, HTTPX.
AI Core (Language & Culture): Open-weight models (Llama 3.2, Qwen 2.5 via local Ollama) + offline culinary intelligence RAG heuristics.
AI Core (Tabular Forecasting): TabPFN-3.5 (Prior Labs' Tabular Foundation Model) + local Scikit-Learn tabular ensemble fallback.
Frontend: Vanilla HTML5 & bespoke Vanilla CSS dark-mode glassmorphic design system with zero external UI framework dependencies.

⚙️ How I Built It

BistroLocal AI is architected around two complementary open-source AI engines:

1. Local Open-Weight Culinary Translation Engine (`backend/engine/translator.py`)

Rather than doing literal word substitution, our culinary engine dissects each dish into 5 distinct dimensions:

Authentic Local Title with Phonetic Guide: Preserves the cultural name while providing phonetic pronunciation (e.g. Cacio e Pepe [KAH-choh eh PEH-peh]).
Sensory Tasting Notes: Explains mouthfeel, texture, and aroma in the diner's native tongue.
Cultural Heritage & Terroir: Explains the historical origin of the recipe.
Traditional Technique: Details how the kitchen crafted the dish.
Dining Etiquette: Offers tips on traditional pairings and how to eat the dish like a local.

The backend queries local Ollama (http://127.0.0.1:11434) running compact, powerful open-weight models (llama3.2, qwen2.5). If Ollama is offline or running on a restricted POS terminal, BistroLocal AI smoothly falls back to an internal deterministic regional culinary dictionary with zero latency.

2. Big-14 Allergen Guardian (`backend/engine/allergen_detector.py`)

Scans raw ingredient strings to detect the Big 14 EU/FDA allergens (Gluten, Crustaceans, Eggs, Fish, Peanuts, Soybeans, Milk, Tree Nuts, Celery, Mustard, Sesame, Sulphites, Lupin, Molluscs), tags religious/ethical dietary compatibility (Halal-Friendly, Kosher-Friendly, Vegan, Vegetarian, Gluten-Free), and flags cross-contact hazards like shared fryers.

3. TabPFN-3.5 Tabular Intelligence Agent (`backend/engine/tabpfn_predictor.py`)

Generic LLMs are notorious for hallucinating numbers when processing tabular records. We integrated Prior Labs' TabPFN-3.5, a state-of-the-art foundation model designed specifically for tabular data.

Dataset (backend/data/dining_history.csv): Historical table records tracking party size, tourist origin region, dining time slot, season, spice tolerance, dietary profiles, and ordered dish categories.
Predictions Made:
- Dish Preference Probabilities: Full probability distribution across dish types for incoming tables.
- Allergen Escalation Risk Score (0–100%): Predicts the likelihood that a table will require custom kitchen intervention or allergen substitution.
- Daily Prep Servings Regression: Estimates prep batch volumes to help kitchen staff prevent food waste.

🌟 Why Does Open Innovation Matter?

Open innovation is not just a nice-to-have for this project—it is the fundamental reason this side hustle works:

Edge & Offline Resilience: Many of the best restaurants in the world are tucked into historic stone alleys, ancient cellars, or street food stalls with spotty or nonexistent Wi-Fi. BistroLocal AI runs 100% on a laptop or local terminal without requiring an internet connection.
Absolute Recipe Confidentiality: Chefs will not compromise their intellectual property. With open-weight models running on local hardware, sensitive recipe formulations never traverse the internet or get fed into closed cloud training sets.
Infinite Margin Economics: In closed-API architectures, your recurring cost scales linearly with usage. Every menu tweak or translation request drains tokens. With open-source models, your marginal cost is $0.00. This makes a $39/month SaaS fee almost 100% pure profit.
No Vendor Lock-In or Sudden Price Hikes: Closed APIs deprecate endpoints, change pricing tiers, or enforce restrictive content filters on cultural dish names. With open-weight AI, the model belongs to the restaurant owner forever.

💬 My First User

To test BistroLocal AI in the real world, I visited Marco, the owner of a small Roman-style trattoria in my local area that gets heavy foot traffic from international university students and tourists.

What Happened:

I uploaded his 12-item pasta and secondi menu into BistroLocal AI. Within seconds, his dishes were translated into Japanese, Spanish, and French, complete with authentic pronunciations and cultural origin notes.

When Marco saw how the system flagged the Pecorino cheese for dairy allergies, the guanciale for non-Halal pork warnings, and the tonnarelli for gluten—and then saw the Guest QR View allow diners to filter dishes with a single tap—his eyes lit up:

"Every Friday night, my waitstaff spends 15 minutes per table trying to explain in broken English what guanciale is and whether the pasta has nuts in it. This QR menu answers all of it before the waiter even reaches the table."

Did he pay?

Marco agreed to test the QR codes on 5 of his tables for the weekend. He said:

"If this saves my servers from having to explain the menu to tourists every rush, I'd gladly pay $35 or $40 a month. What I really want next is a one-click button to print daily seasonal specials straight from the iPad."

That feedback confirmed the core thesis: real businesses will gladly pay for small, specific, and privacy-respecting AI tools that solve their everyday operational headaches.

🏆 Prize Categories

I am entering BistroLocal AI for the following partner prize categories:

1. Best Use of TabPFN ($200 USD)

We used Prior Labs' TabPFN-3.5 foundation model (tabpfn-client) inside our prediction engine to forecast tourist dish preferences, assess kitchen allergen escalation risks, and predict prep quantities from historical dining CSV tables. The system connects to the TabPFN platform while maintaining a robust local tabular fallback.

2. Best Use of Render ($200 USD)

We configured a production-ready Render Blueprint (render.yaml) and optimized containerized Dockerfile for instant 1-click cloud deployment on Render's Web Service platform.

Built with open-source AI, local open-weight models, and TabPFN for Hacktoberfest 2026. 🚀

I built a self-hosted gig watcher so I stop refreshing job boards — it only pings me on new matches

earnnova-dev — Tue, 13 Oct 2026 19:13:30 +0000

Freelancers lose real money to latency. The best remote gigs get filled in the first few hours — the "Senior Backend Engineer, $120k, fully remote" posting is usually taken before you finish your second coffee. So we all do the same embarrassing thing: keep 6 job boards open and refresh every 15–20 minutes, mostly seeing the same 300 stale listings.

I got tired of it, so I built GigWatch — a small, self-hosted watcher that monitors live job/gig feeds, filters them against your skills, remembers what it has already shown you, and pings you (console, email, or Slack) only when a new matching gig actually appears. No dashboard to babysit. No account to sign up for. Just a process on a machine you already run.

Install is one line:

pip install gigwatch-nova

It's Python 3.9+, self-hosted, and pulls from free, keyless job endpoints (Remotive, We Work Remotely, RemoteOK, Jobicy, Hacker News, plus any RSS feed you point it at). No API keys.

The whole idea in four steps

GigWatch does one loop, on a timer you control (default 15 min):

Fetch — pull live listings from each configured source.
Score — match each listing against your skills/title/keywords and score the fit (0–10).
Dedup — compare against a local state file of everything it has already shown you. This is the part that makes it not-spammy.
Alert — only fire (console line, email, or Slack) for new matches above your score floor.

The dedup step is the whole point. A job board shows you the same 300 listings forever; GigWatch shows you a listing exactly once, and only if it matches your profile.

The config you actually write

Everything is a single JSON file. A realistic one looks like this:

{
  "sources": [
    { "type": "remotive" },
    { "type": "wwr" },
    { "type": "remoteok" },
    { "type": "jobicy" },
    { "type": "hn" },
    { "type": "rss", "url": "https://www.python.org/jobs/feed/rss/", "limit": 100 }
  ],
  "profile": {
    "title": "Senior Software Engineer",
    "skills": ["python", "backend", "api"],
    "location": "remote",
    "notes": "senior, $150k+"
  },
  "filters": {
    "keywords": ["python", "backend", "api", "django", "fastapi"],
    "require_all_keywords": false,
    "min_score": 1.0,
    "exclude_keywords": ["intern", "junior"]
  },
  "alerts": {
    "console": true,
    "email": {
      "to": "${GIGWATCH_EMAIL_TO}",
      "smtp_host": "smtp.example.com",
      "smtp_port": 587,
      "use_tls": true,
      "username": "${GIGWATCH_SMTP_USER}",
      "password": "${GIGWATCH_SMTP_PASS}"
    },
    "slack": { "webhook_url": "${GIGWATCH_SLACK_WEBHOOK}" },
    "max_per_alert": 25
  },
  "state_file": "gigwatch-state.json",
  "poll_interval": 900
}

A few things I'd tune before you trust it:

exclude_keywords is your friend. "intern", "junior", "contract-only" — whatever you will never want, put it here.
min_score is the noise dial. Start at 1.0, bump it up if you're still getting too much.
require_all_keywords — set it to true if you only want listings that hit every one of your keywords (much quieter, fewer false positives).
Secrets go in env vars (${GIGWATCH_SMTP_PASS}), not in the JSON. That keeps your config file safe to commit.

Why it's not another job board

The free endpoints that power it are keyless and public — they're the same feeds a job aggregator would use. That's a strength (nothing to register, nothing to break auth on) and a known limitation, so let me be honest about what it covers and what it doesn't:

✅ Remotive, We Work Remotely, RemoteOK, Jobicy, Hacker News, and any RSS feed you add.
✅ Any board that exposes a JSON or RSS feed you can point it at.
❌ Upwork, LinkedIn, and other gated platforms that require a logged-in account. Those need authenticated scraping, which is a whole separate (and fragile) project. GigWatch is built for the open feed world on purpose.

If most of your gigs come from a gated platform, the open-feed watcher is still useful as a secondary channel — it catches the listings the gated boards re-post, which is often a meaningful share.

The CI version: let a schedule post matches as an Issue

If you'd rather not run a daemon, I ship a GitHub Action. It fetches live jobs filtered by skill and returns them as Markdown, so a scheduled workflow can open a fresh Issue (or PR comment) with the day's new matches. No API keys — it's powered by the same free feed:

name: gig-watch
on:
  schedule:
    - cron: "0 7 * * *"   # 07:00 UTC daily
  workflow_dispatch:

jobs:
  scan:
    runs-on: ubuntu-latest
    steps:
      - name: Scan feeds for matching gigs
        uses: earnnova-dev/gigwatch@main
        id: scan
        with:
          skills: python,backend,api
          limit: 20
          min_score: 1.0

      - name: Open an issue with the matches
        if: steps.scan.outputs.job_count > 0
        uses: actions/github-script@v7
        with:
          script: |
            github.rest.issues.create({
              owner: context.repo.owner,
              repo: context.repo.repo,
              title: `New matching gigs (${context.run_id})`,
              body: `${{ steps.scan.outputs.markdown }}`
            })

Point it at your own repo, and every morning you get a clean, searchable Issue of the day's new matching gigs. The state file makes the action idempotent, so it only ever posts new stuff.

Honest limitations

It's a watcher, not a scraper-with-everything. You host it; it does not phone home.
Feed coverage is limited to what's publicly keyless. Gated platforms are out of scope by design.
It scores by keyword overlap, not by an LLM. Good enough to filter noise; not a replacement for actually reading the listing.

Install

pip install gigwatch-nova

Requires Python 3.9+. Drop in a config.json like the one above, point state_file somewhere writable, and run it under cron or your scheduler of choice. If the whole "watch the open feeds, dedup against what I've seen, ping me on new matches" thing matches your workflow, it's a few minutes to stand up — and your browser tabs can finally close.

DEV Community: opensource

My Hacktoberfest 2026 Journey: Getting Started with Open Source

My Hacktoberfest 2026 Journey: Getting Started with Open Source

What I Want to Learn

Technologies I'm Interested In

Looking for Recommendations

hacktoberfest #opensource #beginners

New stricter rules from GitHub for code packages after security investigation

What's changing in software publishing

What should creators do?

Argon2id Security for Self-Hosted AI Wallets: CLI Master Password Best Practices

Argon2id Security for Self-Hosted AI Wallets: CLI Master Password Best Practices

Why the Master Password Is the Root of Everything

The Auto-Provision Path: Getting Started Without Foot Guns

Docker Secrets: The Production-Grade Approach

What masterAuth Actually Protects

Policy as Defense-in-Depth

The Self-Hosted Philosophy in Practice

Quick Hardening Checklist

What's Next

ProofCheck: checking UPI payment screenshots against the bank statement, on your own laptop

What I Built

Demo

Code

Surge77 / proofcheck

Check UPI payment screenshots against your bank statement with local open-weight models (Gemma + RapidOCR). Your statement never leaves your laptop.

ProofCheck

What it tells you

How I Built It

Things that bit me

Why Does Open Innovation Matter?

Prize Categories

Building a Live 3D & 1M-Token Engineering Cookbook with Google DeepMind's Gemini 4 Argon

Try the Live 3D Demos in Your Browser

1. Unifying 1M Input & 1M Output Tokens (Long-Decode Continuation Protocol)

2. First-Class thought Steps & Cryptographic Signatures

3. Built-From-Scratch 3D Engines & Interactive WebGL Simulations (87% ERQA SOTA)

A. Procedural 5-Tier 3D Pagoda Temple (.OBJ Generator + Live WebGL)

B. Interactive 3D Crystalline Shatter & Voxel Physics Arena

C. 6-DOF 3D Robotics Inverse Kinematics & Ballistic Simulator

D. 100% Pure-Python Zero-Dependency 3D Ray-Tracing Engine

4. Multimodal Image & Video -> 3D Scene Graph Reconstruction

Quick Start

What Are You Building First?

Local AI on a Mac: what one open source app runs on Apple Silicon, and what it does not

What you need

Install

Local chat with an LLM

Local image generation without ComfyUI

Local image editing

LoRAs on the Mac

Character LoRA training: not locally on a Mac

Local video generation

What Create does not do locally on a Mac

Voice mode

Local computer control

Coding agent

Not confirmed on macOS

Short version

Revolutionizing CAD: Why CADCraft is the Open-Source AutoCAD Alternative You Need!

Quick Summary: 📝

Key Takeaways: 💡

Project Statistics: 📊

Tech Stack: 💻

Learn More: 🔗

🌟 Stay Connected with GitHub Open Source!

Aurelio Pairs Local Finance Records With an Optional AI Adviser

A ledger for assets, liabilities and goals

The adviser introduces a second boundary

ShopCraft AI: High-Converting Etsy & Shopify Listings Powered by Gemma 2

What I Built

Who Would Pay for It?

Demo

Code

rumparoy3012-ops / shopcraft-ai

How I Built It

Why Does Open Innovation Matter?

1. Sustainable Micro-SaaS Unit Economics

2. Protecting Proprietary Seller IP

3. Model Independence & Longevity

2. First-Class `thought` Steps & Cryptographic Signatures

A. Procedural 5-Tier 3D Pagoda Temple (`.OBJ` Generator + Live WebGL)

1. Local Open-Weight Culinary Translation Engine (`backend/engine/translator.py`)

2. Big-14 Allergen Guardian (`backend/engine/allergen_detector.py`)

3. TabPFN-3.5 Tabular Intelligence Agent (`backend/engine/tabpfn_predictor.py`)