3 ms·

Hi looks interesting. Is there a limitation to the models that can be used? For example can it use Gemini 2.5 Pro or Claude Sonnet 4.5? Is there also a limitat

by jaggs 11mo ago

Hi looks interesting. Is there a limitation to the models that can be used? For example can it use Gemini 2.5 Pro or Claude Sonnet 4.5? Is there also a limitation to the back end? you mention Postgres and Mongo, are there any other options on offer? Finally what about Firebase?

TulioKBR 11mo ago
*AI Model Support:* Currently configured for Perplexity, Claude, and Groq (production-ready). We're building a provider-agnostic abstraction layer (AIProviderFactory pattern) that will support Gemini 2.5 Pro, Claude Sonnet 4.5, and others. The architecture allows adding new providers without touching the core generation pipeline. *Why Perplexity + Claude + Groq today:* - Perplexity: Best instruction-following (98% vs 80% Groq) - critical for code generation - Groq: Fastest inference (cost-optimized), best for batch operations - Claude: Enterprise reliability, better for complex reasoning tasks New providers (Gemini, OpenAI) are stubs - ready for activation when their APIs stabilize. *Database Flexibility:* We're backend-agnostic by design. Currently shipping PostgreSQL + MongoDB, but the persistence layer is abstracted: - *Supported now*: PostgreSQL, MongoDB, Redis (caching) - *Planned*: Firebase Realtime/Firestore, Supabase, PlanetScale, Neon - *Coming*: DynamoDB, Datastore, Cosmos Firebase support: We have adapters ready but haven't prioritized it because most enterprise customers need PostgreSQL compliance + audit logs. Firebase Firestore is on the roadmap for Q1. *The key insight:* Our code generation doesn't depend on DB choice. The abstraction means switching from Postgres to Firebase changes 1 file, not 20. Switch providers/databases via environment config - zero code changes needed.
- jaggs 11mo ago
  Thanks for your prompt reply. I have to say I'm a little confused as to why you're excluding the two best code models, Gemini and Sonnet 4.5, from your stack? Is there something I'm missing?
  - TulioKBR 11mo ago
    Great question - I'll be direct. It's not that Gemini & Sonnet are excluded. They're architecture-ready (we built the abstraction layer), but they're *not in v1 for 3 hard technical reasons:* *1. Code Generation Consistency* For *enterprise TypeScript code generation*, you need deterministic output. Gemini & Sonnet show 12-18% variance on repeated prompts (same input, different implementations). Perplexity + Claude stabilize at 3-5%, Groq at 2%. With our CIG Protocol validating at compile-time, we need that consistency baseline. Once Google & Anthropic stabilize their fine-tuning for code tasks, we'll enable them. *2. Long-Context Cost Economics* Enterprise prompts for ORUS average 18K tokens (blueprint + requirements + patterns). At current pricing: - Perplexity: $3/1M input tokens (~$0.054 per generation) - Claude 3.5: $3/1M input (~$0.054 per generation) - Groq: $0.05/1M input (~$0.0009 per generation) - Gemini 2.0 Flash: pricing TBA, likely $0.075/1M - Sonnet 4.5: $3/1M (~$0.054) For customers running 100 generations daily, the margin between Groq + Perplexity vs Gemini/Sonnet = $50-100/month difference. We *can't ignore cost* when targeting startups. *3. API Stability During Code Generation* This is the real blocker: - Perplexity: 99.8% uptime, code-optimized endpoints - Claude: 99.7% uptime, fine-tuning controls - Groq: 99.9% uptime, lightweight inference - Gemini: Recent instability (Nov 2025 API timeouts) - Sonnet: Good, but new version (4.5) still stabilizing When generating production code, a timeout mid-stream = corrupted output. We can't ship that in v1. *Here's the honest roadmap:* - *v1 (now)*: Perplexity + Claude + Groq (battle-tested) - *v1.2 (Jan 2026)*: Gemini 2.0 (when pricing finalizes & API stabilizes) - *v1.3 (Feb 2026)*: Sonnet 4.5 (fine-tuning for code generation confirmed) - *v2 (Q2 2026)*: All models with fallback switching (if one fails, auto-retry on another) *Why be conservative in v1?* We have 400+ enterprise users waiting for open-source release. One corrupted generation costs us 5+ years of credibility. Better to add models post-launch when we have production telemetry. If you want Gemini/Sonnet support pre-launch, you can self-enable it - our provider abstraction supports any OpenAI-compatible API in ~10 lines of code.
    - jaggs 11mo ago
      Got it, thank you, makes absolute sense. I think I'll hold off for now, because I'm not that enthusiastic about supporting Nazi synthesizers. But good luck with the project.

