One unified API for Gemini, OpenAI, Anthropic, HuggingFace, Ollama, on-device Gemma, and GGUF models — with tool calling, memory, and safety guardrails built in.
The Problem
Building AI agents in Flutter is fragmented. Every provider has a different API shape. There's no standard way to switch between cloud and on-device inference. Tool calling, persistent memory, and safety guardrails are always custom implementations.
The result: developers rebuild the same plumbing for every project.
What It Is
genesis_ai_sdk is a universal Flutter SDK for building AI agents that run locally and in the cloud. One clean API. Seven providers. Zero vendor lock-in.
Supports:
- Gemini (Google)
- OpenAI (GPT-4o)
- Anthropic (Claude)
- HuggingFace (any public model, no download needed)
- Ollama (local server, no API key)
- On-device Gemma (fully offline)
- On-device GGUF via llama.cpp (fully offline)
Switch providers by changing one line. Your agent code stays the same.
Quick Start — 10 Lines of Code
import 'package:genesis_ai_sdk/genesis_ai_sdk.dart';
final agent = GenesisAgent(
provider: GeminiProvider(apiKey: 'YOUR_KEY'),
systemPrompt: 'You are a helpful assistant.',
tools: [GenesisTools.calculator, GenesisTools.dateTime],
);
final response = await agent.chat('What is 1337 * 42, and what day is it?');
print(response);
The agent figures out which tool to call, executes it, and returns the answer. No prompt engineering needed.
The Features That Actually Matter
Real Tool Calling — Not Just Text
The ReAct loop is fully implemented. The agent reasons → calls tools → observes results → repeats until it has a complete answer. An onStep callback fires for every intermediate step — perfect for building a "thinking…" UI.
Custom tools are five lines:
final weatherTool = GenesisTool.define(
name: 'get_weather',
description: 'Returns weather for a city.',
params: {'city': ToolParam.string(description: 'City name')},
execute: (args) async => fetchWeather(args['city']),
);
Any HuggingFace Model — No Download
final agent = GenesisHub.fromHFCloud(
modelId: 'Qwen/Qwen2.5-0.5B-Instruct',
apiToken: 'hf_xxxx',
);
final reply = await agent.chat('Explain transformers in one sentence.');
The HF Inference Router supports virtually all public HuggingFace models via multiple GPU backends (featherless, nebius, together, sambanova). No model download, no conversion, no GPU on your end. Free tier available with any HF account.
Fully Offline — On-Device Models
For privacy-sensitive apps or zero-connectivity scenarios, run everything on-device.
For Gemma (Android, iOS, macOS, Windows):
final provider = GemmaProvider(
modelId: 'gemma-3-1b-it',
modelPath: await GenesisHubPlatformPaths.platformModelsDir(),
);
For GGUF via llama.cpp (Android, macOS, Windows, Linux):
final provider = LlamaCppProvider(modelPath: '/path/to/model.gguf');
platformModelsDir() returns the correct writable path on every platform automatically — no more hardcoded paths that break on Android.
Memory That Survives App Restarts
For in-process memory (current session only):
memory: InMemoryStore()
For persistent memory that survives app restarts (backed by Hive):
memory: HiveMemoryStore(sessionId: 'user_${userId}')
Safety Layer Built In
Block prompt injection before it reaches the model:
final clean = InputGuard.withInjectionDetection().validate(userInput);
Redact PII from model responses (emails, phones, credit cards):
final safe = OutputGuard.withPiiRedaction().process(rawOutput);
Rate limiting per user:
RateLimiter(maxRequests: 20, windowDuration: Duration(minutes: 1)).check(userId);
Smart Routing and Fallback
Automatic fallback if the primary provider fails:
final router = SmartRouter(
primary: GeminiProvider(apiKey: '...'),
secondary: OllamaProvider(model: 'llama3.2'),
);
Privacy-first routing — anonymise sensitive fields before they leave the device:
final router = PrivacyRouter(
cloudProvider: OpenAIProvider(apiKey: '...'),
sensitiveKeys: ['email', 'phone', 'ssn'],
);
The GenesisHub — One Line for Everything
From HuggingFace cloud (no download):
GenesisHub.fromHFCloud(modelId: 'Qwen/Qwen2.5-0.5B-Instruct', apiToken: '...')
From a local model file (auto-detects .gguf / .litertlm / .task):
GenesisHub.fromFile('/path/to/model.gguf')
From Ollama:
await GenesisHub.fromOllama(model: 'llama3.2')
From HuggingFace with auto-download:
await GenesisHub.fromHuggingFace(repoId: 'litert-community/Qwen3-0.6B', filename: 'model.litertlm', destinationDir: dir)
Platform Support
| Platform | Cloud | Ollama | Gemma | GGUF |
|---|---|---|---|---|
| Android | ✅ | ✅ | ✅ | ✅ |
| iOS | ✅ | ✅ | ✅ | ⚠️ (xcframework needed) |
| macOS | ✅ | ✅ | ✅ | ✅ |
| Windows | ✅ | ✅ | ✅ | ✅ |
| Web | ✅ | ❌ | ❌ | ❌ |
| Linux | ✅ | ✅ | ❌ | ✅ |
Installation
Add to your pubspec.yaml:
dependencies:
genesis_ai_sdk: ^0.1.0
Then run:
flutter pub get
What's Next
This is v0.1.1. On the roadmap:
- genesis_ai_ui — Flutter UI components that render dynamically based on AI responses
- genesis_ai_tools — real-world device tools: camera, location, contacts, clipboard
- Semantic memory with vector search
- Mistral, Groq, Cohere providers
Links
- pub.dev: https://pub.dev/packages/genesis_ai_sdk
- GitHub: https://github.com/Devanshv17/genesis_ai_sdk
If this saved you time, a star on GitHub or a like on pub.dev helps more people find it.

