Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

feat(ai): structured outputs — response_format json_schema for JSON-returning calls where the provider supports it

Open
#670 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
25/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Quiet
Tech stack
java
Domain
ai

Research direction

Start in config/ActiveModelSettings.java to see how per-model flags are declared, then look at the @RegisterAiService request options on PrReviewer, FindingVerifier and PrSummarizer. Add the structured-outputs flag with a default of off and an unchanged prompt path when it is off. Done means a flagged run against a supporting provider produces no salvage activations in tests, and startup rejects the flag on unsupported endpoints.

Written by the indexing model from the issue text.

Description

enhancement java

Split out of #668 so each deliverable can be scheduled and closed independently.

Problem Statement

Every JSON-returning call (review, verifier, summary — and the resolution check once #667 lands) spends significant prompt space specifying output shape: "Respond ONLY with valid JSON…", full schemas, field rules. And because the shape is only requested, malformed output needs the parse-salvage paths and TruncatedResponseSalvager machinery. With the multi-call decomposition (#669) multiplying calls, this boilerplate is paid on every one of them.

Proposed Solution

Where the configured OpenAI-compatible provider supports response_format: json_schema, request it for the JSON-returning calls via LangChain4j request options:

  • Per-model capability flag: thrillhousebot.ai.models.<model>.structured-outputs (default off), following the existing per-model settings pattern in ActiveModelSettings.
  • Prompt-side format instructions shrink to intent only; the schema moves into the request.
  • Graceful degradation: flag off or provider unsupported → current prompt-specified JSON + salvage paths, byte-identical behavior.
  • Truncation salvage stays regardless — finish_reason=length can still cut a schema-valid stream mid-array.

Interacts with #30 (native multi-provider support), which needs the same per-provider capability surface; whichever lands first should establish it.

Touchpoints

config/ThrillhouseConfig.java / config/ActiveModelSettings.java (capability flag), the @RegisterAiService request options for PrReviewer / FindingVerifier / PrSummarizer, review/DiffBudgetPlanner.java (overhead estimation shrinks when format boilerplate leaves the prompts).

Acceptance criteria
  • With the flag on against a supporting provider: zero parse-salvage activations in tests; measured prompt-token reduction on every JSON-returning call.
  • With the flag off or an unsupported provider: behavior unchanged.
  • Startup validation rejects the flag on models where the endpoint reports no support, rather than failing at review time.
Alternatives Considered
  • Keep prompt-specified JSON everywhere — simplest, but the boilerplate and salvage complexity now multiply across the decomposed pipeline.
Dominant language
Java
Stars
35
Forks
7
Avg merge
9h 23m
Merged PRs (30d)
154

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from devops-thiago/ThrillhouseBot

All issues in devops-thiago/ThrillhouseBot

Similar issues

More Java issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.