Projects

A decision model answers the same fixed questions for every release, as probabilities. It began as an experiment on whether that reading could predict post-earnings returns. On 1,529 releases it could not, and the site's method page reports that null result. What the model did well was read, so the product is the reading: on demand for any company, plus 2,200+ releases from 99 S&P 100 companies since 2021 that feed the market trends, with an agreement check against a second reader.

A FastAPI service on Google Cloud Run serves both the static Astro site and the API from one container. For a new company it finds the latest 8-K filings on EDGAR, cleans the press release, scores it through the Perplexity Decisions API and stores the reading in Cloud Storage, so each filing is paid for once. Spending is capped per request, per day and in total. Everything is run by hand from a Makefile.

A retriever (BM25 over keyword overlap - no vector database needed for a handful of documents) pulls the most relevant chunks from my CV and other notes, a persona layer combines them with a fixed "who I am" prompt, and a single call to Claude generates the answer. Layered backend architecture (controllers / domain / infrastructure / service layer), deployed on Google Cloud Run with the API key kept in Secret Manager.

The chat widget itself (this component) is framework-free - a small Astro component with vanilla JS calling the backend's POST /chat endpoint directly from the browser, CORS-locked to this site's origin.

Every experiment plots three panels side by side (teacher, student trained on hard labels only, and an architecturally identical student distilled from the teacher), so instead of comparing accuracy numbers you can literally see the boundary each model settled on. On datasets with a real "void" (regions with no training data, like the XOR-blobs case pictured), the no-KD student and the teacher resolve the ambiguity differently, while the KD student, trained on extra teacher-labeled query points sampled from that empty region, reproduces the teacher's exact boundary almost perfectly.

Two further experiments (overlapping blobs, a biased teacher) show the same mechanism from the opposite angle: when there's no void to fill, KD instead transfers the teacher's calibration, flaws included, like overconfidence or a spurious shortcut feature. The README argues that this is structurally the same effect behind why sequence-level distillation works for LLMs, not just a toy analogy.

A single structured-output call to Claude plans the whole job: it breaks a prompt into a dependency graph of subtasks, assigns each one the cheapest model tier that can handle it, and is explicitly told that decomposition isn't free (every extra call has its own overhead), so it only splits work when parallelism or a cheaper tier is actually worth it.

The executor groups subtasks into dependency-respecting "waves" and fires every subtask in a wave concurrently via asyncio, so a wave takes as long as its slowest call rather than the sum of all of them; a final synthesis call stitches independent results back into one answer. Every call (planner, subtasks, synthesis, and a single-model baseline for comparison) logs its own tokens, cost, and latency, so the routed pipeline can be benchmarked against just sending the whole prompt to one large model.

Most "chat with your PDFs" tools reach for a full RAG stack (a vector database, an embedding model, a chunking/retrieval/reranking pipeline) even for a handful of documents. This project takes the opposite approach for small, stable document sets: extract the text (and describe any embedded images via Claude Vision), turn it into a Q&A training set, and LoRA fine-tune LittleLamb directly on the content. LittleLamb is a 290M-parameter model built by Multiverse Computing from Qwen3-0.6B, state of the art for its size class.

The result runs entirely offline on a laptop CPU: a FastAPI server exposes an OpenAI-compatible endpoint, and a Streamlit chat UI lets you ask questions the model answers straight from what it learned. No retrieval step, no infrastructure.

Every 5 minutes, Cloud Scheduler hits a FastAPI heartbeat endpoint on Cloud Run, which asks Claude to decide what the agent should do next, persists its evolving state to Firestore, and posts back to Moltbook through a small API client. It is a self-registering agent that runs unattended, with no human in the loop.

Secrets never touch the codebase: API keys live in Secret Manager, and the service itself runs with --no-allow-unauthenticated so only Cloud Scheduler's OIDC token can ever trigger it.

A full-stack side project built end to end: a Domain-Driven Design REST API, a PostgreSQL data layer, a React Native/Expo mobile client, and a second Flask/DDD service that calls Gemini to turn raw GPS coordinates into narrated points of interest (historical context, nearby landmarks, recommendations) on demand, in five languages.

It's the oldest project here and the one currently being actively rebuilt: the core AI pipeline and API already work end to end, the mobile app has its navigation shell in place, and the landing page is the next piece to build.