OpenGPTs: Customizable AI Model Framework

OpenGPTs, powered by LangChain's technology stack, offers developers a versatile framework for harnessing AI capabilities. Leveraging over 60 language models, LangSmith's prompt customization, and a suite of 100+ tools, OpenGPTs provides unparalleled control and flexibility in AI model configurations.

General
AuthorLangChain
RepositoryGitHub - LangChain OpenGPTs
TypeCustomizable AI Model Framework

Framework Overview

OpenGPTs serves as a customizable AI framework, allowing users to fine-tune language models, prompts, tools, vector databases, retrieval algorithms, and chat history databases. This level of control surpasses direct usage of OpenAI, enabling developers to interact with APIs directly and craft tailored user interfaces.

Technology Tutorials

Customization

  • 1. Language Models (LLMs): Select from over 60 LLMs integrated with LangChain. Note the varying prompts required for different models.
  • 2. Prompt Customization: Debug and fine-tune prompts with LangSmith for enhanced accuracy.
  • 3. Tool Integration: Access a diverse suite of 100+ tools provided by LangChain or easily create custom tools.
  • 4. Vector Databases: Choose from 60+ vector database integrations within LangChain.
  • 5. Retrieval Algorithms: Optimize retrieval algorithms based on project requirements.
  • 6. Chat History Databases: Tailor chat history databases to suit specific project needs.

Agent Types (Default):

  1. "GPT 3.5 Turbo"
  2. "GPT 4"
  3. "Azure OpenAI"
  4. "Claude 2"

OpenGPTs' appeal lies in its high level of customization compared to direct usage of OpenAI. Users gain control over language model selection, seamless addition of custom tools, and direct API utilization. Furthermore, developers can craft custom UIs as needed.

Utilize OpenGPTs to harness the power of AI tailored precisely to your project requirements.

For a deeper dive into usage and configuration, refer to the OpenGPTs Documentation.

OpenGPTs top builders

Explore the top contributors showcasing the highest number of OpenGPTs app submissions within our community.

Langchain OpenGPTs AI technology Hackathon projects

Discover innovative solutions crafted with OpenGPTs, developed by our community members during our engaging hackathons.

AnticipatedD/G4LA13_Gala4_Localizing_Code-Graph

AnticipatedD/G4LA13_Gala4_Localizing_Code-Graph

AnticipatedD/G4LA13_Gala4_Localizing_Code-Graph is a resilient Band Agentic Mesh designed for the Pocketful track. It demonstrates how autonomous agents can collaborate to build a four‑stage wallet and payments service with auditability and reproducibility. The factory runs three agent seats — Architect, Builder, and Reviewer — each with a clear mandate. The Architect inspects requests and produces ordered plans with acceptance criteria. The Builder implements endpoints stage by stage, containerizing services and enforcing balances, validation, and conservation of funds. The Reviewer runs harness tests, validates outputs, and rejects failures with clear logs. Recovery is built in: failures trigger mandate updates and retries until all tests pass. - Stage‑1 establishes authentication, balances, and payments. - Stage‑2 integrates a UI layer with Playwright tests. - Stage‑3 adds time‑aware balances, statements, and operator corrections. - Stage‑4 completes the system with refunds and correction batches. Technologies include Python, Docker, Band SDK, Band Desktop, Band Agent API, Band WebSocket API, Playwright, and GitHub Actions. This structured progression shows originality, resilience, and research‑grade ambition. 🛠 Technologies Used (Expanded) - Python 3.12 Core language for backend service implementation. - Docker Containerizes each stage (stage-1 through stage-4) for reproducibility. - Band SDK Connects agents to Band infrastructure. Provides adapters. - Band Desktop (formerly Jam). The coordination surface where Architect, Builder, and Reviewer agents collaborate. - Band Agent API (/api/v1/agent). Used by agents to validate identity, recruit peers, join chats, send messages, and post events. - Band WebSocket API (Phoenix Channels). - Playwright Automates browser tests for Stage‑2 UI integration. - GitHub Actions CI/CD pipeline for automated builds and harness runs.

FixFlow - Find it,Fix it,Prove it

FixFlow - Find it,Fix it,Prove it

