This project is GoModel - a high-performance, lightweight AI gateway that routes requests to multiple AI model providers through an OpenAI-compatible API.
Accept user requests generously, adapt them to each provider’s requirements, and return conservative OpenAI-compatible responses.
Examples:
- Accept
max_tokensfrom users even when a provider expects another field. - Translate
max_tokenstomax_completion_tokensfor OpenAI reasoning models when required. - Normalize provider responses into an OpenAI-compatible shape.
Prefer production-friendly service design:
- Configuration through environment variables.
- Stateless request handling.
- Clear separation between configuration, routing, provider adapters, and runtime behavior.
- Useful logs for containers and cloud environments.
Reference: https://12factor.net/
Keep files small.
Prefer explicit, maintainable code over clever abstractions.
Do not add abstractions until a repeated pattern clearly justifies them.
Defaults should fit most users so well that they rarely need to change them.
When adding configuration:
- Choose a safe, practical default.
- Avoid requiring configuration for common use cases.
- Document when and why users should override the default.
When changing provider behavior:
- Preserve the OpenAI-compatible public API.
- Keep provider-specific logic isolated.
- Avoid leaking provider-specific quirks into user-facing behavior.
- Never expose API keys, authorization headers, or secrets in errors or logs.
When editing code:
- Make the smallest change that solves the problem.
- Use idiomatic Go.
- Prefer clear names, small interfaces, simple structs, and table-driven tests.
- Avoid hidden global state, unnecessary reflection, and premature optimization.
- Add or update tests for behavior changes.
Tests should cover request translation, response normalization, error handling, default configuration, and provider-specific parameter mapping.
Documentation in docs/ directory is Mintlify based. It should be concise, practical, and user-focused.
Show defaults, explain when to change them, and include minimal examples when useful.
Use Conventional Commits for commit subjects and PR titles:
type(scope): short summary
Allowed types: feat, fix, perf, docs, refactor, test, build, ci, chore, revert
Examples:
feat(openai): support reasoning model token mapping
fix(router): preserve request headers during provider retry
docs(config): document default provider timeout
Squash merges should preserve the PR title as the resulting commit subject.
Do not state that a PR or commit was co-authored by Claude Code. Keep PR descriptions concise. Do not write a commit description unless it contains essential information for the reviewer. Do not add Claude links to PRs or commits.
Before opening a PR:
- Ensure tests pass.
- Keep the change focused.
- Explain the user-visible impact.
- Mention provider-specific behavior when relevant.
- Update documentation for new configuration or API behavior.
If this repository is not the official GoModel repository, ask the user whether they also want to create a PR against the official repository:
https://github.com/ENTERPILOT/GoModel/
Greptile and CodeRabbit review new PRs automatically. Monitor CI and the review comments; verify each finding and address the valid ones before merging. Some findings appear only in the review summary under headings like "Comments Outside Diff" — Greptile updates its main comment in place after every push, so re-read it after each change.
Full reference: .env.template and config/config.example.yaml