amal66 turns Mike into a bring-your-own-engine platform

The fork rebuilds how Mike connects to AI models and file storage so swapping either one becomes a small, contained job instead of open-heart surgery.

infrastructureintegration

Most forks bolt on a feature. amal66 went deeper, reworking the seams where Mike plugs into its AI engine and its document storage. The result is that adding a new AI provider or a new place to keep files is a drop-in change that doesn't touch the core - the kind of plumbing that quietly decides whether a codebase can grow with you or fights you at every turn.

To prove it wasn't just theory, the same work ships two real examples: Google Cloud for both storage and its Gemini models, plus a setup for running AI models on your own hardware. Both slotted in cleanly, with tests, and without disturbing anything underneath.

So what Anyone who can't or won't be locked to a single AI vendor or cloud - for cost, data-residency, or procurement reasons - should look at this fork first.

View this fork on GitHub →

Spotted something wrong? Or know the PR text has fresher detail than the writeup above?

Commits in this thread

2 commits from amal66/mike, oldest first. Source extracted verbatim from the harvested git log.

SHA Subject Author Date
f98c2092 refactor: provider registry, storage adapter, table-driven api-key lookup Amal 2026-05-24 ↗ GitHub
commit body
Implements three open-source extensibility primitives so adding a new LLM
provider, storage backend, or law-library integration is a single-file
operation with no edits to core dispatch logic.

**LLM provider registry** (lib/llm/registry.ts)
- LLMProviderAdapter interface: id, matchesModel, stream, complete, models
- registerProvider() / findProviderForModel() / allRegisteredModels()
- Built-in providers (Claude, Gemini, OpenAI) self-register in index.ts on
  load; Vitest mock hoisting still captures them so retryCircuit tests pass
- providerForModel() checks registry first, then falls back to prefix
  heuristics - external providers override routing with zero core edits
- resolveModel() checks live registry union then static ALL_MODELS fallback
  (derived from *_MODELS spreads, not hand-maintained)
- Dispatch in streamChatWithTools / completeText: registry lookup + explicit
  throw on missing adapter - no silent fallthrough
- registerProvider() re-exported from lib/llm for consumer convenience
- Example: lib/llm/providers/ollama.ts shows full third-party integration

**Storage adapter pattern** (lib/storage/adapter.ts + r2.ts)
- StorageAdapter interface: upload, download, delete, getSignedUrl, checkReady
- R2StorageAdapter implements the interface with singleton S3Client
- lib/storage.ts gains setStorageAdapter() - swap to Supabase Storage, local
  filesystem, AWS S3, or MinIO with zero changes to any route or middleware
- All original function exports preserved with identical signatures

**Table-driven API-key lookup** (core/apiKeyProviders.ts)
- Provider env-var names live in a Map, not in a switch statement
- registerApiKeyProvider() lets new providers declare their env vars once
- getUserApiKeyStatus() and getUserApiKeys() iterate getRegisteredProviders()
  so a fourth provider appears in both automatically - no literal-object edits
- UserApiKeys index signature extended so third-party keys flow through
  without type changes

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
57c1c1b5 feat(google-cloud): GCS storage adapter + Vertex AI Gemini provider (#2) Amalanand Muthukumaran 2026-05-24 ↗ GitHub
commit body
* feat(google-cloud): GCS storage adapter + Vertex AI Gemini provider

Adds two drop-in Google Cloud integrations following the existing
extension points (StorageAdapter + LLMProviderAdapter) so no core files
needed editing beyond exporting the new classes.

**GCS storage adapter** (lib/storage/gcs.ts)
- Implements the StorageAdapter interface backed by @google-cloud/storage
- Auth via Application Default Credentials - covers service account key
  files (GOOGLE_APPLICATION_CREDENTIALS), Workload Identity on GKE /
  Cloud Run, and gcloud CLI for local dev (zero secrets to manage)
- Enabled when GCS_PROJECT_ID or GOOGLE_APPLICATION_CREDENTIALS is set
- Signed URLs use V4 signing; Content-Disposition header supported
- Swap R2 for GCS with one setStorageAdapter() call at startup:
    import { setStorageAdapter } from "./lib/storage";
    import { GCSStorageAdapter } from "./lib/storage/gcs";
    setStorageAdapter(new GCSStorageAdapter());

**Vertex AI Gemini provider** (lib/llm/providers/vertexAI.ts)
- Routes all Gemini model IDs through Google Cloud Vertex AI instead of
  AI Studio - same model IDs, different billing + auth + data residency
- Uses @google/genai (already a dep) with vertexai: true mode - no new
  package required
- Auth via ADC: Workload Identity on GKE/Cloud Run, or
  GOOGLE_APPLICATION_CREDENTIALS locally
- Replaces the built-in gemini provider on re-registration (same id):
    import { setupVertexAI } from "lib/llm/providers/vertexAI";
    setupVertexAI();

**Tests**: 23 new tests (16 GCS adapter, 7 Vertex AI provider); full
suite 151 tests passing.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

* docs(readme): rewrite as setup and contribution guide

The previous README was a project retrospective - design rationale,
open-source bets, a 40-row change index - with the actual setup steps
buried partway through. This rewrites it as a task-oriented doc:

- Quick Start: clone → install → env → database → run (5 steps)
- Configuration: all env vars grouped by category with descriptions
- Extending Mike: concrete code snippets for each extension point
  (custom LLM provider, Vertex AI, GCS, custom storage, law library
  plugins, Python SDK)
- Development: test/lint/build/typecheck commands in one place
- Troubleshooting: the four most common issues
- Contributing: short version inline, CONTRIBUTING.md for the rest

The commit history and design rationale move to a collapsed footnote
(<details> block) so they're available without dominating the page.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

---------

Co-authored-by: Claude Sonnet 4.6 <noreply@anthropic.com>

Capture this thread into my fork

Download a single Markdown prompt that tells Claude how to port every commit above into your working tree — adapting paths and structure to match your repo. Run it via claude -p < capture-thread-598.md from inside the repo you want the changes in.

⬇ Download capture-thread-598.md