This site
How this site works
This site is also a project. I built the chat backend and operate the gateway on a Mac mini at home. It connects the website to a third-party AI provider, adds the public information the assistant can draw on, and streams replies back to your browser.
Putting a text box in front of a model is the easy part. Most of the work went into what happens when one link in that chain is down.
The path of one question
- 01
Your browser
You type a question into the chat, or paste a job description on the comparison page.
- 02
Bot verification
A silent check that the request comes from a person. Requests that do not pass do not reach the live model; they get pre-written answers instead.
- 03
Request validation
The request is size-checked and shape-checked at the edge. Anything unexpected is dropped before it goes further.
- 04
Authenticated connection
An authenticated, encrypted connection from the site host to the gateway at my house.
- 05
Home-server gateway
A Mac mini I operate. It applies per-visitor and global usage limits, pins the model, caps the reply length, adds the public material the assistant can draw on, and writes each conversation to a log.
- 06
AI provider
The gateway sends the prompt to a third-party AI provider, which generates the reply. No model runs on the Mac mini itself.
- 07
Streamed reply
The answer streams back through the same chain to your screen, a few words at a time.
Design decisions
What I designed, built, and run
The gateway service, its usage limits and persistence, the connection between the site and my house, the monitoring that messages me when a layer goes down, the nightly evaluation that checks answer quality, and the prompt and knowledge material the assistant answers from. The model itself is a provider's.
Usage controls run on hardware I control
Serverless functions restart constantly, so any rate-limit state kept there gets wiped. The quotas, caps, and kill switch run on the home server, where state persists and nothing gets in without a shared secret.
It degrades instead of breaking
When the live service is unavailable, because the home server is off, the connection is down, or the day's budget is spent, the site shows clearly labeled pre-written answers and still links to the underlying pages. Nobody sees an error page.
Unverified requests never reach the model
Requests that do not pass bot verification get the pre-written answers. Model usage is spent only on verified visitors, inside per-visitor and per-day limits.
The prompt guides behavior; the server enforces limits
The prompt tells the assistant what to talk about and how to write. Authentication, request validation, and usage limits are handled server-side, so they hold regardless of what the prompt is asked to do.
What gets logged
Each conversation is stored on the home server with the visitor's IP address, approximate location, and browser type. I can review them, and a daily summary of the questions asked is sent to me. The details are on the privacy page.
Ask from your own agent
The same backend is available as a remote MCP server, so your own agent can ask about me without opening this site. In Claude Code:
$ claude mcp add --transport http \
ask-nikhil \
https://www.nikhilkaul.com/api/mcpIt exposes one tool, ask_nikhil(question), with the same limits and logging as the chat. I launched an open-source set of agent skills for Kubernetes at work, so making myself installable felt consistent.
What this page leaves out
This page covers the architecture and tradeoffs. It leaves out private operational details: vendor names, endpoints, model identifiers, rate-limit numbers, and connection details. If you want the rest, email me at nkaul2345@gmail.com.