American English - Pronunciation

S vs Z Pronunciation (English)

What they are

• /s/ = voiceless “s” sound

• /z/ = voiced “z” sound

How to feel the difference (easy test)

• Put your fingers on your throat (Adam’s apple area).

  • /s/: no vibration

  • /z/: vibration (your voice box is “on”)

How to make them

• Mouth position is almost the same (tongue near the ridge behind the top teeth, air goes through a narrow gap).

• The key difference is voice:

  • /s/: air only (like “snake”)

  • /z/: air + voice (like “buzz”)

Common examples

• /s/: see, sun, bus, rice, hiss

• /z/: zoo, zero, music, boys, is

Very common spelling rule (plural / -s, third person -s)

• After a voiceless sound → usually /s/

  • cats /kæts/, books /bʊks/

• After a voiced sound → usually /z/

  • dogs /dɔːgz/, kids /kɪdz/

• After s, z, sh, ch, x, j sounds → /ɪz/

  • buses /ˈbʌsɪz/, watches /ˈwɑːtʃɪz/

Quick practice

• Hold a long sound: ssssss (quiet throat) vs zzzzzz (buzzing throat)

---

S 和 Z 发音（中文）

它们是什么

• /s/ = 清音 的 “s”

• /z/ = 浊音 的 “z”

怎么快速分辨（最简单的方法）

• 用手指摸喉咙（喉结附近）。

  • /s/：几乎没有震动

  • /z/：有明显震动（声带在工作）

怎么发出来

• 口型几乎一样（舌头靠近上齿龈后方的齿龈脊，气流从狭窄通道出去）。

• 关键差别是 有没有“带声”：

  • /s/：只有气流（像 “snake” 里的 s）

  • /z/：气流 + 声带振动（像 “buzz” 的嗡嗡感）

常见例子

• /s/：see, sun, bus, rice, hiss

• /z/：zoo, zero, music, boys, is

超常见拼写规则（复数 / -s，第三人称 -s）

• 前面是 清辅音 → 通常读 /s/

  • cats /kæts/，books /bʊks/

• 前面是 浊音 → 通常读 /z/

  • dogs /dɔːgz/，kids /kɪdz/

• 结尾是 s, z, sh, ch, x, j 这类音 → 读 /ɪz/

  • buses /ˈbʌsɪz/，watches /ˈwɑːtʃɪz/

快速练习

• 拉长发音：ssssss（喉咙不震） vs zzzzzz（喉咙在震）

---

Intro to the EAR Diphthong (American English)

In American English, the EAR diphthong is most commonly the sound /ɪr/—a quick glide from a relaxed /ɪ/ (“ih”) into /r/. You hear it in words like ear, here, near, cheer, fear, and weird (often /wɪrd/).

1) What it sounds like

• Start with a short “ih” sound: like the vowel in sit.

• Then slide immediately into /r/.

• The vowel part is usually short, and the /r/ is strong in American English (rhotic).

2) How to make it (step-by-step)

1. Jaw: slightly open, relaxed.

2. Tongue (vowel /ɪ/): high and forward-ish, not tense.

3. Slide to /r/: pull the tongue back slightly and raise the sides of the tongue; the tongue tip usually does not touch the roof of the mouth.

4. Lips: often slightly rounded for /r/.

Try it slowly: ih → r = /ɪr/.

3) Common spelling patterns

You’ll often see ear / eer / ere / ier / ir:

• ear: ear, hear, near

• eer: cheer, deer (many Americans say /dɪr/)

• ere: here, sincere

• ier: pierce, tier

• ir: weird, spirit (varies by word)

4) Practice words

Say each one clearly, then faster:

• ear, here, near, fear, cheer, beard, weird, pier

5) Quick sentence practice

• “I’m here near the pier.”

• “I can hear the cheer.”

• “Don’t fear being weird.”

---

美式英语中的 EAR 双元音入门

在美式英语里，EAR 双元音最常见的读音是 /ɪr/——从放松的 /ɪ/（“ih”）快速滑向 /r/。你会在这些词里听到它：ear, here, near, cheer, fear，以及 weird（常见读法是 /wɪrd/）。

1) 听起来像什么

• 先发一个短促的 “ih”：类似 sit 里的元音。