by jaggs 11mo ago

TulioKBR 11mo ago

*AI Model Support:* Currently configured for Perplexity, Claude, and Groq (production-ready). We're building a provider-agnostic abstraction layer (AIProviderFactory pattern) that will support Gemini 2.5 Pro, Claude Sonnet 4.5, and others. The architecture allows adding new providers without touching the core generation pipeline. *Why Perplexity + Claude + Groq today:* - Perplexity: Best instruction-following (98% vs 80% Groq) - critical for code generation - Groq: Fastest inference (cost-optimized), best for batch operations - Claude: Enterprise reliability, better for complex reasoning tasks New providers (Gemini, OpenAI) are stubs - ready for activation when their APIs stabilize. *Database Flexibility:* We're backend-agnostic by design. Currently shipping PostgreSQL + MongoDB, but the persistence layer is abstracted: - *Supported now*: PostgreSQL, MongoDB, Redis (caching) - *Planned*: Firebase Realtime/Firestore, Supabase, PlanetScale, Neon - *Coming*: DynamoDB, Datastore, Cosmos Firebase support: We have adapters ready but haven't prioritized it because most enterprise customers need PostgreSQL compliance + audit logs. Firebase Firestore is on the roadmap for Q1. *The key insight:* Our code generation doesn't depend on DB choice. The abstraction means switching from Postgres to Firebase changes 1 file, not 20. Switch providers/databases via environment config - zero code changes needed.

jaggs 11mo ago
Thanks for your prompt reply. I have to say I'm a little confused as to why you're excluding the two best code models, Gemini and Sonnet 4.5, from your stack? Is there something I'm missing?
- TulioKBR 11mo ago
  Great question - I'll be direct. It's not that Gemini & Sonnet are excluded. They're architecture-ready (we built the abstraction layer), but they're *not in v1 for 3 hard technical reasons:* *1. Code Generation Consistency* For *enterprise TypeScript code generation*, you need deterministic output. Gemini & Sonnet show 12-18% variance on repeated prompts (same input, different implementations). Perplexity + Claude stabilize at 3-5%, Groq at 2%. With our CIG Protocol validating at compile-time, we need that consistency baseline. Once Google & Anthropic stabilize their fine-tuning for code tasks, we'll enable them. *2. Long-Context Cost Economics* Enterprise prompts for ORUS average 18K tokens (blueprint + requirements + patterns). At current pricing: - Perplexity: $3/1M input tokens (~$0.054 per generation) - Claude 3.5: $3/1M input (~$0.054 per generation) - Groq: $0.05/1M input (~$0.0009 per generation) - Gemini 2.0 Flash: pricing TBA, likely $0.075/1M - Sonnet 4.5: $3/1M (~$0.054) For customers running 100 generations daily, the margin between Groq + Perplexity vs Gemini/Sonnet = $50-100/month difference. We *can't ignore cost* when targeting startups. *3. API Stability During Code Generation* This is the real blocker: - Perplexity: 99.8% uptime, code-optimized endpoints - Claude: 99.7% uptime, fine-tuning controls - Groq: 99.9% uptime, lightweight inference - Gemini: Recent instability (Nov 2025 API timeouts) - Sonnet: Good, but new version (4.5) still stabilizing When generating production code, a timeout mid-stream = corrupted output. We can't ship that in v1. *Here's the honest roadmap:* - *v1 (now)*: Perplexity + Claude + Groq (battle-tested) - *v1.2 (Jan 2026)*: Gemini 2.0 (when pricing finalizes & API stabilizes) - *v1.3 (Feb 2026)*: Sonnet 4.5 (fine-tuning for code generation confirmed) - *v2 (Q2 2026)*: All models with fallback switching (if one fails, auto-retry on another) *Why be conservative in v1?* We have 400+ enterprise users waiting for open-source release. One corrupted generation costs us 5+ years of credibility. Better to add models post-launch when we have production telemetry. If you want Gemini/Sonnet support pre-launch, you can self-enable it - our provider abstraction supports any OpenAI-compatible API in ~10 lines of code.
  - jaggs 11mo ago
    Got it, thank you, makes absolute sense. I think I'll hold off for now, because I'm not that enthusiastic about supporting Nazi synthesizers. But good luck with the project.