Modern software development teams face a persistent challenge: debugging a failure is rarely limited to identifying an error. When unexpected behavior occurs, developers must manually inspect source code, understand program logic, reproduce the issue, identify its root cause, implement a correction, write tests, and verify that the fix has not introduced new problems. This fragmented debugging process consumes valuable development time and often leaves developers with a critical question: **did the fix actually solve the problem?** Our solution, **FixFlow**, introduces an AI-powered autonomous debugging workflow that transforms debugging from a manual, fragmented process into a continuous investigation-and-verification loop. The platform accepts source code through an interactive web workspace and orchestrates multiple specialized debugging stages powered by **IBM Bob**. Instead of simply generating a code patch, FixFlow analyzes the code and runtime behavior, investigates program logic, generates relevant test cases, identifies the root cause, proposes a targeted fix, executes regression tests, and independently verifies the result. The FixFlow workflow follows a structured pipeline: **Code Analysis → Runtime Analysis → Logic Analysis → Test Generation → Root Cause Analysis → Fix Generation → Regression Testing → Independent Verification**. Each stage contributes evidence to the next, allowing the system to move from identifying a potential problem to producing a tested and reviewable solution. What differentiates FixFlow is its **closed-loop debugging architecture**. Traditional AI coding workflows can stop after producing a suggested fix; FixFlow continues by testing the corrected code and asking an independent verification stage whether the identified issue has actually been resolved. Developers can therefore see not only the proposed correction, but also the reasoning, generated tests, execution results, regression results, and verification outcome behind it. FixFlow is purpose-built for **software developers, backend engineers, DevOps engineers, SREs, and students** who need a systematic way to investigate and resolve software failures. By combining IBM Bob's reasoning capabilities with automated execution and verification, FixFlow aims to make debugging more **structured, transparent, evidence-driven, and reliable**, while keeping the developer in control of the final decision to accept and apply a fix. **FixFlow doesn't just find a bug and suggest a fix — it follows the fix through testing and verification.** **Find it. Fix it. Prove it.**

ReleaseGuard AI

ReleaseGuard AI

Software releases require developers to manually check multiple areas before deployment, including code changes, test results, dependency updates, security-related risks, and deployment configuration. These checks are often distributed across different tools and files, making the process time-consuming and increasing the possibility of missed issues or repeated manual work. ReleaseGuard is an AI-powered Release Readiness and Deployment Assistant designed to bring these checks into one coordinated workflow. It analyzes a software project before release and produces an explainable release-readiness assessment that helps developers understand what needs attention before deployment. The solution is designed for software developers and development teams who want a structured way to validate a release. A developer selects the project to analyze and starts the release analysis. ReleaseGuard coordinates multiple specialized analyzers: a Change Analyst examines Git changes and affected files, a Test Agent executes and analyzes tests, a Dependency Agent identifies dependency and version changes, a Security Agent identifies obvious security-related risks, and a Deployment Agent checks deployment configuration and readiness. The results are passed to a transparent Risk Engine, which preserves the evidence from each analyzer and classifies findings as CRITICAL, HIGH, MEDIUM, LOW, or PASS. The system produces an overall release state of READY, NEEDS_ATTENTION, or BLOCKED. If an analyzer cannot run, the system explicitly reports that the result is unavailable instead of treating it as a successful check. A key feature is the developer-in-the-loop fix-and-retest workflow. Developers can inspect a finding, view its evidence and explanation, review a proposed remediation, and explicitly approve the change. After an approved fix is applied, ReleaseGuard runs the relevant tests and re-analyzes the affected areas to show the updated result. ReleaseGuard also generates a release report, release notes, and deployment checklist from verified analysis results. The project is creative in its combination of coordinated release analysis, specialized agent roles, explainable findings, and an iterative fix-test-reanalyze workflow. Rather than simply producing a generic AI recommendation, it connects repository evidence, automated validation, remediation, and documentation into one release-readiness workflow. The target outcome is to reduce manual release-checking effort, make potential issues easier to identify and understand, reduce avoidable rework, and provide developers with a repeatable and transparent release validation process. The developer remains the final decision-maker for whether a release should proceed.

Code2Edge: Deployment with Proof

Code2Edge: Deployment with Proof

Porting a PyTorch model to a microcontroller sounds like a model problem, but it's really a pipeline problem. A keyword-spotting model needs audio resampled, windowed, FFT'd, run through a Mel filterbank, log-compressed, and normalized before it ever reaches the network — and the constants controlling each step (window size, FFT convention, epsilon values) are usually scattered across config files nobody rereads. Get one of them wrong in the C rewrite and the device still boots fine; it just quietly predicts the wrong thing, with no black-box "pass/fail" test telling you why. Code2Edge solves this with stage-wise differential parity instead of black-box testing. The same audio corpus runs through both the Python reference pipeline and the generated C pipeline, and every intermediate tensor is compared — max/mean absolute error, cosine similarity, and eventually prediction agreement. If a stage drifts past tolerance, the system flags exactly which stage and offers a deterministic hint (e.g., "shape mismatch at framing — check hop length"), so debugging starts from evidence instead of guesswork. Bob drives this as an orchestrator, not a black-box code generator. An MCP server gives it five hardware-aware tools (profiling the model, inspecting the pipeline, checking the target, running parity tests, benchmarking) plus workflow tools for starting runs and gating steps. Bob follows a fixed sequence: analyze the repo, produce an Edge Readiness Report, pause for a human APPROVE/REJECT, generate code, run a host parity gate (with a 3-attempt repair loop before escalating to a human), build for the MCU, run a device parity gate, benchmark on real silicon, and open a pull request. The target users are embedded/ML engineers who need confidence that a ported pipeline behaves identically to its source model — not just that it compiles. The project is grounded in a real trained workload: a 119,372-parameter DS-CNN for 12-class keyword spotting (96.65% test accuracy), deployed to an STM32U585 (Cortex-M33) on an Arduino UNO Q. What makes this different is the discipline around honesty: every reported number is explicitly labeled real (measured from an artifact) or mock (a placeholder for an unavailable dependency), and the two are never mixed. Host-side parity is fully real and passing across 500 samples and 4 pipeline stages. Physical benchmarking is real and passing on actual silicon (50/50 correct inferences). Device-side parity is real but currently limited to a single fixture rather than the full corpus — an openly disclosed gap, with a hardware-validation guide checked in to finish the job.