• 然后 立刻滑到 /r/。

• 元音部分通常 很短，而美式英语的 /r/ 很明显（卷舌音/儿化特征，rhotic）。

2) 怎么发（分步骤）

1. 下巴：微微张开，放松。

2. 舌位（元音 /ɪ/）：舌头较高、偏前一些，但不要紧绷。

3. 滑向 /r/：舌头略向后收，同时 抬高舌头两侧；舌尖通常 不碰 上颚。

4. 嘴唇：发 /r/ 时常常 略微圆唇。

慢慢试：ih → r = /ɪr/。

3) 常见拼写规律

你经常会看到这些拼写：ear / eer / ere / ier / ir：

• ear：ear, hear, near

• eer：cheer, deer（很多美式发音会读成 /dɪr/）

• ere：here, sincere

• ier：pierce, tier

• ir：weird, spirit（不同单词会有差异）

4) 练习词

每个词先清晰读，再加快：

• ear, here, near, fear, cheer, beard, weird, pier

5) 句子快速练习

• “I’m here near the pier.”

• “I can hear the cheer.”

• “Don’t fear being weird.”

---

Intro to the “UH” Vowel (American English)

1) What sound is “UH”?

• In American English, “UH” most often means the /ʌ/ sound (the STRUT vowel), like in cup, luck, sun.

• There’s also a very common “uh” sound called schwa /ə/ in unstressed syllables, like about, sofa.

• In this intro, we’ll focus on /ʌ/ and briefly compare it to /ə/.

2) How to pronounce /ʌ/ (mouth + tongue)

• Jaw: slightly open (not wide)

• Lips: relaxed, not rounded

• Tongue: relaxed in the center of the mouth (not high, not front)

• Voice: ON (it’s a voiced vowel)

• Quick feel: Say “ah” then relax your mouth and let the sound move toward a neutral “uh”.

3) /ʌ/ vs. schwa /ə/ (easy comparison)

• /ʌ/ = usually stressed: CUP, LUCK, SUN

• /ə/ = usually unstressed: aBOUT, SOfa, again

• A helpful rule: if the syllable is strong and clear, it’s often /ʌ/; if it’s weak and quick, it’s often /ə/.

4) Common spellings for /ʌ/

• u: cup, sun, luck, rush

• o: love, come, mother, some

• ou: young, tough

• oo: flood, blood (common exceptions)

5) Minimal pairs (hear the difference)

• /ʌ/ vs /æ/: cup vs cap, luck vs lack

• /ʌ/ vs /ʊ/: cut vs could, luck vs look

• /ʌ/ vs /oʊ/: cut vs coat, son vs sew (name “Sew”)

6) Quick practice routine (5 minutes)

• Step 1 (sound): hold /ʌ/ for 2 seconds: “uhhh”

• Step 2 (syllables): bʌ, kʌ, sʌ, lʌ

• Step 3 (words): cup, luck, sun, love, come

• Step 4 (phrases): a cup, so much, just one, come back

• Step 5 (sentence): “I just want one cup.” (stress just / want / one / cup)

7) Common mistakes to avoid

• Too rounded (turning into /ʊ/ like book): keep lips relaxed.

• Too open (drifting toward an “ah” sound): don’t drop the jaw too much.

• Using schwa in a stressed syllable: keep /ʌ/ clear when the syllable is stressed.

8) Self-check tips

• Record yourself saying “cup” and “coop” (to compare /ʌ/ vs /u/).

• Put a finger under your chin: /ʌ/ should be small jaw movement, not big.

• If it sounds “lazy” but the word is stressed, make it a bit clearer: /ʌ/, not /ə/.

---

“UH” 元音简介（美式英语）

1) “UH” 是什么音？

• 在美式英语里，“UH” 最常指 /ʌ/ 这个音（STRUT 元音），比如 cup, luck, sun。

• 还有一个非常常见的 “uh” 音叫 弱读元音 schwa /ə/，出现在 非重读 音节里，比如 about, sofa。

• 这篇简介会重点讲 /ʌ/，并简单对比 /ə/。

2) /ʌ/ 怎么发（口型 + 舌位）

• 下巴： 微微张开（不要张太大）

