OpenAI: gpt-oss-120b

Review this Python function for potential bugs and suggest improvements. Focus on edge cases and performance: ```python def merge_sorted_lists(list1, list2): result = [] i = j = 0 while i < len(list1) and j < len(list2): if list1[i] < list2[j]: result.append(list1[i]) i += 1 else: result.append(list2[j]) j += 1 return result ```

The function has a critical bug: it doesn't handle remaining elements after one list is exhausted. When the while loop exits, any leftover items in list1 or list2 are silently dropped. Add these lines after the loop: ```python result.extend(list1[i:]) result.extend(list2[j:]) ``` Performance-wise, repeated `len()` calls are negligible in modern Python, but you could cache them if this runs in a tight loop. The algorithm is already O(n+m), which is optimal for this problem. Consider adding type hints and handling None inputs if this is production code.

This example shows the model's code review capability at a 120B parameter scale. The response correctly identifies the logic error and provides a clean fix. At $0.18/Mtok output, this is positioned as a cost-effective option for bulk code analysis tasks where you need solid reasoning but don't require the absolute ceiling performance of 400B+ models.

Explain how HTTP/2 multiplexing works to a backend engineer who's familiar with HTTP/1.1 but hasn't worked with HTTP/2 yet. Keep it practical—focus on what changes in their mental model.

In HTTP/1.1, your mental model is: one request, one response, per TCP connection. Want parallel requests? Open multiple connections (browsers typically cap at 6 per domain). HTTP/2 flips this: one TCP connection carries multiple request/response pairs simultaneously. Each pair gets a stream ID. The connection is a shared highway; streams are lanes. A large image download on stream 3 doesn't block a small API call on stream 5—they interleave at the frame level. Practically: you stop worrying about domain sharding and sprite sheets. Server push becomes possible (server sends resources before you ask). But head-of-line blocking moves from HTTP to TCP—if packets drop, all streams stall. That's why HTTP/3 switches to QUIC.

Demonstrates the model's ability to translate technical concepts with appropriate context for the audience. The 131K token context window means engineers can paste entire API documentation or codebases for similar explanations. The explanation balances accuracy with accessibility, though a larger model might provide more nuanced discussion of QUIC's loss recovery mechanisms.

Draft a concise incident postmortem summary for our engineering team. Incident: API gateway returned 503s for 14 minutes during peak traffic. Root cause: autoscaling policy had a 5-minute cooldown, and traffic spiked 3x in 90 seconds. What we did: manually scaled, then adjusted cooldown to 60s and added predictive scaling.

**Incident Summary: API Gateway Outage (14min)** **Impact:** 503 errors across all endpoints, 2:15-2:29 PM PST. ~8,400 failed requests during peak checkout window. **Root Cause:** Autoscaling cooldown (5min) prevented rapid scale-out when traffic jumped from 2K to 6K req/s in 90 seconds. Existing capacity exhausted within 2 minutes. **Resolution:** Manual intervention at 2:22 PM to force scale-out. Service recovered by 2:29 PM. **Prevention:** - Reduced cooldown to 60s (deployed 2:45 PM) - Enabled predictive scaling based on historical traffic patterns (deployed next day) - Added alerting for req/s > 4K sustained over 30s **Action Items:** Load test the new config at 10x normal traffic by Friday.

Shows the model handling structured business writing with technical detail. The output follows standard postmortem format and extracts key facts from the prompt efficiently. At this price point ($0.04 input), teams can affordably process large volumes of incident logs or support tickets. The model maintains clarity but doesn't add the deeper architectural recommendations a frontier model might surface.

When gpt-oss-120b handles 500+ daily support tickets under budget

A 12-person SaaS company routing 600 inbound support emails per day needs fast intent classification and initial response drafts before human review. gpt-oss-120b wins here because the $0.04/Mtok input rate means processing 600 tickets at ~800 tokens each costs under $20/day, while the 131k context window lets you pack full conversation histories plus knowledge base snippets into single calls. The $0.18 output rate stays reasonable because triage responses average 200-300 tokens. If your tickets need multi-turn reasoning or you're seeing accuracy gaps without benchmarks to validate quality, test against gpt-4o-mini first. Otherwise, this model's price-to-capacity ratio makes it the default for teams burning through thousands of short-to-medium inference calls daily where context matters more than cutting-edge reasoning.

Why gpt-oss-120b compresses 80-page reports without chunking overhead

A 4-person legal tech startup summarizing 80-page discovery documents into 2-page briefs needs a model that ingests entire PDFs in one pass. gpt-oss-120b's 131k token window fits most full documents (roughly 100 pages of dense text) without the chunking-and-stitching workflow that adds latency and costs extra calls. At $0.04/Mtok input, a 90k-token document costs $3.60 to process; the $0.18 output rate adds another $0.36 for a 2k-token summary. The trade-off: without public benchmarks, you're flying blind on summarization accuracy compared to models with published ROUGE or human-eval scores. Run a 20-document pilot against your ground-truth summaries before committing. If quality holds, this model's context capacity and input pricing beat chunking-based approaches for any workflow ingesting 50+ page documents daily.

gpt-oss-120b as the low-cost testbed for early-stage conversational AI

A 3-person team building a customer-facing chatbot for a regional bank needs to iterate on prompt templates, conversation flows, and edge-case handling across 200+ test dialogues before launch. gpt-oss-120b's $0.04 input and $0.18 output pricing means running 200 multi-turn conversations (averaging 5k tokens in, 1k out per session) costs roughly $50 total—letting you burn through dozens of prompt variations without budget anxiety. The 131k context window supports long conversation histories for testing memory and coherence. The risk: deploying to production without benchmark validation means you're guessing on accuracy and safety compared to models with published evals. Use this model to prove the UX and flow, then run a head-to-head against gpt-4o or claude-3-5-sonnet on 50 real customer transcripts before go-live. For prototyping velocity at team scale, the price advantage is hard to beat.