ForensiX-ZR Release & Security Audit Assistant

ForensiX-ZR Release & Security Audit Assistant

orensiX-ZR is a role-based crime analysis and incident management platform where citizens can report crimes and upload evidence, while officers review, investigate, and manage cases end-to-end. Before every release, developers need to manually verify security, authentication, database and migrations, testing, dependencies, and deployment configuration, making the process slow, repetitive, error-prone, and difficult to repeat consistently. Team CodeFlow solved this problem by combining IBM Bob 2.0 with a deterministic Python audit engine (scripts/release_check.py) to create a structured, repeatable, evidence-based release-readiness workflow. IBM Bob Project Context understands the repository, Agent Mode drives multi-step audit workflows, and specialized audit tasks independently analyze Security, Configuration, Database, Deployment, Testing, and Dependencies before consolidating the results into a release-readiness report. The audit engine produces deterministic findings with severity, confidence, evidence, affected locations, and remediation steps in both Markdown and JSON formats, without inventing CVEs or test results. During development, the team identified and remediated real issues by adding CI/CD through GitHub Actions, replacing public /uploads with authenticated evidence-file access, upgrading python-multipart from 0.0.20 to 0.0.32 and python-jose from 3.3.0 to 3.4.0, making VALID_OFFICER_CODES mandatory, reducing JWT lifetime to 30 minutes, increasing the minimum password length from 6 to 8 characters, confirming .env is gitignored, adding non-root Docker execution, separating production and test dependencies, and documenting production host restrictions. The final live audit using python scripts/release_check.py --run-tests --run-pip-audit resulted in READY WITH WARNINGS, with 0 confirmed blocking findings, 23/27 checks passed, 2 non-blocking warnings, 2 items requiring human verification, and 35/35 pytest tests passing, while GitHub Actions CI was confirmed present. The remaining warnings are CONFIG-03 (ALLOWED_HOSTS=* in .env.example, which must be restricted in production) and SEC-04 (JWT passed through the WebSocket query parameter due to a browser WebSocket API limitation). The project demonstrates an evidence-based workflow that moves from Audit → Findings → Fix → Verify → Release, making release-readiness checks more structured, repeatable, and transparent. Team CodeFlow: Saqib Azair, Zainab, Areeha.

RecodeAI — Legacy Code Modernization Engine

RecodeAI — Legacy Code Modernization Engine

RecodeAI is an explainable legacy-code modernization platform designed to help developers understand, prioritize, and modernize aging software systems. Organizations and development teams often depend on legacy applications that still perform critical functions but contain outdated APIs, insecure programming patterns, deprecated language features, poor observability, and growing technical debt. Modernizing these systems manually is expensive and risky because developers must first understand what should change, why it should change, and whether a proposed modification could alter existing behavior. RecodeAI turns this process into an interactive modernization workflow. A developer submits legacy source code and selects its programming language. RecodeAI analyzes the code using a deterministic static-analysis engine and identifies modernization concerns across categories such as security, maintainability, legacy constructs, code quality, and observability. Each finding includes its severity, location, explanation, and recommended remediation. Rather than simply generating replacement code, RecodeAI calculates explainable security, maintainability, modernization, and overall health scores. It then converts its findings into a prioritized modernization plan so developers can understand which problems should be addressed first. For transformations that can be performed safely, RecodeAI can generate a modernized version of the source code and display a before-and-after diff. Potentially behavior-changing fixes are intentionally reported for developer review rather than being silently rewritten. The primary users are developers, engineering teams, students maintaining older applications, and organizations planning software modernization initiatives. What makes RecodeAI different is its focus on explainable and conservative modernization. Instead of treating legacy modernization as a black-box “rewrite my code” operation, RecodeAI separates detection, risk assessment, planning, transformation, and validation. This keeps developers in control while making modernization significantly faster and easier to understand. The MVP supports Python, Java, and JavaScript and is designed with an extensible analysis architecture so additional languages, modernization rules, and AI-assisted capabilities can be introduced without redesigning the core system.