• 嘴唇： 放松，不要噘圆

• 舌头： 放松在口腔 中间（不高、不靠前）

• 声带： 要振动（这是浊元音）

• 快速体感： 先说 “ah”，然后放松口腔，让声音回到更中性的 “uh”。

3) /ʌ/ 和弱读元音 /ə/（简单对比）

• /ʌ/ = 通常 重读：CUP, LUCK, SUN

• /ə/ = 通常 非重读：aBOUT, SOfa, again

• 一个好用的规则：音节如果强而清楚，常常是 /ʌ/；如果弱而很快，常常是 /ə/。

4) /ʌ/ 的常见拼写

• u: cup, sun, luck, rush

• o: love, come, mother, some

• ou: young, tough

• oo: flood, blood (常见例外)

5) 最小对立对（听出差别）

• /ʌ/ vs /æ/：cup vs cap, luck vs lack

• /ʌ/ vs /ʊ/：cut vs could, luck vs look

• /ʌ/ vs /oʊ/：cut vs coat, son vs sew (名字 “Sew”)

6) 快速练习流程（5 分钟）

• 步骤 1（音）： 把 /ʌ/ 拉长 2 秒：“uhhh”

• 步骤 2（音节）： bʌ, kʌ, sʌ, lʌ

• 步骤 3（单词）： cup, luck, sun, love, come

• 步骤 4（短语）： a cup, so much, just one, come back

• 步骤 5（句子）： “I just want one cup.”（重读 just / want / one / cup）

7) 常见错误要避免

• 嘴唇太圆（变成 /ʊ/ 像 book）：保持嘴唇放松。

• 口太开（跑向 “ah” 的感觉）：下巴不要掉太多。

• 重读音节用成 schwa： 该重读时把 /ʌ/ 发清楚，不要变成 /ə/。

8) 自我检查小技巧

• 录音对比 “cup” 和 “coop”（比较 /ʌ/ 和 /u/）。

• 手指放在下巴下面：/ʌ/ 的下巴动作应该 小，不是大幅度。

• 如果听起来太“糊”但这个词在重读位置，就把它发清一点：/ʌ/，不是 /ə/。

---

Intro to the “UH” Vowel (Part 2) — American English

1) Is “uh” always found in the stressed syllable of a word?

Mostly yes (for /ʌ/).

• The /ʌ/ vowel (STRUT) is usually stressed: CUP, LUCK, SUN, MOTH-er, BROTH-er.

• In unstressed syllables, American English often uses schwa /ə/ instead (a weaker “uh”): aBOUT /əˈbaʊt/, soFA /ˈsoʊfə/.

• In fast speech, even a syllable that could have /ʌ/ may sound closer to /ə/ if it’s not stressed.

Takeaway: If the syllable is clearly stressed, “uh” is often /ʌ/. If it’s weak/quick, it’s often /ə/.

2) “u” followed by a consonant = /ʌ/?

Often, but not always.
Common /ʌ/ examples:

• cut, cup, luck, fun, bus, rush

Common exceptions (not /ʌ/):

• put /pʊt/, push /pʊʃ/, pull /pʊl/, full /fʊl/ (these are usually /ʊ/ in American English)

• use /juz/, music /ˈmjuzɪk/ (here “u” is /ju/ or /u/, not /ʌ/)

Tip: If the word is in the “put/push/pull/full” family, it’s usually /ʊ/, not /ʌ/.

3) “u” between two consonants = /ʌ/?

Very often (especially in one-syllable words).

• fun, sun, run, luck, duck, jump, lunch

But still watch for the /ʊ/ exceptions:

• pull, push, full (and sometimes bull /bʊl/)

4) “o” followed by a consonant, followed by an “e” (the “O–E sandwich”) = /ʌ/?

• Most of the time it’s /oʊ/: hope, rope, joke, note

• But there’s a small exception set with /ʌ/: come, some, love, shove, done, none

• One fun example: dove can be /dʌv/ (the verb “dive” past tense for some speakers) or /doʊv/ (the bird), depending on meaning and speaker.

5) “C-O-M” (like C-O-M-E) = /ʌ/?

Sometimes “o” spells /ʌ/ in common words, but it’s a word-list pattern, not a perfect rule.
Very common /ʌ/ words with o:

