StellarGPT

Extending a chat sample for configurable documentation assistance.

Azure OpenAI chat interface with the model deployment selector open.
Choose the model behind the conversation The selector exposes model deployments in the existing React interface. Real application UI with fictional fixture data and scripted demo responses; no model or database calls.

Built for and adopted by Stellar, StellarGPT helps teams ask recurring questions about their documentation. I extended Microsoft's Azure OpenAI chat sample with reasoning-model support, assistant presets and model-aware conversation history.

The use case is building information modeling, or BIM. A coordinator answering a modeling or handoff question needs the team's procedure and enough source context to check it. The assistant supports that workflow with a documentation assistant preset.

Role
Application extension. Python request handling, API integration, React controls, typed configuration and history metadata.
Foundation
Microsoft's Azure OpenAI sample supplied the chat application, authentication, retrieval infrastructure and Azure deployment foundation.
Status
Adopted by Stellar. Project name, organization and adoption confirmed by Dylan. Screenshots exercise fixture-backed UI; usage scale, live answer quality and measured business outcomes were not established by this review.

The licensing decision

Stellar was considering Copilot licenses for everyone. I persuaded the team to adopt StellarGPT instead, choosing token-based API billing over per-seat licensing for this workflow to avoid a substantial recurring license expense. The project was adopted; a measured monthly savings figure is not established here. Hosting, maintenance and support still belong in the total cost.

Two API paths, one conversation interface

The main engineering change was supporting reasoning models through the Responses API while retaining Chat Completions for other models. Those APIs return different response and streaming shapes. I added routing and normalization so the existing chat interface could consume both paths.

Keeping the original path reduced the scope of the migration. It also left two integrations to maintain, with different request options and event handling. The work crosses backend dispatch, response formatting and the frontend message types; a model dropdown alone would not have completed it.

Assistant selector showing a generic BIM SOPs documentation preset in the chat application.
A preset carries the task configuration The assistant choice connects a model with instructions and typed tool configuration in source. This real UI capture uses a fictional BIM SOPs preset and scripted demo responses, not a live retrieval run.

Configuration follows the conversation

I added model and assistant selection endpoints and controls, with tool definitions represented in Python and TypeScript. Conversation records also gained model and assistant metadata in Cosmos DB, making the selected configuration part of the saved record.

The BIM preset asks the assistant to use the supplied documentation and include page references. That is an instruction to the model. The review did not establish that answers or page references are consistently correct, and the example below is scripted.

A fictional BIM documentation question and an illustrative assistant response in the real chat interface.
A response the coordinator can review This scripted demo answer illustrates the intended question-and-document workflow. Its procedure and references are fictional; they are not evidence of generated answer quality or validated citations.

What this work establishes

The fork adds a coherent feature across model dispatch, configuration, UI and persistence. My contribution is that extension. The underlying chat product and Azure foundation remain Microsoft's work.

Shared application state for selections, unfinished tool and history behavior, and verbose logging remain technical follow-up items in the reviewed source. The source review and fixture screenshots do not replace application tests, live provider checks or a supervised pilot. Adoption is confirmed; this review did not establish measured time savings.

The next useful trial would use a small approved document set and questions that coordinators already answer. Check each answer against the current procedure, verify its references, and count both review time and unsupported claims. The use-case document describes that trial from the team's perspective.

  • Python
  • React
  • TypeScript
  • Azure OpenAI
  • Responses API
  • Cosmos DB

Evidence snapshot: 7 September 2026. Screenshots show the existing application build with an isolated fixture API, fictional documents and scripted responses. No live model, database or customer data was used.