IBM Granite

General
Relese date	2024
Author	IBM
Website	Granite AI Models
Repository	https://github.com/ibm-granite
Type	AI Models

The Granite AI Models family, developed by IBM, encompasses a range of state-of-the-art language models tailored for various applications. These models provide robust solutions for creating interactive chatbots, executing precise instructions and supporting multiple languages. Each model in the Granite AI Models family is designed to deliver high performance and accuracy, making them ideal for innovative and complex language processing tasks.

Granite AI Models are available on Hugging Face under the Apache 2.0 license.

Granite AI Models

Granite 13b Chat: This model is designed for creating interactive chatbot applications that can understand and generate human-like responses, enhancing user engagement and support capabilities.

Granite 13b Instruct: Optimized for following detailed instructions, this model excels at tasks requiring precise adherence to user commands, making it ideal for complex workflow automation and support tasks.

Granite Multilingual: A powerful model supporting multiple languages, Granite Multilingual is suitable for applications requiring understanding and generation of text in various languages, broadening accessibility and reach.

Granite Japanese: Specialized in Japanese language processing, this model is tailored for applications needing high proficiency in understanding and generating Japanese text, from chatbots to content creation tools.

Start building with Granite AI Models

Granite AI Models, developed by IBM, offer robust solutions for various language processing tasks. These models include the Granite 13b Chat for creating interactive chatbot applications, the Granite 13b Instruct for following detailed instructions, the Granite Multilingual for supporting multiple languages, and the Granite Japanese for applications needing Japanese language proficiency. Start building innovative solutions with these models and explore the community-built use cases and applications for inspiration.

👉 Try Granite on watsonx.ai

👉 Try Granite on Hugging Face

Useful Links

Libraries

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.

ErrLens

The pipeline is a single async generator (backend/app/pipeline.py). Each step emits an event, and the last one carries the full result. parse: Detects the language, the exception type and message, and all frames (innermost first), and separates user code from library code. Handles chained exceptions and warns about minified traces. resolve_paths: Resolves the ref to a commit SHA, fetches the repository tree and maps absolute trace paths (/home/deploy/app/user.py) to repository paths (app/user.py) by longest suffix match. fetch_context: Fetches ±20-line snippets for the first 3 user frames. If the source line in the trace does not match the repository, it warns and lowers the confidence. blame: Blames the lines around each error line. It then runs a related-commit search: if the error lines have not changed since then, it scores the patches of later commits in the same language against the identifiers and string literals on the error lines (for example '%Y-%m-%d'). This finds the cause when the line the trace points to is not the one that changed. analyze: Calls the LLM with a forced tool call. The output is validated in two layers: first the schema, then the semantics (the file and line range must be inside the shown snippet, the diff must build, and the code must pass a Python/JS syntax check). On failure, the error goes back to the model and it gets one retry. If it still fails, the result is returned without a fix. build_fix: Turns the edit into a unified diff with difflib; the LLM never writes the diff itself. The confidence score is 0.6 × LLM confidence + 0.4 × average of signals. The signals are: user frame resolved, change within the last 14 days, error type matches the line, fix validated, trace lines match the commit. done: Saves the result to SQLite. The cache key is a hash of the normalized trace, the repository and the SHA, so an identical request returns without calling the LLM. The pipeline only stops on parse errors and user input errors (invalid URL, repository or ref not found). If any other step fails, it is marked error or skipped and the analysis continues with what it has.

Ongoing Copilot

Problem Joining a new codebase is one of the slowest, most frustrating parts of a developer's job. New hires, open-source contributors and students face hundreds of unfamiliar files, outdated or missing documentation, and no clear place to start. Senior engineers lose hours answering the same questions, and newcomers can spend weeks before making a first meaningful contribution. Generic tutorials don't help: every repository is different, and every developer arrives with a different skill level and role. Solution Developer Onboarding Copilot turns any GitHub repository into a personalised, interactive learning journey, from first clone to first pull request. The user pastes a repository URL, and the system automatically analyses it: languages, frameworks, entry points, directory structure and test suites. It then combines this analysis with the developer's profile (experience level, role such as frontend, backend or fullstack, and personal goals) to generate a day-by-day onboarding plan with concrete tasks, time estimates and the exact files to read. Target users New team members onboarding into company codebases Open-source newcomers who want to contribute but don't know where to begin Students and junior developers learning from real-world projects Engineering managers and maintainers who want to scale onboarding without spending their own time How users interact with it Through a clean web dashboard, the developer follows their plan and tracks progress task by task. When stuck, they ask questions in a codebase-aware chat that answers with references to specific files, like a senior colleague who is always available. After completing a task, they submit their code and receive instant AI feedback against the task's acceptance criteria. When ready, the copilot suggests beginner-safe first contributions based on real gaps in the codebase, and generates a pull request title, description and pre-merge checklist. What makes it creative and unique Most AI coding tools help developers write code. Ours helps them understand code, and it covers the whole path from confusion to contribution in one guided flow instead of isolated features. Plans adapt to the person, not just the project: a beginner fullstack developer and an advanced backend engineer get different journeys through the same repository. The backend also exposes standard MCP endpoints, so its tools can plug directly into IBM watsonx Orchestrate and other agent workflows. Built with IBM Bob and watsonx We used IBM Bob throughout development to design the architecture and to generate and refine the FastAPI backend, React components, prompt templates, tests and documentation. This let a small team ship a full-stack product within the hackathon timeline. All AI reasoning runs on IBM watsonx with Granite models, through a vendor-agnostic provider layer. Impact By replacing weeks of unstructured exploration with a tailored, step-by-step plan, instant answers and validated practice, the copilot shortens time to first contribution, reduces the burden on senior engineers, and makes any codebase approachable for anyone.