• come /kʌm/, some /sʌm/, love /lʌv/, money /ˈmʌni/

• mother /ˈmʌðər/, brother /ˈbrʌðər/, another /əˈnʌðər/

But many “o” words are NOT /ʌ/:

• home /hoʊm/, cone /koʊn/, most /moʊst/

Tip: Memorize the high-frequency set: come, some, love, money, mother, brother, another.

6) What about: what, was, of, the, because?

These are function words, so their vowel often changes with stress (strong form vs weak form).

• what: usually /wʌt/ (often stays /ʌ/ even in fast speech)

• was: strong /wʌz/, weak /wəz/

• of: strong /ʌv/, weak /əv/

• the: usually /ðə/ before consonants (the book), and /ði/ before vowels (the apple) or when emphasized

• because: commonly /bɪˈkʌz/ in American English; also /bɪˈkɔz/ for some speakers; very often reduced in speech to /kəz/ (“’cause”)

Mini practice (natural American rhythm):

• What was the problem? → /wʌt wəz ðə ˈprɑbləm/

• It was because of the bus. → /ɪt wəz kəz əv ðə bʌs/

---

“UH” 元音简介（第 2 部分）——美式英语

1) “uh” 一定在单词的重读音节里吗？

大多数情况下是（针对 /ʌ/）。

• /ʌ/（STRUT 元音）通常是重读：CUP, LUCK, SUN, MOTH-er, BROTH-er。

• 在非重读音节里，美式英语常用 schwa /ə/（更弱的 “uh”）：aBOUT /əˈbaʊt/、soFA /ˈsoʊfə/。

• 在快速语流中，即使某个音节可能有 /ʌ/，只要不重读，也可能听起来更像 /ə/。

**结论：**音节如果明显重读，“uh” 往往是 /ʌ/；如果又弱又快，往往是 /ə/。

2) “u” 后面跟辅音 = /ʌ/ 吗？

经常是，但不总是。
常见 /ʌ/ 例子：

• cut, cup, luck, fun, bus, rush

常见例外（不是 /ʌ/）：

• put /pʊt/、push /pʊʃ/、pull /pʊl/、full /fʊl/（这些在美式英语里通常是 /ʊ/）

• use /juz/、music /ˈmjuzɪk/（这里 “u” 是 /ju/ 或 /u/，不是 /ʌ/）

**小提示：**如果单词属于 “put/push/pull/full” 这一类，通常是 /ʊ/，不是 /ʌ/。

3) “u” 在两个辅音中间 = /ʌ/ 吗？

非常常见（尤其是一音节词）。

• fun, sun, run, luck, duck, jump, lunch

但仍要注意 /ʊ/ 的例外：

• pull, push, full（以及有时 bull /bʊl/）

4) “o” + 辅音 + “e”（“O–E 三明治”）= /ʌ/ 吗？

• 大多数时候是 /oʊ/：hope, rope, joke, note

• 但有一小组 /ʌ/ 的例外：come, some, love, shove, done, none

• 一个有趣的例子：dove 既可能是 /dʌv/（动词 “dive” 的过去式，对一些说话者而言）也可能是 /doʊv/（鸟），取决于含义和说话者。

5) “C-O-M”（比如 C-O-M-E）= /ʌ/ 吗？

有时 “o” 会拼成 /ʌ/，但这更像高频词清单，而不是完美规则。
非常常见的 o = /ʌ/ 单词：

• come /kʌm/、some /sʌm/、love /lʌv/、money /ˈmʌni/

• mother /ˈmʌðər/、brother /ˈbrʌðər/、another /əˈnʌðər/

但很多 “o” 的词并不是 /ʌ/：

• home /hoʊm/、cone /koʊn/、most /moʊst/

**小提示：**先背最常用的一组：come, some, love, money, mother, brother, another。

6) 那么这些词呢：what, was, of, the, because？

这些是功能词，所以它们的元音常随重音变化（强读 vs 弱读）。

• what：通常 /wʌt/（即使语速快也常保持 /ʌ/）

• was：强读 /wʌz/，弱读 /wəz/

• of：强读 /ʌv/，弱读 /əv/

