Skip to content
← Back to projects Active · AI Gateway / Personal Infrastructure

NestyAI Ecosystem

Personal AI gateway, model routing, tool execution, memory, search, provider fallback, and API compatibility — behind one consistent interface.

View architecture Back to projects

Overview

NestyAI is a personal-first AI gateway ecosystem designed to route requests between cloud AI providers, tools, memory, search, and safety layers. It is not meant to be a generic portfolio demo; it is a real personal backend architecture experiment.

Why I built it

  • 01

    Self-hosting local LLMs 24/7 is expensive.

  • 02

    Cloud APIs are fast and flexible.

  • 03

    A gateway gives control over routing, tools, safety, memory, and provider fallback.

  • 04

    Personal projects can reuse the gateway later.

Core modules

  • Gateway API

  • Provider Router

  • Tool Intent Router

  • Retrieval Recovery

  • Memory System

  • Search Integration

  • Guardrails

  • OpenAI-Compatible Layer

  • Diagnostics / Health Checks

  • Console-ready Architecture

Repositories

NestyAI is split across separate GitHub repos in its own organization. Each repo links directly below.

NestyAI GitHub ↗

NestyAI

Core AI gateway — model routing, tool execution, memory, search, provider fallback, guardrails & an OpenAI-compatible API.

  • FastAPI
  • Python
  • SQLite
NestyAI GitHub ↗

NestyConsole

Web console / control plane for the gateway — runtime provider config, orchestration roles, and an operational UI.

  • Console UI
  • BFF
  • Ops
System Flow

Request lifecycle

User RequestNestyAI GatewayIntent RouterTool SystemWeb SearchMemoryProvider FallbackGuardrailsFinal Response
  1. 01

    Input enters the gateway

    A request hits the NestyAI Gateway through a single OpenAI-compatible entry point.

  2. 02

    Intent routing

    The Intent Router decides whether to use tools, memory, search, or a direct model response.

  3. 03

    Enrichment

    Tool System, Web Search, and Memory can enrich the request before generation.

  4. 04

    Provider fallback

    Provider Fallback selects the best available model / provider path, health-aware.

  5. 05

    Guardrails

    Guardrails clean and normalize the final output into a safe, consistent shape.

  6. 06

    Final response

    The normalized response returns to the user through the same compatible interface.

Tech stack

  • Python
  • FastAPI
  • SQLite
  • Provider APIs
  • Tool Registry
  • Search / Retrieval
  • Testing
  • OpenAI-Compatible API shape

Lessons learned

  • 01

    Routing needs strict intent validation.

  • 02

    Retrieval should recover when tool routing fails.

  • 03

    Provider fallback should be health-aware.

  • 04

    Memory requires controls and safety.

  • 05

    Public API compatibility needs stable errors and metadata.

Future direction

  • Nesty Console
  • NestyChat Web
  • NestyChat Android
  • More advanced memory controls
  • Better diagnostics
  • UI dashboard
  • Safer external API key usage