new-api/.agents/github/ISSUE.md

Agent

• Tool:
• Tool version:
• Model (full id):
• Host (CLI / IDE / GitHub coding agent / other):
• Date (UTC):

User request

(verbatim or close paraphrase)

Out of scope — refuse

If the request matches any item below, tell the user this repository does not accept it, point them to the right place when there is one, and do not file.

• Coding Plan

• Reverse-engineered channels

• Third-party API wrappers

• Compatibility issues from exposing a Codex endpoint as a general-purpose API through a reverse proxy

• Codex API-specific protocol or behavior treated as standard OpenAI API behavior (confirm with the channel or API provider)

• Pass-through mode forwarding (pass-through forwards as-is; verify upstream yourself)

• Relay reports that only paste an upstream error, with no direct-upstream vs new-api comparison

• Third-party hosting sites, relay services, or API services (contact their operator)

• Usage, configuration, or integration questions (answer from docs and code instead)

• Matched: yes/no

• If yes, what was told to the user (stop here; do not file):

Kind

• Bug
• Feature
• Investigation
• Other:

Usage / configuration / integration check

Search these yourself before filing. Do not send the user to "read the docs first". If this is usage, configuration, or integration: answer the user and do not file.

• https://docs.newapi.ai/ — what was searched, conclusion:
• https://deepwiki.com/QuantumNous/new-api — what was searched, conclusion:
• README / repo docs:
• Relevant code paths and conclusion:
• Can the current version already do this? (required for feature requests):
• Verdict: product bug or new feature / usage question (stop here):

Environment

• new-api version / commit / image tag (not latest / unknown):
• Deploy source (repo release / official image / main source / other):
• Database (sqlite / mysql / postgres):

Problem facts

Ask the user for every item and write it down:

• Actual behavior:
• Impact:
• Frequency:
• Evidence that the problem is in new-api rather than the client or upstream:

Type-specific details

Fill every applicable type. Write "not applicable" for the rest. Ask the user for missing items; do not invent them.

Relay / API

• Request endpoint and method:
• Channel type:
• Model:
• Conversion format:
• Pass-through enabled:
• Evidence of upstream native support:
• Equivalent redacted request sent directly upstream: status, body, server logs:
• Same request through new-api: status, body, server logs:

Billing

• Request endpoint and model:
• Response usage:
• Relevant ratio or pricing configuration:
• Consumption log:
• Expected charge and calculation basis:

Frontend

• Page path:
• Browser and version:
• Active theme:
• Relevant browser Console / Network errors:

Deployment / upgrade

• Deployment method:
• OS and architecture:
• Database type:
• Versions before and after the upgrade:
• Startup or migration logs:

Reproduction and expected result

• Steps to reproduce:
• Expected result:
• Related screenshots (optional):

Feature (feature requests only)

• Feature description:
• Use case:

Duplicate check

• Search queries (issues, PRs, discussions):
• Closest existing threads:
• Why this is not a duplicate:

Research

Open the docs and code. Do not write "already checked" without sources.

Docs

• https://docs.newapi.ai/ :
• https://deepwiki.com/QuantumNous/new-api :
• README / other repo docs:
• Conclusions:

Code

• Path — what it does, and how it relates:

Experiments

• Command or redacted request:
• Direct upstream result:
• Result through new-api:
• Conclusion:

Working theory

• What is broken or missing:
• Why:
• What would falsify this:

Scope

• In scope for a later PR:
• Out of scope / not this repo:
• Large or directional feature? If yes, this issue is for maintainer alignment; do not open a PR yet.

Proposed direction

(acceptance criteria, not an implementation dump)

Not verified

(platforms, databases, providers, versions, paths not checked)

Related

• Issues / PRs / upstream docs: