AdRouter

AdRouter is a monetization layer for AI, helping users and developers offset inference costs with clearly labeled, privacy-preserving sponsored placements.

Comment

AdRouter Hackathon Writeup

Inspiration

Intelligence is becoming a premium commodity. As AI moves from novelty to daily infrastructure, the best models are still gated by subscriptions, API bills, and platform lock-in. That hurts casual users, but it also hurts the indie developers and small teams building wrappers, agents, and vertical AI tools on top of frontier models.

At the same time, brands are trying to reach people in an AI-first discovery flow, where high-intent questions happen inside chat interfaces instead of search result pages. We saw a missing link between these needs: developers need a way to subsidize inference, users need cheaper access to useful models, and businesses need privacy-respecting access to relevant moments of intent.

AdRouter was built to explore that overlap. It turns transparent, auditable sponsored compute into a way to offset AI inference costs without letting sponsors alter the model's answer.

What it does

AdRouter is a revenue-aware AI gateway for AI apps. It sits between a user interface and an LLM, routes prompts through a semantic sponsorship layer, and returns two things separately:

  1. The model's answer, streamed independently.
  2. A clearly labeled ad payload and settlement object that the frontend can render around the answer.

The current demo supports three sponsored-compute tiers:

  • Tier A: Inline contextual citation for high-relevance sponsor matches.
  • Tier B: Parallel sponsored agent panel for medium-relevance commercial intent.
  • Tier C: Thinking-time banner for broad baseline subsidization.
  • NONE: Privacy guardrail route for sensitive categories such as health, finance, legal, or politics.

The frontend includes a consumer chat experience, a Compute Wallet that shows prompt cost, ad subsidy, and final paid amount, a developer API page with endpoint docs and a sandbox, and a business dashboard where sponsors can add campaigns and verify that a relevant prompt triggers the loop.

How we built it

We built the router backend in TypeScript with Express, using the Vercel AI SDK and an OpenAI-compatible DeepSeek live model path. When a DeepSeek API key is not configured, the backend runs in mock mode so the full routing, tiering, guardrail, and settlement pipeline can still be demonstrated without live API spend.

For semantic routing, prompts are embedded and matched against a sponsor database. The implementation supports OpenAI text-embedding-3-small for real embeddings, with a deterministic mock embedding and keyword fallback for local demos. Sponsors are stored in a JSON-backed in-memory cache for the hackathon version, with a POST /api/sponsors/add endpoint that embeds and persists new sponsor records.

The frontend was built with Vite, React 19, TypeScript, Tailwind CSS, React Router, Motion, and Lucide icons. It handles both backend response modes: JSON in mock mode and streamed AI SDK data in live mode. The ad payload can arrive before the model finishes responding, which lets the UI render sponsored components in parallel with the answer instead of blocking the chat.

We also built a separate public-facing waitlist site with role-specific flows for users/developers and businesses/advertisers, backed by a small TypeScript waitlist API and SQL migration.

Challenges we ran into

The biggest challenge was preserving trust. A naive version of AI advertising would inject sponsor data into the model prompt, but that risks biasing the answer, creating hallucinations, and breaking user confidence.

We solved this by separating the ad path from the model path. The sponsor match is computed as metadata, while the LLM receives only the user's request plus the server-owned objective system prompt. Client-supplied system messages are stripped before reaching the model, and sponsor content is rendered by the UI instead of being placed into the model context.

We also had to make the router fast enough for a chat experience. Running a separate LLM call just to classify intent would add latency and cost, so the current implementation uses lightweight embeddings, keyword fallback signals, and tier thresholds. The backend sends the ad payload before stream completion, and the final settlement is calculated after token usage is known.

Another challenge was making the demo honest without requiring live keys. Mock mode still runs the same guardrail, sponsor matching, tier override, and wallet math, which let us prove the interaction model before depending on external provider configuration.

Accomplishments that we're proud of

We built an end-to-end sponsored-compute loop rather than just a landing page. A business can create an ad, verify it in chat, and see the user-facing sponsored component render alongside a Compute Wallet settlement.

We are especially proud of the separation model. The ad never needs to enter the LLM prompt, so sponsored compute can reduce cost without changing the objective answer path. The implementation also includes sensitive-topic guardrails, tiered UI surfaces, mock/live mode detection, developer-facing API docs, and a sandbox that makes the protocol easy to understand.

The Compute Wallet is another key piece. It turns the business model into something visible: users can see prompt cost, subsidy, and paid amount instead of trusting an invisible ad network.

What we learned

We learned that AI-native advertising cannot be a copy-paste version of web banners. In chat, trust is the product. Sponsored content has to be labeled, optional, auditable, and technically separate from the model's reasoning.

We also learned that developer adoption depends on the API contract being simple. The app cannot require every developer to redesign their whole stack. The gateway needs to return the normal model response plus a small, typed ad and settlement payload that developers can render however their app requires, as long as transparency rules are preserved.

Finally, we learned that monetization logic needs guardrails from day one. Sensitive categories should route without ads, raw prompts should not be sold to advertisers, and cost settlement should be based on real usage rather than vague impressions.

What's next for AdRouter

Our first product priority is expanding model coverage. The current live path is built around DeepSeek with OpenAI embeddings, but the gateway is designed to become provider-agnostic. We want to work directly with model providers and aggregators to add more options across frontier, reasoning, fast, and budget models so developers can choose the right cost-performance tradeoff per request.

Next, we want to reach businesses, SaaS companies, and indie developers who already have strong intent-driven offers. Early sponsor supply will focus on categories where users naturally ask for recommendations, tools, software, travel, productivity, ecommerce, education, and developer services. For these partners, AdRouter offers a new placement surface: not broad demographic targeting, but privacy-preserving relevance at the moment a user is actively solving a problem.

We also plan to promote the platform and API to measure real user interest. That means launching the waitlist, sharing the demo with indie AI builders, testing developer API onboarding, and validating whether users are comfortable trading transparent sponsored placements for lower AI costs. The goal is to learn which audiences care most: users who want cheaper model access, developers who need inference-cost relief, or businesses looking for AI-native acquisition channels.

After that, the technical roadmap is to move from mocked sponsor inventory to live affiliate and campaign APIs, add authentication and fraud-aware settlement, improve guardrail coverage, persist analytics, and package the rendering layer as a lightweight SDK for third-party AI apps.

Finishing thoughts

Frankly, this project was extremely rushed, though we had this idea for a long while. We just needed a little push that told us it was worth building and committing to. We sincerely hope that even if we don't succeed with the current team, another will take this torch and pursue the journey for cheaper intelligence, for everyone.

Built With

Share this project:

Updates

Submission history