• the：在辅音前通常 /ðə/（the book），在元音前通常 /ði/（the apple），或在强调时用 /ði/

• because：美式英语里常见 /bɪˈkʌz/；也有一些人读 /bɪˈkɔz/；口语里经常弱化成 /kəz/（“’cause”）

小练习（自然的美式节奏）：

• What was the problem? → /wʌt wəz ðə ˈprɑbləm/

• It was because of the bus. → /ɪt wəz kəz əv ðə bʌs/

---

---

---

---

---

---

---

---

---

---

---

---

---

---

---

---

---

---

---

---

---

---

Manus

Manus is a general purpose AI agent, meaning it is built to do tasks for you, not just chat with you. Instead of only answering questions, it can plan a sequence of steps, use tools, and produce finished outputs such as a report, a spreadsheet, a set of slides, or even a simple website. The company describes Manus as an “action engine” that helps turn ideas into delivered results.

Manus has a few product “surfaces” and packaged capabilities. It offers a web app plus mobile and Windows apps, and it highlights workflows such as creating slides, building websites, developing apps, data cleaning and structuring, writing professional emails, translation, and automations like calendar related reminders. It also promotes add ons like a browser operator, research mode, email workflows, and Slack integration.

Its most important product is the core Manus AI agent subscription, which runs tasks on your behalf using its own virtual computer environment and tool access. In practice, this is the “one product” behind all the different use cases you see on the website, because the agent is the part that breaks a goal into steps and then executes those steps to deliver something you can use. Manus publicly said it will keep selling and operating this subscription through its own app and website even after joining Meta, while continuing to operate from Singapore. 

A simple example: imagine you need a short presentation for school about renewable energy. You tell Manus your topic, how many slides you want, and the audience. Manus can research key points, draft a slide outline, write slide text, and produce a ready to present deck. This is similar to the “Create slides” style workflow Manus showcases, and business reporting has also described Manus doing creative work like slide making in addition to research and coding.

Manus competes in the fast growing “agent” space. The closest competitors are large AI assistants that are adding more agent behavior, especially OpenAI ChatGPT, Google Gemini, and also other strong models and systems that users compare against, such as DeepSeek. Manus even markets direct comparisons like “vs ChatGPT,” which reflects that it is positioning itself against mainstream assistants, not only niche automation tools.

The company’s background is closely tied to Butterfly Effect, a team founded by Chinese entrepreneurs that built globally oriented AI products and later launched Manus in 2025, then moved operations to Singapore as cross border tech scrutiny increased. In late December 2025, Meta announced it had acquired Manus, and in early January 2026 reporting said Chinese authorities were reviewing the deal with attention on whether moving staff and technology to Singapore before the sale could trigger Chinese export control requirements.

The main founders commonly reported in recent coverage are Xiao Hong (肖弘), Ji Yichao (季逸超), and Zhang Tao (张涛). Xiao Hong is often described as the CEO and a key founder, while Ji Yichao is described as a cofounder and chief scientist, and Zhang Tao is described as a cofounder who led product work.

Open AI Code Interpreter

Code Interpreter is a built in tool in the OpenAI API that lets a model write Python code and actually run it inside a sandboxed environment, then use the results to finish the task. This is different from plain code generation, where the model only writes code as text and cannot execute it. With Code Interpreter, the model can calculate, transform data, create charts, read files you provide, and generate new files as outputs. A small but important naming detail is that even though the docs call it Code Interpreter, the model “knows” and refers to it as the python tool. If you want to make tool usage more explicit in your prompting, telling the model to “use the python tool” is the clearest instruction.

The mental model: model, tool, container, outputs

When you enable Code Interpreter, you are giving the model access to a Python runtime that lives inside a container. The container is a fully sandboxed virtual machine that the model can run Python code in, and it can hold files you upload or files the model creates.

A typical interaction looks like this conceptually:

The user asks a question or provides files.
Your app calls the Responses API with the Code Interpreter tool enabled.
The model decides whether it needs Python. If yes, it writes code, executes it in the container, sees the results, and may iterate until it succeeds.
The model returns a normal assistant message that explains the result, and it can attach references to any files it generated in the container.