RepoScope — AI-Powered Repository Intelligence

Modern software repositories can contain hundreds or thousands of files, functions, classes, and interconnected modules. When developers join an existing project or investigate unfamiliar code, finding the right information often requires manually searching across files and tracing imports and dependencies. Traditional keyword-based search can locate matching text, but it does not inherently explain how code components are connected or which related files are important to the question. This makes repository onboarding, dependency investigation, debugging, and understanding unfamiliar systems time-consuming. Developers also need confidence in AI-generated explanations. An answer without clear evidence or source locations can be difficult to verify, especially when reasoning about a large codebase. The challenge is therefore to provide a practical way to understand a repository through both its textual content and its underlying code relationships, while keeping AI responses grounded in identifiable repository evidence. Solution Statement RepoScope addresses this problem by building a structured intelligence layer over a software repository. The system first ingests repository files and extracts structural information such as classes, functions, methods, modules, signatures, and line ranges. It then identifies relationships between files, including IMPORTS and EXPORTS, and indexes repository content into searchable chunks. When a developer asks a question, RepoScope combines lexical retrieval with relationship-aware expansion to identify relevant files, components, and connected code. A context builder assembles the retrieved evidence, including source locations and relationship information, and passes the grounded context to IBM watsonx.ai and Granite to generate an answer. The resulting response is accompanied by source files, line ranges, and relationship evidence, allowing developers to trace the explanation back to the repository. A dependency graph further provides a visual representation of how relevant code components are connected. This approach combines repository structure, relationships, retrieval, and generative AI into a single workflow for exploring and understanding unfamiliar codebases.

Offline Emergency Communication Network

ResQMesh is an offline emergency communication network built to keep critical information flowing during disasters such as floods, fire accidents, earthquakes, and cyclones — situations where cellular towers fail and internet connectivity disappears within minutes of a disaster striking. At the exact moment communication becomes most critical, conventional systems stop working, cutting off families from each other, victims from help, and rescue teams from visibility into where assistance is needed most. ResQMesh solves this using ESP32 microcontrollers and LoRa-based communication modules to form a network of low-power emergency nodes. When someone needs help, an SOS message containing emergency details and, where available, location or sensor data is transmitted through the nearest node. Instead of depending on a direct connection to a rescue center, messages hop from node to node across the network, extending coverage far beyond the range of any single device. This multi-hop design keeps the system functional even when parts of the network are damaged or spread across a wide disaster zone. At least one node acts as a gateway, linking the mesh to a monitoring dashboard or an external uplink, so data collected offline can still reach human rescue coordinators without requiring internet or cellular access anywhere else in the network. Beyond SOS messages, ResQMesh can integrate environmental sensors such as smoke, temperature, and water-level sensors, giving rescue teams real-time context to prioritize where help is needed most. LoRa's long-range, low-power characteristics make the nodes practical for extended battery-powered deployment, which matters most in disasters where power infrastructure often fails first. By creating a resilient, infrastructure-independent communication layer, ResQMesh helps ensure that no SOS goes unheard simply because the network went down — turning silence during a crisis into a signal that can still reach the people who can help.

Medusa

When you're handed a codebase you didn't write, whether it's a class assignment, a research artifact, or your new employer's old monorepo, the cost is the same: hours spent mapping what talks to what before you can even find where a bug lives. Once you find it, most AI tools jump to a confident fix, with no way to check if it works or why the code broke. Students end up trusting the model instead of learning to reason about the system. Nobody gets proof, only an assertion. Medusa treats understanding a system and proving a fix as two separate, honest steps, on any codebase: point it at a public GitHub repo or an uploaded zip. First, it maps the architecture. A static analysis pass parses the source, builds an import graph, ranks files by importance, and lays out a diagram with the tech stack, entry points and external services, no LLM involved, nothing executed. Large repos degrade to a partial map with a clear reason, not a guess. From the issue list, Medusa's own scan plus the repository's real GitHub Issues, you can reproduce and debug any problem. Two independent investigators work it in parallel and never see each other's answer: IBM Bob, headless and read-only, and IBM Granite on watsonx.ai. On our built-in demo, against OptiLearn, a real offline-first learning platform for refugee classrooms, this runs for real in a locked-down Docker sandbox, then races competing fixes in their own containers. For any linked Python repository with its own tests, Medusa can do the same for real: it asks a model to write a failing test, confirms it inside an isolated gVisor sandbox with its own snapshot and a PyPI-only network, then races proposed fixes against that reproducer. That path is built and tested, and switched off by default until we finish reviewing it live. Everywhere else, Medusa reasons instead of running code, and always says so: plausible, with a confidence score, never reproduced. A deterministic verifier, never a model, decides what passed, what regressed, and what's smallest, and hands back the winning patch as a zip or a git-applyable patch file. That distinction, evidence over confidence, is the point: most AI coding tools will tell you a bug is fixed, while Medusa only says that once a sandbox has proven it. Students get to watch two different models reason about the same bug, then watch a real test suite settle the argument. Researchers get competing hypotheses and the runtime evidence behind each one. Developers onboarding onto an unfamiliar service get the map before the debugger, and can run the same workflow on their own repository, with real verification if they turn it on. This isn't a toy scenario. The demo bug lives in a real LMS with a voice pipeline and an adaptive mastery engine, not a synthetic one-liner built for the pitch. The sandbox, the architecture parser and the verifier are deterministic Python, with the two models doing exactly what they're good at: reasoning, not deciding.