Top comments (7)
One unified API across Gemini, OpenAI, Anthropic, HuggingFace, Ollama, and on-device is the right abstraction, and the fragmentation you're solving is real, every provider has a different shape and there's no clean cloud-to-on-device switch, so most Flutter AI code is hard-wired to one vendor and painful to change. The part that makes this more than a convenience wrapper is the cloud-and-on-device-behind-one-interface bit, because that's the precondition for routing: once the call site doesn't care which backend serves it, you can send the cheap/private/offline-friendly tasks to on-device Gemma and reserve the cloud frontier call for the hard ones, all without touching app code. That's where the unified SDK quietly becomes a cost-and-privacy lever, not just an ergonomics one. Baking tool-calling, memory, and safety guardrails into the SDK is also the right call, those are exactly the cross-cutting concerns nobody should re-implement per provider. The thing I'd make sure stays first-class as it grows: the guardrails enforcing at the boundary, not just passing through whatever the provider offers. That one-interface-enables-routing instinct is core to how I think about provider orchestration in Moonshift. Does Genesis let you route per-call (this task on-device, that one cloud), or is the backend chosen once at init?
So on the current scope it dosent let you route, but that is surely a great way to think I would try to improve it and make sure a scalable structure for routing is there, which decides on the routing but as of users choice, (I'll surely update you on this in some days)
Thanks for letting me think better on this, Do use the sdk and let me know if you think any other improvements can be made, or even if you think you can contribute you are open to contribute to the repo if you think you can add some features
Hey, I've added the functionality for the per call routing, you can go and test it out there, Do let me know your reviews on it
This looks like a handy toolkit for integrating AI into Flutter apps! Have you had any experience with performance differences between the cloud-based models and on-device Gemma?
Thanks for the question!
The short answer is: it depends entirely on the hardware, but the SDK itself adds zero overhead.
When running Gemma on device using a development machine (like a 16GB Mac), the performance is incredibly fast with almost no noticeable difference compared to cloud APIs. However, on average mobile hardware, local inference can still feel quite laggy due to GPU and memory constraints.
The good news is I've tried to keep the this Flutter AI SDK to be completely lightweight once the model is initialized on the device, the SDK doesn't introduce any bottlenecks. For mobile apps, cloud models are still king for speed, but on device is getting closer as mobile hardware evolves.
That's great to hear about performance! We've noticed similar patterns with local models like Qwen3; they can be quite fast on powerful devices but lag on average hardware. Have you considered optimizing for edge devices, perhaps by reducing model size or using quantization techniques?
That’s exactly why the core mission of genesis_ai_sdk is to be a universal integration layer rather than a model optimization tool. Since AI organizations are already doing the heavy lifting on hardware quantization, our goal is simply to make running those models in Flutter effortless.
For mobile/edge deployment, I highly recommend pairing the SDK with smaller 1B–3B models instead of full-sized ones. Running highly quantized versions of Qwen-1.5B, Gemma-2B, or Phi-3-mini on-device gives a massive speedup on average hardware while keeping the integration completely seamless!"