This design is especially useful for tasks where correctness depends on computation and where intermediate failures are normal, like data cleaning, parsing messy files, or statistical analysis. The model can run code, see an exception, fix the code, rerun, and only then respond.

Containers: how they are created, reused, and why they expire

Code Interpreter requires a container object. You can create or select a container in two main ways.

Auto container mode
You set the tool with container: { type: "auto" } (optionally with a memory limit and file ids). In this mode, the system will create a new container or reuse an active container that is already in context from a previous Code Interpreter call. This makes it easy to keep continuity across turns, because you do not need to manage container ids yourself.

Explicit container mode
You create a container yourself using the containers API, then pass its id into the tool configuration for your Responses API call. This gives you more control, for example if you want to deliberately reuse the same container across multiple requests from your server, or if you want a specific memory tier.

Memory tiers
You can choose from memory limits such as 1g as the default, and larger tiers like 4g, 16g, or 64g. That memory limit applies for the life of the container.

Expiration and ephemerality
Containers are meant to be treated as ephemeral. A container expires if it is not used for 20 minutes, and when it expires, the data is discarded and not recoverable. You cannot reactivate an expired container; you create a new one and upload files again. Container operations like retrieving the container or adding or deleting files refresh the container’s last active time.

This is the reason you should treat Code Interpreter as a compute workspace, not as long term storage. If you need something later, download it and store it in your own system.

Files: how to give the model data, and how to get generated artifacts back

There are two separate but related file concepts:

Files in model input
When you include a file as part of the model input, it is automatically uploaded to the container when Code Interpreter runs. You do not need to separately upload it into the container.

Files generated inside the container
The model can create files in the container while it is running Python, for example a CSV of cleaned data, or an image file of a chart. When it does this, the next assistant message can include annotations that cite those container files. These citations include the container id, the file id, and the filename, and you can parse them to present download options in your app.

Downloading generated files
To download a file created in the container, you call the container files content endpoint, conceptually:

GET /v1/containers/{container_id}/files/{file_id}/content

The response is the binary content of the file.

If you want to upload or manage files inside a container directly, there are container file endpoints for creating, listing, retrieving metadata, retrieving content, and deleting.

Prompting patterns that work well with Code Interpreter

Make the model’s decision easy
Instead of asking vaguely, directly grant permission and set expectations, for example: “Use the python tool to compute the answer and show the final numeric result.”

Tell it what to produce
If you want a file, say so explicitly: “Create a CSV with the cleaned data and a PNG chart, then cite the files.”

Ask it to verify with code
For math and data questions: “Compute with the python tool, then cross check with an independent method.”

Keep important state in files
Even if a container stays active, treat it as ephemeral. If a result matters, write it to a file and download it.

End to end example 1: the smallest useful Code Interpreter call

This example enables Code Interpreter in a Responses API request and asks for a math solution. It uses auto container mode.

Python

from openai import OpenAI

client = OpenAI()

instructions = """
You are a personal math tutor.
When asked a math question, use the python tool to compute the answer.
Return the final answer and a short explanation.
"""

resp = client.responses.create(
    model="gpt-4.1",
    tools=[
        {
            "type": "code_interpreter",
            "container": {"type": "auto", "memory_limit": "4g"},
        }
    ],
    instructions=instructions,
    input="Solve 3x + 11 = 14. Show x.",
)

print(resp.output_text)

What you should expect to happen

The model sees the instruction to use the python tool, runs the algebra computation in Python, then returns x = 1 with a short explanation. The exact formatting depends on the model, but the key point is that the computation is executed, not guessed.

End to end example 2: explicit container creation and forcing tool usage

Sometimes you want stronger control. In explicit mode, you create the container first, then pass its id into the response call. You can also set tool_choice to required so the model must use tools for that request.

Python

from openai import OpenAI

client = OpenAI()

container = client.containers.create(
    name="analysis-container",
    memory_limit="4g",
)

resp = client.responses.create(
    model="gpt-4.1",
    tools=[
        {
            "type": "code_interpreter",
            "container": container.id,
        }
    ],
    tool_choice="required",
    input="""
Use the python tool to do all computations.

Compute 4 * 3.82.
Then take the square root of that result.
Then take the square root again.
Return each intermediate value.
""",
)

print(resp.output_text)
print("container_id:", container.id)

Why this is useful

You now have a specific container_id you can reuse on later requests, as long as it remains active. You can also manage its lifecycle explicitly via the containers endpoints, and you can choose memory tiers at creation time.

End to end example 3: upload a CSV, analyze it, generate a chart, download the chart

This example shows the full “data analysis plus artifact output” workflow.

Conceptual flow

Create a local CSV file.
Upload it using the Files API with purpose user_data.
Call the Responses API with Code Interpreter enabled and include the file id in the input message.
Ask the model to read the CSV with the python tool, compute metrics, and save a chart as a PNG file.
Parse the response to find container_file_citation annotations, then download the file content using the container files content endpoint.

Python

import csv
from pathlib import Path
from openai import OpenAI

client = OpenAI()

# Create a tiny CSV locally for the demo
csv_path = Path("sales.csv")
rows = [
    ["date", "region", "revenue"],
    ["2026-01-01", "west", "1200"],
    ["2026-01-02", "west", "900"],
    ["2026-01-01", "east", "700"],
    ["2026-01-02", "east", "1100"],
]
with csv_path.open("w", newline="", encoding="utf-8") as f:
    writer = csv.writer(f)
    writer.writerows(rows)

# Upload the file to OpenAI Files
uploaded = client.files.create(
    file=csv_path.open("rb"),
    purpose="user_data",
)

# Ask the model to analyze it with Code Interpreter
resp = client.responses.create(
    model="gpt-4.1",
    tools=[{"type": "code_interpreter", "container": {"type": "auto", "memory_limit": "4g"}}],
    input=[
        {
            "role": "user",
            "content": [
                {"type": "input_text", "text": """
Use the python tool.

Read the uploaded CSV.
Compute total revenue by region.
Create a bar chart of revenue by region.
Save the chart as chart.png in the container.
Then explain the result in plain English.
"""},
                {"type": "input_file", "file_id": uploaded.id},
            ],
        }
    ],
)

# Print the assistant's explanation
print(resp.output_text)

# Extract container file citations
citations = []
for item in resp.output:
    if item.type == "message":
        for part in item.content:
            ann = getattr(part, "annotations", None)
            if not ann:
                continue
            for a in ann:
                if a["type"] == "container_file_citation":
                    citations.append(a)

print("Found citations:", citations)

# At this point you can download the file bytes:
# Send an authenticated GET request to:
# /v1/containers/{container_id}/files/{file_id}/content
# using citations[0]["container_id"] and citations[0]["file_id"].

Key details that make this work

The file is included in the model input as an input_file with a file id. 
Any files in the model input are automatically uploaded to the container for Code Interpreter runs.
When the model creates chart.png, the next message can include a container_file_citation annotation with the container id and file id.
You download the chart by calling the container file content route for that container id and file id.

End to end example 4: image or document processing as a Python powered vision helper

Code Interpreter is also useful as an “analysis workbench” for images and documents, because Python can load images, crop, rotate, compute histograms, and generate derived images. The docs explicitly call out that the model can use the tool to crop, zoom, rotate, and otherwise process images as part of problem solving.

A practical workflow

Upload an image as an input file.
Ask the model to use the python tool to do preprocessing, for example crop to a region of interest, rotate, enhance contrast, compute statistics, then save the processed image as a new file.
Parse the returned container file citation and download the processed output.

This pattern is extremely useful when you want reproducible image transformations, or when you want the model to compute objective measurements rather than rely on a purely verbal description.

Operational considerations for real products

Latency and iteration
Because the model may run code multiple times, tool enabled requests can take longer than pure text. The tradeoff is higher correctness for computation heavy work.

Rate limits
The guide lists an availability of 100 requests per minute per organization for this tool across APIs, so you should design with throttling and retries in mind.

Cost control
Memory tier selection matters. If most tasks are small, keep the default tier. Move to larger tiers only when needed.

Robustness pattern
When you want highly reliable pipelines, prompt the model to write intermediate outputs to files, then read them back and validate, rather than relying on a single pass.

If you want, tell me what kind of example you care about most, like analyzing a spreadsheet, generating a PDF report, or cleaning JSON logs, and I will write a tailored end to end sample that includes the exact prompts and the response parsing logic for citations.